高可用数据库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并同步到从库以后，从库执行这个事务的操做耗时也很是长，这段时间，就会产生主从复制延时。

举个例子，假如主库花费200s更新了一张大表，在主从库配置相近的状况下，从库也须要花几乎一样的时间更新这张大表，此时从库延时开始堆积，后续的events没法更新。

解决思路

对于这种状况引发的主从复制延时，咱们的改进方法是：拆分大事务语句到若干小事务中，这样可以进行及时提交，减少主从复制延时。

◆ 案例三：主库对大表执行DDL语句

DDL全称为 Data Definition Language ，指一些对表结构进行修改操做的语句，好比，对表加一个字段或者加一个索引等等。当DDL对主库大表执行DDL语句的状况下，可能会产生主从复制延时。

现象描述

从现象上，若是从库执行SHOW SLAVE STATUS的输出中，检查Exec_Master_Log_Pos一直未动，在排除主库执行大事务的状况下，那么就有多是在执行大表的 DDL。这一点结合分析主库binlog，看主库当前执行的事务就能够进行确认。

DDL语句的执行状况，能够进一步细分现象来更好地判断：

1. DDL未开始，被阻塞，这时SHOW SLAVE STATUS的结果能检查到Slave_SQL_Running_State为waiting for table metadata lock，且Exec_Master_Log_Pos不变；

2. DDL正在执行，SQL Thread单线程应用致使延时增长。这种状况下观察SHOW SLAVE STATU的结果能发现Slave_SQL_Running_State为altering table，而Exec_Master_Log_Pos不变。

若是有上述的现象，那么颇有可能主库对大表执行DDL语句，同步到从库并在从库回放时，就产生了主从复制延时。

缘由分析

DDL致使的主从复制延时的缘由和大事务相似，也是由于从库执行DDL的binlog较慢而产生了主从复制延时。

解决思路

遇到这种状况，咱们主要经过SHOW PROCESSLIST或对information_schema.innodb_trx作查询，来找到阻塞DDL语句，并KILL掉相关查询，让DDL正常在从库执行。

DDL自己形成的延时难以免，建议考虑：

避免业务高峰，尽可能安排在业务低峰期执行 ； set sql_log_bin=0后，分别在主从库上手动执行DDL（此操做对于某些DDL操做会形成数据不一致，请务必严格测试），这一条若是用户使用云数据库UDB，能够联系UCloud UDB运维团队进行协助操做。

◆ 案例四：主库与从库配置不一致

若是主库和从库使用了不一样的计算资源和存储资源，或者使用了不一样的内核调教参数，可能会形成主从不一致。

现象描述

咱们会详细比对主库和从库的性能监控数据，若是发现监控数据差别巨大，结合查看主从的各个配置状况，便可做出明确判断。

缘由分析

各类硬件或者资源的配置差别都有可能致使主从的性能差别，从而致使主从复制延时发生：

硬件上：好比，主库实例服务器使用SSD磁盘，而从库实例服务器使用普通SAS盘，那么主库产生的写入操做在从库上不能立刻消化掉，就产生了主从复制延时； 配置上：好比，RAID卡写策略不一致、OS内核参数设置不一致、MySQL落盘策略不一致等，都是可能的缘由。

解决思路

考虑尽可能统一DB机器的配置（包括硬件及选项参数）。甚至对于某些OLAP业务，从库实例硬件配置须要略高于主库。

◆ 案例五：表缺少主键或合适索引

若是数据库的表缺乏主键或者合适索引，在主从复制的binlog_format设置为’row’的状况下，可能会产生主从复制延时。

现象描述

咱们进行数据库检查时，会发现：

观察SHOW SLAVE STATUS的输出，发现Slave_SQL_Running_State为Reading event from the relay log； SHOW OPEN TABLES WHERE in_use=1的表一直存在； 观察SHOW SLAVE STATUS的Exec_Master_Log_Pos字段不变； mysqld进程的CPU接近100%（无读业务时），IO压力不大。 这些现象出现的状况下，能够认为极可能有表缺少主键或惟一索引。

缘由分析

在主从复制的binlog_format设置为’row’的状况下，好比有这样的一个场景，主库更新一张500万表中的20万行数据。binlog在row格式下，记录到binlog的为20万次update操做，也就是每次操做更新1条记录。若是这条语句刚好有很差的执行计划，如发生全表扫描，那么每一条update语句须要全表扫描。此时SQL Thread重放将特别慢，形成严重的主从复制延时。

解决思路

这种状况下，咱们会去检查表结构，保证每一个表都有显式自增主键，并协助用户创建合适索引。

◆ 案例六：从库自身压力过大

有时候，从库性能压力很大的状况下，跟不上主库的更新速度，就产生了主从复制延时。

现象描述

观察数据库实例时，会发现CPU负载太高，IO利用率太高等现象，这些致使SQL Thread应用过慢。这样就能够判断是由于从库自身压力过大引发主从复制延时。

缘由分析

部分UCloud用户对于数据库的主从会使用读写分离模式，读请求大部分在从库上执行。在业务有大量读请求的场景下，从库会产生比主库大得多的性能压力。有的用户甚至会在从库运行十分耗费计算资源的OLAP业务，这也对从库形成了更高的性能挑战，这些都会形成主从复制的延时。

解决思路

这种状况下，咱们会建议用户创建更多从库，打散读请求，下降现有从库实例的压力。对于OLAP业务来讲，能够专门创建一个从库来作OLAP业务，并对这个从库，容许适当的主从复制延时。

总结

在使用MySQL的主从复制模式进行数据复制时，主从复制延时是一个须要考量的关键因素。它会影响数据的一致性，进而影响数据库高可用的容灾切换。

在遇到数据库之间出现主从复制延时的状况下，咱们团队基于过往经验，概括出如下方法与流程来协助排查问题：

经过SHOW SLAVE STATUS与SHOW PROCESSLIST查看如今从库的状况。（顺便也可排除在从库备份时的相似缘由）； 若Exec_Master_Log_Pos不变，考虑大事务、DDL、无主键，检查主库对应的binlog及position便可； 若Exec_Master_Log_Pos变化，延时逐步增长，考虑从库机器负载，如IO、CPU等，并考虑主库写操做与从库自身压力是否过大。 UDB的高可用、高性能、便捷易用，能够大量减轻使用者的运维负担。在使用过程当中， UDB团队也会利用多年累积的运营经验，帮助用户及时分析、排查问题缘由，并给出合理的解决方法。