应用错误收集

要指出的第一个事实是MySQL RDS Read Replicas使用异步复制，因此您的主实例将在执行事务处理的SQL之后复制它们。如果此RDS实例失败，则可以，您可能会丢失少量数据。

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

升级只读副本期间应遵循的steps如下：

阻止任何事务被写入只读副本源数据库实例，然后等待对只读副本进行所有更新。数据库更新发生在源数据库实例上之后，将在只读副本上发生，并且此复制滞后可能会发生很大的变化。使用“副本延迟”度量标准来确定何时对只读副本进行了所有更新。
仅适用于MySQL和MariaDB：如果需要对MySQL或MariaDB只读副本进行更改，则必须在只读副本的数据库参数组中将read_only参数设置为0。然后，您可以在只读副本上执行所有必需的DDL操作，例如创建索引。对只读副本执行的操作不会影响源数据库实例的性能。
使用Amazon RDS控制台上的Promote选项，AWS CLI命令promote-read-replica或PromoteReadReplica 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设置，它将自动为您执行升级和故障转移。

要总结这是您对3个问题的回答

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