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降低延时 索引主从一致）

• 由于数据库过度追求安全配置也会导致同步延时问题（从库关闭双一参数）；

主从复制的延时问题监控的方式是：
mysql主从同步延时的监控方式