加入收藏 | 设为首页 | 会员中心 | 我要投稿 衡阳站长网 (https://www.0734zz.cn/)- 数据集成、设备管理、备份、数据加密、智能搜索!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

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

发布时间:2019-05-10 22:35:13 所属栏目:MySql教程 来源:丁顺&张苏宁
导读:MySQL主从复制的延时一直是业界困扰已久的问题。延时的出现会降低主从读写分离的价值,不利于数据实时性较高的业务使用MySQL。 UDB是UCloud推出的云数据库服务,上线已达六年,运营了数以万计的UDB MySQL实例。除了提供高可用、高性能、便捷易用的产品特性
副标题[/!--empirenews.page--]

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语句的情况下,可能会产生主从复制延时。

现象描述

(编辑:衡阳站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读