Amazon RDS for MySQL 的高副本滞后问题 AmazonRDSforMySQL使用异步复制

Amazon RDS for MySQL 使用异步复制，因此副本有时无法与主数据库实例保持同步。这可能会导致复制滞后。
使用 Amazon RDS for MySQL 只读副本和基于二进制日志文件位置的复制时，您可以通过查看 Amazon RDS ReplicaLag 指标来监控 Amazon CloudWatch 中的副复制滞后。 ReplicaLag 指标可报告 SHOW SLAVE STATUS 命令的 Seconds_Behind_Master 字段的值。
Seconds_Behind_Master 针对副本数据库实例所处理的事件，显示副本数据库实例上的当前时间戳与主数据库实例上记录的原始时间戳之间的差异。
MySQL 复制适用于三个线程：Binlog Dump 线程、IO_THREAD 和 SQL_THREAD 。有关这些线程具体工作方式的更多信息，请参阅 MySQL 文档的复制实施细节。如果复制中存在延迟，请先确定滞后是由副本 IO_THREAD 还是副本 SQL_THREAD 引起的。然后，您可以确定滞后的根本原因。
文章插图
排查方法：
要确定哪个复制线程发生了滞后，请参阅以下示例：
1. 在主数据库实例上运行 MASTER STATUS 命令，然后查看输出：
文章插图
注意：在示例输出中，主数据库实例将二进制日志写入到文件 mysql-bin.066552 。
2. 在副本数据库实例上运行 SHOW SLAVE STATUS 命令并查看输出：
【Amazon RDS for MySQL 的高副本滞后问题】示例输出 A：
文章插图
在示例输出了A 中， Master_Log_File: mysql-bin.066548 指示副本 IO_THREAD 正在从二进制日志文件 mysql-bin.066548 读取数据。这是因为主数据库实例正在将二进制日志写入文件 mysql-bin.066552 。此输出显示副本 IO_THREAD 滞后了4 个二进制日志。但是， Relay_Master_Log_File 是 mysql-bin.066548 ，这表示副本 SQL_THREAD 正在从与 IO_THREAD 相同的文件中读取数据。这意味着副本 SQL_THREAD 保持同步，但副本 IO_THREAD 出现滞后。
示例输出 B：
文章插图
示例输出 B 显示主日志文件是 mysql-bin-changelog.066552 。这也是主状态的文件参数，意味着 IO_THREAD 与主数据库实例保持一致。在副本输出中， SQL 线程正在执行 Relay_Master_Log_File: mysql-bin-changelog.066530 。这意味着 SQL_THREAD 滞后了12 个二进制日志。
通常， IO_THREAD 不会导致较高的复制延迟，因为 IO_THREAD 仅从主数据库实例读取二进制日志。但是，网络连接和网络延迟会影响服务器之间的读取速度。副本 IO_THREAD 可能会由于高带宽的使用而变慢。
如果副本 SQL_THREAD 是复制延迟的产生原因，那么这些延迟可能是由于以下原因导致的：

主数据库实例上长时间运行的查询
数据库实例类大小或存储空间不足
在主数据库实例上执行的并行查询
同步到副本数据库实例上的磁盘的二进制日志
副本上的 Binlog_format 设置为 ROW
副本创建滞后