我正在尝试评估 AWS RDS Aurora 作为我们本地 MySQL 数据库的未来替代品，但我注意到一些奇怪的行为。
我有一个基本集群，其中包含一个数据库主服务器（写入器）和一个副本（读取器）。我的想法是将阅读器用作始终可用的数据源，即使在编写器不可用时也是如此。但是当我重新启动主控时，它也会关闭阅读器，使设置变得毫无价值。
查看读取器副本日志，当它注意到写入器已关闭时会发生以下情况：
有谁知道如何让 Aurora 读取入口点即使写入器离线或短暂忙碌也不会关闭？
或者无论集群的大小，写入/读取“不同步”是否总是关闭读取器入口点？
【问题讨论】：
标签： amazon-web-services amazon-rds amazon-aurora
在主服务器重新启动期间保持副本可用的唯一方法是使用常规 MySQL 复制来获得异步副本 - Aurora 确实支持。
Aurora replication is very different 比 MySQL（或 Galera）复制。 master 的丢失必然会触发集群的重组，因为各个实例没有自己的数据副本，它们共享一个 6 路复制的存储卷——这就是复制可以保持在 10-20 毫秒内的方式时间范围。实际上从主服务器复制的是事务日志 LSN。更换master需要提升一个replica，接管后验证磁盘上的数据结构是干净的，然后所有其他replica开始跟随它。
如果数据库集群有一个或多个 Aurora 副本，则在发生故障事件期间，一个 Aurora 副本会提升为主实例。失败事件会导致短暂的中断，在此期间，读写操作会失败并出现异常。
当 Aurora 副本停止查看来自主节点的更新时，无论实际故障出在哪里（无论是实际的主节点还是基础架构中的其他位置）都无关紧要，因为在最好的情况下，它不会为查询提供服务more 可以访问权威数据。
在可能的情况下，zero-downtime patching 似乎可以避免在升级期间重新启动主服务器。除了升级，应该不需要重启master。
【讨论】：