接上篇：/article/1224222?spm=a2c6h.13148508.setting.14.15694f0ejOhNAo
数据库管理中经常会搭建从节点（只读节点）提供读请求给业务使用，减少主库的读压力。在使用只读实例的过程中会遇到延迟问题，如果在本地遇到延迟，如何定位延迟原因？如何快速恢复延迟？
主从复制的原理与开源MySQL一样，主库会通过Binlog dump线程推送日志，备库通过IO线程连接主库接收日志并写入relaylog，再由SQL线程应用relaylog，保持主从同步的关系。
对高可用版本实例备节点只提供高可用切换能力，并不提供读能力。如果要实现读写分离，需要单独购买只读实例，分担读请求。高可用的主备实例之间是双向复制的关系，只是从库不提供读写请求。开通只读实例的前提为RDS必须是高可用版或企业版。
如果备实例出现了复制延迟，一旦主节点挂了则无法切换到备节点做快速恢复。HA探测时也需要探测主备实例的延迟情况，延迟过大时不会做切换，除非有客户强制要求，不怕数据丢失，并且需要客户充分授权。
创建出来的只读实例与主实例时单向同步的关系，从高可用的master节点同步，并不是从备节点同步。如果发生了HA切换，只读节点也会重新调整复制关系，从新的主节点上保持同步。
另外，有些客户通过Flink消费主实例的Binlog，可能会出现空间打满的情况。因为RDS实例也有清理本地日志空间的功能，如果有其他线程占用Binlog，会导致清理线程无法将Binlog清理掉，很可能导致主实例的空间不断增加，直至打满。因此，如果平常有通过第三方的工具消费主实例的Binlog，需要注意此类情况。
上图列出了导致延迟的高频原因：
? 只读实例规格小：CPU或内存比主实例规格小时，很可能会成为瓶颈，影响复制。
? 只读实例规格负载比较高：如果出现很多慢查询，会将只读实例的CPU打满，使复制线程受到影响，导致复制延迟的情况。
? 大事务：大事务会导致额外的风险，比如踩到BUG，此时又出现备库延迟导致无法切换，对业务造成损失，因此，建议尽量将大事务拆分成小事务的操作。
? 锁阻塞：比如做DDL变更，主实例上不一定有元数据锁阻塞出现，但是当DDL语句在只读实例上应用时，如果在应用之前有长的只读查询，会导致DDL变更始终无法得到元数据锁，造成全局阻塞。因此在主实例上做完DDL之后，也需要关注只读实例是否出现元数据锁阻塞的情况。
? 表无主键：对表做操作时，对于只读实例来说是基于全表扫描的方式做更新删除，表没有主键则性能会急剧下降。因此在开发规范里面需要明确为开发人员定义好规则，表必须设置主键。
? 参数设置：比如Mysql开启innodb_adaptive_hash_index（自适应哈希索引），只读实例应用DDL变更之后，需要清理内存中的自适应哈性索引。此时全局锁可能会导致实例短暂夯住，复制延迟的情况也有可能出现。因此，一般建议实例上将参数置为off。
? 表结构设计：不建议在数据库侧将表设计成带有唯一索引，而是通过业务来保持索引的唯一性。
高可用版会在后台创建容灾的只读实例。如果提供业务访问的只读实例挂掉，可以快速换到备用只读进行恢复，对于延迟场景有一定的帮助。对延迟的场景，备用只读实例不提供业务访问，遇到大事务时如果急于恢复，可以找我们确认，比如备用只读实例是否已经没有延迟，如果没有延迟则可以快速切到备用只读上做恢复。但是需要注意，切换时会有连接闪断。
另一种快速恢复的方式直接重建只读实例，但是需要保证开始重建不能再有大事务产生，否则会导致重建完应用增量Binlog时，大事务语句应用时间依然比较久。克隆时间受限于比如是本地盘实例还是云盘实例、数据量的大小等因素因素。ESSD云盘能够快速克隆实例，一般1T、2 T大小仅需半小时。因此，如果对网络时间要求不是特别高的场景，一般建议首先选择ESSD云盘类型的实例。
可以在读写分离的地址上配置延迟阈值，超过阈值之后，新的请求不会再分给超过延迟阈值的只读节点。如果所有只读节点的延迟都很大，则请求可能会全部分发给主实例，需要关注主实例是否能够承受。
针对大事务或元数据锁阻塞，可以执行show slave status\G来查看。
重点关注应用的GTID位点是否卡在某位点上。再通过show processlist查看是否存在元数据锁阻塞，如果没有，则可以往大事务的方向排查。
排查大事务时，主要关注事务的开始时间与会话状态。如果出现fetching rows，则建议查看慢日志对应时间点的操作情况。如果想要确认哪一类操作影响比较多，可以通过 show global status like “Innodb_rows_%”来确认，帮助过滤慢日志时更高效地找到具体方向。
确认了影响较大的行为后，再通过慢日志，洞察日志，解析相应的binlog、查看表结构、查看是否有主键等快速确认问题。
数据库自治服务DAS提供了异常检测功能，基于机器学习和细粒度的监控数据，可以通过比如CPU、IOPS、活跃会话监控异常，对于生产环境RDS，我们可以开通SQL洞察，这样DAS可以结合SQL洞察日志综合进行分析。
相比于传统的基于阈值方式的异常告警检测，DAS的异常检测准确性与时效性都显著优于传统方式。DAS检测到异常时，可以做特征提取、根因分析，还可以做自动SQL优化，kill异常SQL、自动添加索引，评估SQL优化后的效果，实现全闭环的链路。
传统方式下，CPU打满时很多平常执行不慢的SQL会被拖慢，此时慢日志里记录了大量慢SQL，通过记录下CPU等指标打高时的慢SQL来进行根因追溯，该过程效率极低。
而DAS提供的异常检测功能可以在比如CPU等指标飙高时，保存此刻的会话，通过会话结合保留的慢日志和洞察日志，快速分析哪些SQL开销较高，方便快速定位到引起问题的SQL。
毛刺、周期性、趋势、均值便宜、新增等问题均能通过DAS进行检测。
比如类似于OOM的场景，可能执行了SQL之后，内存可能有缓慢上升。
开通SQL洞察后，如果某条SQL引起了OOM，MySQL进程直接挂掉，会导致来不及记录引起问题的SQL，此时如果要追溯，可以通过异常检测来实现。
DAS提供了一键诊断的功能，在自治中心可以选择某个时间段内的异常事件进行查看，点击可进入详情页。
接下篇：/article/1224219?spm=a2c6h.13148508.setting.16.15694f0ejOhNAo
