您好、欢迎来到现金彩票网!
当前位置:红黑大战作弊器助手 > 数据库 >

对应的延时也在逐步上升

发布时间:2019-08-07 13:13 来源:未知 编辑:admin

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

  ?配置上:比如,RAID卡写策略不一致、OS内核参数设置不一致、MySQL落盘策略不一致等,都是可能的原因。

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

  观察数据库实例时,会发现CPU负载过高,IO利用率过高等现象,这些导致SQL Thread应用过慢。这样就可以判断是因为从库自身压力过大引起主从复制延时。

  各种硬件或者资源的配置差异都有可能导致主从的性能差异,从而导致主从复制延时发生:

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

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

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

  DDL导致的主从复制延时的原因和大事务类似,也是因为从库执行DDL的binlog较慢而产生了主从复制延时。

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

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

  考虑尽量统一DB机器的配置(包括硬件及选项参数)。甚至对于某些OLAP业务,从库实例硬件配置需要略高于主库。

  遇到这种情况,我们主要通过SHOW PROCESSLIST或对odb_trx做查询,来找到阻塞DDL语句,并KILL掉相关查询,让DDL正常在从库执行。

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

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

  举个例子,假如主库花费200s更新了一张大表,在主从库配置相近的情况下,从

关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有