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
————————————————------------------------------------------------------------------------------------------------
## S：① IO线程导致
从库IO比较慢。relay 落地慢。原因可能是机械盘更替为固态盘
## S ：② SQL 线程： 串行回放。
主库可以并行事务，从库SQL线程串行回放。 害怕： 并发事务高、大事务、DDL

导语：这个原因改进了好几次 串行化 》 基于库处理 》 基于时间片处理 （WriteSet）

5.6 版本： 开启GTID后，可以多SQL线程，只能针对不同的库的事务进行并行SQL恢复。
5.7 版本： 做了增强，基于逻辑时钟的并行回放。MTS。

my.cnf配置文件：
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
slave-parallel-workers=4

slave-parallel-type=LOGICAL_CLOCK

master_info_repository=TABLE
relay_log_info_repository=TABLE

看你们怎么优化了 有几处建议

隔离级别设置为 RC 减少并发
事务上：减少大事务
用DDL —> gh-ost pt-osc
设备：网络优质
配置上：MTS+GC