关于RDS只读实例延迟分析

只读实例是目前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的消耗情况），防止由于只读实例的规格较小导致了数据延迟。最佳实践：只读实例节点的配置大于或者等于主节点的配置；

---

只读实例延迟场景二：主库的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

这个时候只需要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  |

上面的5类场景我们将会做到诊断报告中，帮助您方便的进行问题的排查。