AWS - 失败的主实例在恢复后发生了什么答案

【问题标题】：AWS - What happened to the failed Primary Instance after it recoversAWS - 失败的主实例在恢复后发生了什么
【发布时间】：2019-03-29 23:57:51
【问题描述】：

我是 AWS Aurora 的新手。

在this link阅读下面这段时：

为了提高可用性，您可以使用 Aurora 副本作为故障转移目标。也就是说，如果主实例发生故障，则 Aurora 副本提升为主实例

如果失败的Primary Instance可以恢复，它会是哪个角色？我猜它会变成副本？

我问这个问题是因为我猜连接 Aurora 数据库集群的服务器代码必须指定主实例和副本的端点？由于Replica只提供只读查询，所以在Replica提升为Primary Instance后代码必须更正端点才能进行写操作查询？

我的代码如何知道哪个端点现在是主实例的（即可以进行写操作查询）？

【问题讨论】：

【解决方案1】：

Aurora 集群不仅为您提供集群中每个节点的直接连接终端节点，还为您提供读写终端节点和只读终端节点。读写端点将始终指向主节点。只读端点将跨只读副本节点执行 DNS 循环连接。

因此，如果一个节点发生故障并且另一个节点被提升为主节点，只要您使用这些端点而不是单个节点端点，您就不必进行任何更改。

【讨论】：

【解决方案2】：

您通过URL 连接到集群端点，例如 mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

这样，当发生故障转移时，您不必对代码进行任何更改，在 AWS 的幕后，该 url 现在将指向现在被提升为主要（写入）的只读副本节点。

【讨论】：

【解决方案3】：

如果失败的Primary Instance可以恢复，它会是哪个角色？我猜它会变成副本？

写入器失败有多种情况，根据情况不同，它们的处理方式也不同。故障转移是 Aurora 从故障中恢复的方式之一。发生故障转移时，旧的 WRITER 将作为 READER 重新启动。对于其他小故障场景，Aurora 将自动恢复，无需故障转移。而是恢复了相同的 WRITER。

我的代码如何知道哪个端点现在是主实例的

您的代码应始终处理集群端点而不是实例端点。集群 RW 端点将始终指向主节点，而集群 RO 端点将跨副本执行 DNS 循环。在发生故障转移的任何时候，您的客户端连接都会断开，它们应该尝试使用集群端点重新连接。

如果你真的需要知道当前作者和读者的详细信息，你可以通过查询副本状态表来做到这一点，但我认为这不是你需要的。

【讨论】：