您的位置 首页 数据库

mysql主从同步延时问题分析

mysql主从同步延时问题分析

主从复制的延时问题主要描述的是:(在出现主从数据同步延时问题时,从库的线程还是能够正常工作运行的)

  • 在主库操作执行语句信息后,从库经过一段时间后才进行操作执行的同步;
  • 在主库操作执行语句信息后,从库经过一段时间后也没有进行相关的操作;

 

主从复制的延时问题造成的影响是:

  • 对于读写分离架构是依赖于主从同步数据环境的,主库作为写节点,从库作为读节点,延时严重会影响从库的读操作体验;
  • 对于高可用架构也是依赖于主从同步数据环境的,主库作为主节点,从库作为备节点,延时严重会影响主备的切换一致性;

主从复制的延时问题出现的原因是:

 

  • 外部因素导致的延时问题:

    - 网络通讯不稳定,有带宽阻塞等情况,造成主从数据传输同步延时;

    - 主从硬件差异大,从库磁盘性能较低,内存和CPU资源都不够充足;

    - 主从配置区别大,从库配置没有优化,导致并发处理能力低于主库;(参考了解)

  • 主库因素导致的延时问题:

- 主要涉及Dump thread工作效率缓慢,可能是由于主库并发压力比较大;

- 主要涉及Dump thread工作效率缓慢,可能是由于从库数量比较多导致;

- 主要涉及Dump thread工作效率缓慢,主要由于线程本身串型工作方式;(利用组提交缓解此类问题-5.6开始 group commit

主库本身可以并发多个事务运行,默认情况下主从同步Dump thread只有一个,只能采用串型方式传输事务日志信息;

从库因素导致的延时问题:

- 从库产生延迟受SQL线程影响较大,由于线程本身串型工作方式导致;

利用不同数据库并行执行事务操作,但是一个库有多张表情况,产生大量并发事务操作,依旧是串型的(5.6开始 多SQL线程回放)

利用logical_clock机制进行并发回放,由于组提交事务是没有冲突的,从库并行执行也不会产生冲突(5.7开始 多SQL线程回放)

根据日志内容信息,获取logical_clock机制的组提交标记信息:(事务级别并发)

 


[root@baimeidashu-01 ~]# cd /data/3307/data/
[root@baimeidashu-01 data]# mysqlbinlog binlog.000001 
#221204 10:27:02 server id 7  end_log_pos 415 CRC32 0xd4ca0729  Anonymous_GTID  last_committed=1       
#221204 12:50:03 server id 7  end_log_pos 603 CRC32 0x06629cba  Anonymous_GTID  last_committed=2        
...省略部分信息...
-- 可以看到日志文件中,有大量last_commited信息,用于标记相同组提交的同步事件信息,并发执行是以事务为单位;
-- 可以看到日志文件中,会利用sequence_number信息,表示一个事务内执行操作顺序;
  • 其他因素导致的延时问题:

- 由于数据库大事务产生的数据同步延时问题;(更新100W数据/尽量切割事务)

- 由于数据库锁冲突机制的数据同步延时问题;(资源被锁无法同步/隔离级别配置RR-锁冲突严重,可调整RC降低延时 索引主从一致)

- 由于数据库过度追求安全配置也会导致同步延时问题(从库关闭双一参数);

主从复制的延时问题监控的方式是:

欢迎来撩 : 汇总all

白眉大叔

关于白眉大叔linux云计算: 白眉大叔

热门文章