AWS MySQL RDS 故障转移 - 复制滞后处理？

Question

在正常的 MySQL 复制设置中，当主服务器出现问题时，从服务器很可能落后并且没有最新数据。

在AWS RDS中，当一个slave被自动提升为master时，问题：

1. 滞后的数据会永远丢失吗？
2. 如果主DB再次up，会不会有冲突？
3. 在我的应用程序中查询数据库时是否需要做一些特殊处理？

Answer 1

首先要指出的是 MySQL RDS Read Replicas 使用异步复制，因此您的主实例将在执行事务 SQL 后复制这些。如果此 RDS 实例失败，那么是的，您可能会丢失少量数据。

然后，只要源数据库实例发生更改，它就会使用引擎的本机异步复制来更新只读副本

在提升只读副本期间应遵循的steps 应如下所示：

• 停止将任何事务写入只读副本源数据库实例，然后等待对只读副本进行所有更新。数据库更新在源数据库实例上发生之后发生在只读副本上，并且这种复制延迟可能会有很大差异。使用 Replica Lag 指标来确定对只读副本进行所有更新的时间。
• 仅适用于 MySQL 和 MariaDB：如果您需要更改 MySQL 或 MariaDB 只读副本，则必须在只读副本的数据库参数组中将 read_only 参数设置为 0。然后，您可以在只读副本上执行所有需要的 DDL 操作，例如创建索引。对只读副本执行的操作不会影响源数据库实例的性能。
• 使用 Amazon RDS 控制台上的提升选项、AWS CLI 命令提升读取副本或提升读取副本 Amazon RDS API 操作提升只读副本。
• （可选）将新数据库实例修改为多可用区部署。有关更多信息，请参阅修改 Amazon RDS 数据库实例和 Amazon RDS 的高可用性（多可用区）。

如果您将 RDS 实例升级为一个独立的 RDS 实例，它将仅包含在升级之前它所拥有的事务。任何其他红色副本将保留在原始集群中。

即使主数据库恢复，此时您提升的 RDS 实例也是不同集群的一部分，此时无法撤消该操作。如果它们之间有任何交易差异，则需要手动应用。

对于您的应用程序，主要更改是数据库 DNS 名称现在已更改。我建议创建或使用 private route 53 hosted zone 并创建指向原始 RDS cname 的 CNAME 记录。完成此操作后，请更新您的应用程序以在您的私有托管区域中使用 CNAME。

如果您需要提升只读副本，则只需将 Route 53 中的 CNAME 值更新为新的 RDS CNAME。如果您确实使用此功能，请记住将 Route 53 记录的 TTL 保持在较低水平，以确保快速进行故障转移。

或者，如果您可以使用Multi-AZ 设置，它将自动为您执行升级和故障转移。

总结这三个问题的答案

• 滞后的数据会永远丢失吗？ - 一旦你提升了 RDS 实例，两者之间的关系就被破坏了，任何没有被复制的东西都不会被复制。
• 如果主数据库又起来了，会不会有冲突？ - 从 RDS 的角度来看没有冲突，它们现在是两个独立的 RDS 实例。
• 在我的应用程序中查询数据库是否需要做一些特殊处理？ - 确保您的应用程序现在可以与新 RDS 集群的新 DNS CNAME 通信。尝试使用 Route 53 私有托管区域来降低使用旧 CNAME 的风险。