一 简介:今天咱们来汇总下如何避免主从延迟
二 方案:
1 集群硬件配置统一,磁盘组更好(SSD最佳),更大的内存
2 linux系统+mysql的配置参数已经优化
3 mysql从库没有任何慢语句进行IO的消耗
4 mysql主库业务唯一,不把多个频繁的业务集中在同一DB上,同时业务本身也进行了优化,减少了和数据库的交互.就是一句话:减少主库事务
三 架构
1 mysql5.7 半同步复制
2 pxc/mgr 强一致性架构
上面两种架构都可以强制消除延迟现象,但是会导致主库的性能变低
四 问题 seconds_behind_master 不准么？
对于这个问题我们要进行分析:
定义 Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较，而得到的这么一个差值
分析 我们可知 在主从复制延迟瓶颈基本在于sql_thread瓶颈,所以5.7出现了并行复制的情况加大了sql_thread线程的数量,但是从未考虑io_thread
1 io_thread 瓶颈和异常问题
2 较大的事务可能导致延迟波动
定位问题 如果主从网络发生问题或者生成的binlog量太大导致接收慢,这时候seconds_behind_master依然是0,但是实际已经有延迟了 这种情况只在多机房走专线出现过
代码解析: 只要sql_state状态为 apply all relay log 和io_thread为YES,就代表seconds_behind_master为0
解决问题
1 脚本解决 同时监控复制进程和seconds_behind_master 可适用于大部分情况
2 采用 pt-heartbeat监控
1，在主上创建一张heartbeat表，按照一定的时间频率更新该表的字段（把时间更新进去）。
2，从主库连接到从上检查复制的时间记录，和从库的当前系统时间进行比较，得出时间的差异
相关问题 :这是由主库发出的动作,一旦主库负载压力过大,或者网络连通性出现问题就会异常
3 采用其他方式进行监控
1 普通主从复制
Master_Log_File == Relay_Master_Log_File && Read_Master_Log_Pos == Exec_Master_Log_Pos。
计算差值 可以定位相差的文件数 和 位置数,但是一旦落后多个文件,位置比较就毫无意义了
根据过滤输出的两段差值分别输出 相差的文件个数和相差的位置数量
不足 没办法从时间角度观察进度
2 GTID 复制
Retrieved_Gtid_Set == Executed_Gtid_Set。
计算差值 可以定位相差多少个事务
过程
1 根据 Retrieved_Gtid_Set 定位主 UUID 和最大事务
2 根据 上一步的UUID 定位 Executed_Gtid_Set 最大事务
3 进行 最大事务的比较
不足 :没办法从时间角度进行观察落后进度
3 补充
1 proxysql还是采用的seconds_behind_master进行的读写分离判断
2 上面几种方式大多采用show slave status方式进行计算,一旦卡主,就没办法获得值了
补充