最近我考虑在生产环境中使用Amazon RDS Multi-AZ部署服务，并且我已经阅读了相关文档。
但是，我对故障转移有疑问。在Amazon RDS的常见问题解答中，故障转移描述如下：
问：在多可用区故障转移期间会发生什么以及需要多长时间？
Amazon RDS会自动处理故障转移，以便您可以恢复 数据库操作尽快而无需管理 介入。当失败时，亚马逊RDS只是翻转规范 数据库实例的名称记录（CNAME）指向备用数据库， 反过来又被提升为新的主要人物。我们鼓励你 遵循最佳实践并实现数据库连接重试 应用层。故障转移时间是它的时间的函数 完成崩溃恢复。从头到尾，通常是故障转移 在三分钟内完成。
从上面的描述中，我猜必须有一个监控服务，它可以检测主要实例的故障并进行翻转。
我的问题是，哪个AZ监控服务主机在哪？有三种可能性： 1.与主要相同的AZ 2.与备用数据库相同的AZ 3.另一个AZ
显然1＆amp; 2不会是这种情况，因为它无法处理整个AZ不可用的情况。那么，如果是3，那么如果监控服务的AZ发生故障怎么办？是否有其他服务来监控此监控服务？这似乎是一个无尽的多米诺骨牌。
那么，亚马逊如何确保多可用区部署中RDS的可用性？
答案 0 :(得分：0)
受过教育的猜测 - 监控服务在所有AZ上运行，并引用正在运行的实例的共享列表（在AZ之间进行同步复制）。只要一个AZ上的监视服务注意到另一个AZ已关闭，它就会将所有正在运行的实例的CNAMES翻转到当前处于启动状态的AZ。
答案 1 :(得分：0)
我们无法确定故障转移实例所在的位置，但我们的主要位于US-West-2c，而次要位于US-West-2b。
使用PostgreSQL，我们的数据因亚马逊卷的物理问题而被破坏（尽可能接近）。我们当时没有设置多个AZ，因此为了恢复，我们必须尽可能接近事件执行时间点恢复。亚马逊支持向我们保证，如果我们继续使用多可用区，他们会自动转移到其他AZ。这引出了他们如何确定这一点的问题，以及数据损坏是否会传播到另一个AZ？
由于这个shisaster，我们还添加了一个只读副本，这对我来说似乎更有意义。我们还使用RO副本进行读取和其他功能。我对亚马逊代表的理解是，人们可以将多可用区设置视为更像RAID的情况。
答案 2 :(得分：0)
如果符合以下条件，则会从文档中发生故障转移：
这表明监控不在同一个AZ 中。最有可能的是，只读副本使用mysql函数（https://dev.mysql.com/doc/refman/5.7/en/replication-administration-status.html）来监视主服务器的状态，并在主服务器无法访问时采取措施。
当然，这还有一个问题，如果副本AZ失败会发生什么？亚马逊很可能会对副本的故障检测进行检查，以确定其是否出现故障或是否为主要故障。
答案 3 :(得分：0)
那么，亚马逊如何确保多可用区部署中RDS的可用性？
我认为，鉴于RDS是一种PaaS服务，在这种情况下，“如何”被设计从用户中抽象出来。多区域部署有很多隐藏的内容，但是，以下情况属实：
在他的blog post中，John Gemignani提到observer管理哪个RDS实例在多AZ架构中处于活动状态的概念。但是到了你的观点， observer是什么？它在哪里观察？
根据我对AWS的经验，这是我的猜测：
RDS多可用区部署中的
observer是一种高可用性服务，部署在RDS多可用区可用的每个区域的每个AZ中，并利用现有AWS平台服务来监控运行状况以及可能影响RDS实例的所有基础结构的状态。组成observer的某些服务可能是AWS平台本身的一部分，也可能对用户隐藏。
我愿意打赌，构成CloudWatch Events的相同底层服务在某些容量中用于RDS多可用区observer。来自Jeff Barr的blog post宣布CloudWatch Events，他用这种方式描述了这项服务：
您可以将CloudWatch Events视为AWS环境的中枢神经系统。它连接到受支持服务的每个角落，并在发生操作时意识到操作变化。然后，在您的规则的驱动下，它会激活功能并发送消息（激活肌肉，如果您愿意），以响应环境，进行更改，捕获状态信息或采取纠正措施。
以同样的方式考虑observer - 它是AWS平台的一个组件，它提供了我们作为平台用户不需要考虑的功能。这是AWS在Shared Responsibility Model中负责的一部分。