RDS for MySQL的Binlog采用row格式，对每一行的数据更新，都会形成row格式Binlog event记录。例如：一个update语句更新100行数据，那么row格式的Binlog中会形成100行update记录，备机或只读回放时会执行100次单行update。

只读节点和备机在回放主库的Binlog event时，会根据表的主键或者二级索引来检索需要更改的行。如果对应表未创建主键，则会产生大量的全表扫描，从而降低了Binlog日志的应用速度，产生复制延迟。

排查方法：

通过show create table xxx，分析执行慢的update和delete语句对应的表，分析是否有主键。

解决方法：

给无主键表增加主键，给缺少二级索引的表增加索引。

DDL操作往往执行时间很长，尤其是表数据量很大时。通常情况下，只读节点或备机回放一个DDL操作的时间和主库花费的时间基本一致。因此，当主机执行了大表的DDL操作后，备机和只读节点在回放该DDL期间，复制时间必然是一致增大的。

解决方法：

该场景为正常现象，等DDL执行完成后，主备复制延迟才能恢复。建议在业务低峰期执行DDL操作。

只读实例上往往有业务流量，如果存在只读长事务正在执行，会阻塞主实例同步过来的相应表的DDL操作，卡在了表MDL锁获取，进而阻塞所有同表的后续Binlog回放，导致复制延迟越来越大。

排查方法：

1. 登录只读节点，使用如下命令，观察是否有长时间执行的事务。
2. select t.*,to_seconds(now())-to_seconds(t.trx_started) idle_time from INFORMATION_SCHEMA.INNODB_TRX t \G;
3. 查看只读节点的MDL锁视图，观察是否有MDL锁冲突。
4. select * from information_schema.metadata_lock_info;
5. 根据MDL锁视图中的线程ID，找到阻塞的session。更多信息，请参见MDL锁视图。

解决方法：

kill只读节点上阻塞DDL操作的长事务，或者在业务侧提交该长事务。

只读实例、DRS灾备实例的规格小于主实例时，一旦主实例写负载升高到一定程度，只读实例或DRS灾备实例会因为自身资源不足，无法及时回放Binlog，导致复制延迟增加。

解决方法：

只读实例或DRS灾备实例扩大规格，与主实例规格匹配。