UCloud高可用数据库UDB主从复制延时的解决

　　MySQL主从复制的延时一直是业界困扰已久的问题。延时的出现会降低主从读写分离的价值，不利于数据实时性较高的业务使用MySQL。

　　UDB是UCloud推出的云数据库服务，上线已达六年，运营了数以万计的UDB MySQL实例。除了提供高可用、高性能、便捷易用的产品特性，团队还平均每天帮助用户解决2-3起MySQL实例主从复制延时的问题。从大量实践中我们总结了主从复制延时的各种成因和解决方法，现分享于此。

　　延时问题的重要性

　　主从复制机制广泛应用在UDB的内部实现中：UDB创建的从库和主库就采用了“主从复制”的数据复制;另外，UDB的主打产品“UDB MySQL高可用实例”，也是采用2个数据库互为主从的“双主模式”来进行数据复制，而双主模式的核心就是主从复制机制。

　　如果主从复制之间出现延时，就会影响主从数据的一致性。

　　在高可用复制场景下，我们在UDB高可用容灾设计上考虑到，若出现主备数据不一致的场景，默认是不允许进行高可用容灾切换的。因为在主备数据不一致的情况下，此时发生容灾切换，且在新的主库写入了数据，那么从业务角度上，会产生意想不到的严重后果。

　　复制延时问题，不仅在UDB高可用中会带来不良后果，在只读从库的场景下，若从库产生复制延时，也可能会对业务造成一定影响，比如在业务上表现为读写不一致——新增/修改数据查不到等现象。

　　由此可见，主从复制的延时问题在数据库运营中需要特别关注。一般来说，DBA在库上执行’SHOW SLAVE STATUS’，并且观察

　　‘Seconds_Behind_Master’的值，就能够了解当前某个数据库和它的主库之间的数据复制延时。这个值是如此的重要，因此在UDB的监控界面上，我们将这个值单独抽取来，设计了“从库同步延时”监控项，以便于运维人员能够直接在控制台上观察。

　　生产环境中延时问题的分析及解决

　　我们将最常见的主从复制延时案例总结为几类，以下是相关案例的现象描述、原因分析和解决方法汇总。

　　◆ 案例一：主库DML请求频繁

　　某些用户在业务高峰期间，特别是对于数据库主库有大量的写请求操作，即大量insert、delete、update等并发操作的情况下，会出现主从复制延时问题。

　　现象描述

　　我们通过观察主库的写操作的QPS的值，会看到主库的写操作的QPS值突然升高，伴随主从复制延时的上升，可以判断是由于主库DML请求频繁原因造成的。

　　如上图，可以看出，在17:58分左右QPS突增，查看控制台上的写相关QPS，也有相应提升。而QPS突增的时间，对应的延时也在逐步上升，如下图所示。

　　原因分析

　　经过分析，我们认为这是由于主库大量的写请求操作，在短时间产生了大量的binlog。这些操作需要全部同步到从库，并且执行，因此产生了主从的数据复制延时。

　　从深层次分析原因，是因为在业务高峰期间的主库写入数据是并发写入的，而从库SQL Thread为单线程回放binlog日志，很容易造成relaylog堆积，产生延时。

　　解决思路

　　如果是MySQL 5.7以下的版本，可以做分片(sharding)，通过水平扩展(scale out)的方法打散写请求，提升写请求写入binlog的并行度。

　　如果是MySQL 5.7以上的版本，在MySQL 5.7，使用了基于逻辑时钟(Group Commit)的并行复制。而在MySQL 8.0，使用了基于Write Set的并行复制。这两种方案都能够提升回放binlog的性能，减少延时。

　　◆ 案例二：主库执行大事务

　　大事务指一个事务的执行，耗时非常长。常见产生大事务的语句有：

　　￭使用了大量速度很慢的导入数据语句，比如：INSERT INTO $tb、SELECT * FROM $tb、LOAD DATA INFILE等;

　　￭使用了UPDATE、DELETE语句，对于一个很大的表进行全表的UPDATE和DELETE等。

　　当这个事务在从库执行回放执行操作时，就有可能会产生主从复制延时。

　　现象描述

　　我们从SHOW SLAVE STATUS的结果进行分析，会发现 Exec_Master_Log_Pos 字段一直未变，且second_behinds_master持续增加，而 Slave_SQL_Running_State 字段的值为”Reading event from the relay log”;同时，分析主库binlog，看主库当前执行的事务，会发现有一些大事务，这样基本可以判定是执行大事务的原因导致的主从复制延时。

　　原因分析

　　当大事务记录入binlog并同步到从库之后，从库执行这个事务的操作耗时也非常长，这段时间，就会产生主从复制延时。