云数据库RDS for MySQL主备之间的复制延迟

只读实例规格过小 分析 这类延迟场景经常出现在只读实例规格和主实例规格相差较大，而且只读实例上负载较重，比如只读实例上IOPS过载。只读实例的数据为了和主实例保持同步，采用了MySQL原生的Binlog复制技术，由一个IO线程和一个SQL线程来完成。IO线程负责将主实例的Binlog拉取到只读实例，SQL线程负责将这些Binlog日志应用到只读实例。这两个线程会消耗只读实例的IO资源，所以当只读实例的IOPS配置不够的时候，会导致只读实例的数据出现延迟。

解决方案 建议您升级只读实例规格，避免由于只读实例规格较小导致延迟。RDS推荐只读实例的配置大于或者等于主实例的配置。

情况二：主实例的TPS（Transaction Per Second）过高 分析 由于只读实例与主实例同步采用的是单线程同步，而主实例的压力是并发多线程写入，这样在主实例TPS过高的情况下容易出现只读实例的数据延迟，可以通过观察只读实例的TPS与主实例的TPS性能数据来判断。

解决方案 排查主实例的TPS是否正常，如果TPS过高，则需要对业务进行优化或者拆分，保证主实例的TPS不会导致只读实例出现延迟。

情况三：主实例的大事务 分析 主实例执行一个涉及数据量非常大的update、delete、insert…select、replace…select等事务操作，生成大量的Binlog数据传送到只读实例。只读实例需要花费与主实例相同的时间来完成该事务，进而导致了只读实例的同步延迟。例如在主实例上执行一个持续80秒的删除操作，只读实例进行相同操作时也需要花费很长时间，于是会出现延迟情况。

在只读实例出现大事务导致延迟时，通过show slave status \G命令，可以看到Seconds_Behind_Master不断变化，而Exec_Master_Log_Pos却保持不变，这样可以判断只读实例的SQL线程在执行一个大的事务或者DDL操作。 主实例执行大事务 解决方案 建议将大事务拆分为小事务。例如在delete语句中增加where条件子句，限制每次删除的数据量，将一次删除操作拆分为多次数据量较小的删除操作进行。这样只读实例可以迅速的完成事务的执行，不会造成数据的延迟。

情况四：主实例的DDL语句执行时间长 分析 只读实例和主实例数据同步是串行进行的，如果DDL操作在主实例执行时间很长，那么同样在只读实例也会消耗同样的时间导致延迟。常见操作例如create index、repair table、alter table add column等。 只读实例上执行的查询或未完成的事务阻塞了来自主实例的DDL执行。在只读实例上执行show processlist命令查看SQL线程的状态为waiting for table metadata lock。 解决方案 对于DDL直接引起的只读实例延迟，建议在业务低峰期执行这些DDL。 对于来自主实例的DDL在只读实例上被阻塞的情况，需要使用kill命令终止只读实例上引起阻塞的会话，用来恢复只读实例和主实例的数据同步，详情请参见解决MDL锁导致无法操作数据库的问题。 总结 当只读实例出现延迟的时候，排查方向如下：

在控制台查看监控，检查只读实例的IOPS，确认只读实例是否存在资源瓶颈。 在控制台查看监控，检查只读实例的MySQL_COMDML，确认主实例是否TPS过高。 检查只读实例的Binlog增长量，确定是否存在大事务。 只读实例执行show slave status \G命令，确定是否存在元数据锁。 控制台查看SQL慢日志，是否有alter，repair，create等DDL操作。 检查只读实例是否存在无主键表的删除或者更新操作，可以通过在只读实例执行show engine innodb status\G命令查看，或者执行show open tables后查看输出结果的in_use列里值为1的表。