我正在尝试评估 AWS RDS Aurora 作为我们本地 MySQL 数据库的 future 替代品，但我注意到一些奇怪的行为。
我有一个基本集群，其中包含一个数据库主机(写入器)和一个副本(读取器)。我的想法是将阅读器用作始终可用的数据源，即使在编写器不可用时也是如此。但是当我重新启动 master 时，它也会让 reader 崩溃，使设置变得毫无值(value)。
查看读取器副本日志，当它注意到写入器已关闭时会发生以下情况:
有谁知道如何让 Aurora 读取入口点永远不会关闭，即使作者离线或短暂忙碌也是如此？
或者无论集群大小如何，写入/读取“不同步”总是会导致读取器入口点失效？
最佳答案
让副本在主服务器重启期间保持可用的唯一方法是使用传统的 MySQL 复制来拥有一个异步副本——Aurora 确实支持这种复制。
Aurora replication is very different比 MySQL(或 Galera)复制。 master 丢失必然会触发集群重组，因为各个实例没有自己的数据副本，它们共享一个 6 路复制存储卷——这就是复制可以保持在 10-20 毫秒内的原因时间范围。实际上从 master 复制的是事务日志 LSN。 master的更换需要提升一个replica，接管后验证磁盘上的数据结构是否干净，然后所有其他replica开始跟随它。
If the DB cluster has one or more Aurora Replicas, then an Aurora Replica is promoted to the primary instance during a failure event. A failure event results in a brief interruption, during which read and write operations fail with an exception.
当 Aurora 副本停止接收来自主服务器的更新时，实际故障出在哪里并不重要——无论是实际主服务器还是基础设施中的其他地方——副本停止服务查询，因为在最好的情况下，它不会更长的时间可以访问权威数据。
如果可能，zero-downtime patching似乎是为了避免在升级期间重新启动主机。除了升级之外，应该不需要重新启动主服务器。
关于amazon-web-services - 重启 AWS RDS Aurora master/writer 也会重启读者？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50246429/