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

Question

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

在 AWS RDS 中，当从站自动提升为主站时，会提出以下问题：

Answer 1

首先要指出的事实是，MySQL RDS只读副本使用异步复制，因此您的主实例将在执行事务处理 SQL 后复制这些副本。如果此 RDS 实例发生故障，那么您可能会丢失少量数据。

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

升级只读副本期间应遵循的步骤应如下所示：

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

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

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

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

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

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

总结一下你的 3 个问题的答案

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