MySQL的主从延时问题分析【主库】

#背景:MSS结构 S和M的延时有哪些方面导致的

OS CACHE 中还涉及到 2PC机制 以及俩阶段提交 flush和fsync 还要半同步和增强半同步

导语：Seconds_Behind_Master不准确，一般看回访的relog的position和接收到的position对比

		Seconds_Behind_Master: 0

---

          Master_Log_File: mysql-bin.000002
      Read_Master_Log_Pos: 1161
    Relay_Master_Log_File: mysql-bin.000002
      Exec_Master_Log_Pos: 1161

---

M：①主库binlog的刷新不及时导致的

binlog的双一标准中的一没有开启

select @@sync_binlog;

					+---------------+
					| @@sync_binlog |
					+---------------+
					|             1 |
					+---------------+
					1 row in set (0.00 sec)
					------------------------------------------------------------------------------------------------------------------

sync_binlog分析 8.0默认 为 1
我们主库的binlog刷新 根据设置的参数
0 ：只负责刷新到OS CACHE中 让OS CACHE选择刷新到磁盘
1 ： 负责刷新到OS CACHE再刷新到磁盘 才提示binlog commit
大于1 : 是内存中每次多少 一组组刷到OSCACHE 再刷新到磁盘

M：② binlogdump线程串行化 主从复制是主库可开启一个binlogdump线程来发送binlog的

导致延时的主要原因为大事务、并发事务高、DDL
比如大事务迟迟不提交   并发的事务太多了   相关的DDL操作是很大的影响

历史版本解决办法：
5.6版本加入GTID复制模式，但手工配置。DUMP在传输日志时可以并发。
5.7版本GTID做了增强，不手工开启也自动维护匿名的GTID信息。

导语：这里也是吧binlogdump线程根据group commit原理 进行 短时间内提交 不再是类似于数据结构中的队列一样串行化先进先出