个人不是很喜欢在技术上跟人互喷，尤其是不在同一个岗位上的人。一方面本人的性格如此，另一方面，我自身的口水也确实是不行，人生经历了第一次的双11洗礼，在大促的环境下，总算知道了有些东西是否应该规避，这次的大促中，因为读库的延时，导致了主从这块的延时差异几乎持续了6个小时，这个也确实是跟我经验有关系。虽然对方的话语还是有点难听，但自己没有很清晰的对这个主从延时进行剖析，就是自己的问题，在阿里的论坛上看到对只读延时的剖析，觉得写的很好，分享出来，同时在这里做了一下对应的排版，希望遇到这问题的人，可以有所明白，也希望能看到这篇文章的人，能有所收获，IT道路本身就容易受到委屈，受到委屈了没有关系，做好自己的事情先。

原文分享--个人经过排版了一下

只读实例是目前RDS用户实现数据读写分离的一种常见架构，用户只需要将业务中的读请求分担到只读节点上，就可以缓解主库查询压力，同时也可以把一些OLAP的分析查询放到另外的只读节点上，减小复杂统计查询对主库的冲击，RDS只读节点架构图如下：

由于RDS只读节点采用原生的MySQL Binlog复制技术，那么延迟必然会成为他成立之初就会存在的问题。延迟会导致只读节点与主库的数据出现不一致，进而可能造成业务上逻辑的混乱或者数据不正确；另外只读实例延迟同样也会触发binlog堆积，导致只读实例的空间迅速消耗完，这样会导致只读实例被锁定，锁定之后应用则无法完成读操作。 
 
 
最近也收到了很多用户关于只读实例延迟的问题反馈，下面将会分析RDS只读实例出现延迟的几种常见场景，希望能够帮助用户理解和处理只读节点的延迟，更好地使用只读节点：

一．只读节点规格过小(10%)
二．主库的TPS过高(20%)
三．主库的DDL(alter、drop、repair)(40%)
四．主库大事务(insert..select)(20%)
五．其他（无主键，主机压力）(10%) 

数据图:

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

只读实例延迟场景一：只读实例规格配置过小导致slave延迟，这类延迟场景的出现往往主节点购买的一个非常大规格的配置，而只读节点却购买了一个最小规格的配置（240M内存/150 IOPS）。 
分析：只读节点的数据为了和主节点保持同步，采用了MySQL原生的binlog复制技术，由一个IO线程和一个SQL线程来完成，IO线程负责将主库的binlog拉取到只读节点，SQL线程负责消费这些binlog日志，这两个线程会消耗掉只读节点的IO资源，所以当只读节点IOPS配置不够的时候，则会导致只读节点的数据出现延迟：

可以通过只读节点性能监控来判断是否已经达到只读实例的资源配额:

所以当这样的延迟情况的发生的时候，需要用户升级只读实例的规格（可以参考主库此时的IOPS的消耗情况），防止由于只读实例的规格较小导致了数据延迟。最佳实践：只读实例节点的配置大于或者等于主节点的配置；

这里补充一下:

mysql的主从复制都是单线程的操作，主库对所有DDL和 DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高，下一步， 问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺 序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要 执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什 么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

只读实例延迟场景二：主库的TPS（insert，update，delete）过高导致只读节点延迟，这一类的延迟也是非常常见的延迟，由于只读节点与主库的同步采用的是单线程同步，而主库的压力是并发多线程写入，这样势必会导致只读节点的数据延迟，可以通过观察只读节点的TPS与主节点的TPS性能数据来完成判断： 
主库的TPS性能数据：

只读节点的TPS性能数据：

针对这样场景的延迟，开启只读节点的并行复制是解决这一问题的根本方法，但目前RDS线上还没有大规模的使用，所以用户需要排查主库的这些写入压力是否正常，如果正常则需要对业务进行优化或者拆分，保证主库的TPS不会导致slave出现延迟。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

只读实例延迟场景三：主库的DDL(alter、drop、repair、create)导致只读节点延迟，这种延迟是非常常见的延迟， 可以分为两类： 
第一类：只读节点与主库的数据同步是串行进行的，如果DDL操作在主库执行时间很长，那么同样在备库也会消耗同样的时间，比如在主库对一张500W的表添加一个字段耗费了10分钟，那么在只读节点上也同样会耗费10分钟，所以只读节点会延迟600S，其他常见操作比如create index，repair table，alter table add column； 
范例：只读节点出现延迟

主库备库同样出现延迟：

查看主库这这一段时间是否存在DDL，发现主库在添加索引：

第二类：由于只读节点上会有用户的查询在上面运行，所以如果只读节点上有一个执行时间非常长的的查询正在执行，那么这个查询会堵塞来自主库的DDL，直到查询结束为止，进而导致了只读节点的数据延迟。在只读节点上可以通过执行show processlist命令查看连接的状态处于： Waiting for table metadata lock

为什么要标红这个，因为，这个就是他妈的坑货害的我主从延时这么大的根本原因,而我经验的问题，却没有在当时的情况下，通过processlist查看是否有metadata lock，经验问题，希望看到此处的朋友，能用心记一下

这个时候只需要kill掉只读节点上的大查询就可以恢复只读节点与主节点的数据同步。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

只读实例延迟场景四：主库执行大事务大事务导致延迟，这一种延迟场景也是比较常见的，比如在主库执行一个大的update、delete、insert ….select的事务操作，产生大量的binlog传送到只读节点，只读节点需要花费与主库相同的时间来完成该事务操作，进而导致了只读节点的延迟。只读实例发生延迟，在只读节点执行show slave status\G命令，可以通过两个关键的位点参数来判断只读实例上是否在执行大事务：Seconds_Behind_Master不断增加， 但是Exec_Master_Log_Pos却没有发生变化，这样则可以判断只读节点的SQL线程在执行一个大的事务或者DDL操作。 
例如下面的例子，用户在主库执行了一条insert ..select非常大的插入操作，该操作产生了近几十G的binlog文件传输到只读节点，进而导致了只读节点出现应用binlog延时

针对此类大事务延迟的场景，需要将大事务拆分成为小事务进行，这样只读节点就可以迅速的完成事务的执行，不会造成数据的延迟。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

只读实例延迟场景五：其他只读实例出现延迟的情况比如只读实例的主机IO压力出现异常，或者对无主键的表进行删除（可以参考mysql主键的缺少导致备库hang），RDS目前已经支持对表添加隐士主键，但是对于以前历史创建的表需要进行重建才能支持隐士主键。 
综上所述，把目前RDS只读实例出现延迟的场景都进行了分析，可以简单归纳一下，当只读实例出现延迟后，通过

一看只读节点IOPS定位是否存在资源瓶颈二看只读节点的binlog增长量定位是否存在大事务三看只读节点的commdml性能指标，对比主节点的commdml定位是否是主库写入压力过高导致四看只读节点show full processlist，判断是否有Waiting for table metadata lock和alter，repair，create等ddl操作

如果上述四看都还没有发现问题，那么在最后再检查一下只读节点是否存在无主键表的删除或者更新操作，可以通过在只读节点执行：show engine innodb status\G或者show open tables状态为in_use为1的表： 
mysql> show open tables; 
+————–+———————+——–+————-+ 
| Database     | Table               | In_use | Name_locked | 
+————–+———————+——–+————-+ 
| aixuedai_web   | sd_repay            |      4 |       0 | 
| mysql         | slow_log             |      0 |       0 | 
| dw           | dw_acc_sd_expectpay  |     1 |      0  |

差点忘了摘录地址：

https://bbs.aliyun.com/read/250956.html

文章由阿里的团队所发，论据充分而有条理。