MySQL主从复制的延时一直是业界困扰已久的问题。延时的出现会降低主从读写分离的价值,不利于数据实时性较高的业务使用MySQL。
UDB是UCloud推出的云数据库服务,上线已达六年,运营了数以万计的UDB MySQL实例。除了提供高可用,高性能,便捷易用的产品特性,团队还平均每天帮助用户解决2 - 3起MySQL实例主从复制延时的问题。从大量实践中我们总结了主从复制延时的各种成因和解决方法,现分享于此。
<强>延时问题的重要性
主从复制机制广泛应用在UDB的内部实现中:UDB创建的从库和主库就采用了“主从复制”的数据复制;另外,UDB的主打产品”UDB MySQL高可用实例”,也是采用2个数据库互为主从的“双主模式”来进行数据复制,而双主模式的核心就是主从复制机制。
如果主从复制之间出现延时,就会影响主从数据的一致性。
在高可用复制场景下,我们在UDB高可用容灾设计上考虑到,若出现主备数据不一致的场景,默认是不允许进行高可用容灾切换的。因为在主备数据不一致的情况下,此时发生容灾切换,且在新的主库写入了数据,那么从业务角度上,会产生意想不到的严重后果。
复制延时问题,不仅在UDB高可用中会带来不良后果,在只读从库的场景下,若从库产生复制延时,也可能会对业务造成一定影响,比如在业务上表现为读写不一致——新增/修改数据查不到等现象。
由此可见,主从复制的延时问题在数据库运营中需要特别关注。一般来说,DBA在库上执行显示奴隶状态,并且观察
“Seconds_Behind_Master”的值,就能够了解当前某个数据库和它的主库之间的数据复制延时。这个值是如此的重要,因此在UDB的监控界面上,我们将这个值单独抽取来,设计了”从库同步延时“监控项,以便于运维人员能够直接在控制台上观察。
<强>生产环境中延时问题的分析及解决
我们将最常见的主从复制延时案例总结为几类,以下是相关案例的现象描述,原因分析和解决方法汇总。
<强>◆案例一:主库DML请求频繁
某些用户在业务高峰期间,特别是对于数据库主库有大量的写请求操作,即大量插入、删除、更新等并发操作的情况下,会出现主从复制延时问题。
<强>现象描述
我们通过观察主库的写操作的每秒的值,会看到主库的写操作的每秒值突然升高,伴随主从复制延时的上升,可以判断是由于主库DML请求频繁原因造成的。
如上图,可以看的出,在17:58分左右每秒突增,查看控制台上的写相关每秒,也有相应提升。而每秒突增的时间,对应的延时也在逐步上升,如下图所示。
<强>原因分析
经过分析,我们认为这是由于主库大量的写请求操作,在短时间产生了大量的binlog。这些操作需要全部同步到从库,并且执行,因此产生了主从的数据复制延时。
从深层次分析原因,是因为在业务高峰期间的主库写入数据是并发写入的,而从SQL线程库为单线程回放binlog日志,很容易造成relaylog堆积,产生延时。
<>强解决思路
如果是MySQL 5.7以下的版本,可以做分片(分片),通过水平扩展(规模)的方法打散写请求,提升写请求写入binlog的并行度。
如果是MySQL 5.7以上的版本,在MySQL 5.7,使用了基于逻辑时钟(集团提交)的并行复制。而在MySQL 8.0,使用了基于写集合的并行复制。这两种方案都能够提升回放binlog的性能,减少延时。
<强>◆案例二:主库执行大事务
大事务指一个事务的执行,耗时非常长。常见产生大事务的语句有:
使用了大量速度很慢的导入数据语句,比如:插入结核病美元,SELECT * FROM结核病美元,数据加载INFILE等;
使用了更新、删除语句,对于一个很大的表进行全表的更新和删除等。
