MySQL主从延迟现象及原理解析详解
发布时间：2022-02-24 05:59:41 所属栏目：MySql教程 来源：互联网
导读：MySQL主从延迟现象及原理分析详解： 一、现象 凌晨对线上一张表添加索引，表数据量太大(1亿+数据，数据量50G以上)，造成主从延迟几个小时，各个依赖从库的系统无法查询数据，最终影响业务。 现在就梳理下主从延迟的原理。 二、原理 根据 MySQL 官方文档 My
|
MySQL主从延迟现象及原理分析详解： 一、现象 凌晨对线上一张表添加索引，表数据量太大(1亿+数据，数据量50G以上)，造成主从延迟几个小时，各个依赖从库的系统无法查询数据，最终影响业务。 现在就梳理下主从延迟的原理。 二、原理 根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述，MySQL 主从复制依赖于三个线程：master一个线程(Binlog dump thread)，slave两个线程(I/O thread和SQL thread)。主从复制流程如下图： master 服务器和 slave 服务器连接时，创建Binlog dump thread以发送bin log数据： 一个Binlog dump thread对应一个 slave 服务器； Binlog dump thread从bin log获取数据时会加锁，获取到数据后，立即释放锁。 当 slave 服务器收到 START_SLAVE 命令时，会创建I/O thread和SQL thread： 通过 SHOW PROCESSLIST 可查看线程状态: Binlog dump thread: mysql> SHOW PROCESSLISTG *************************** 1. row *************************** Id: 2 User: root Host: localhost:32931 db: NULL Command: Binlog Dump Time: 94 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL I/O thread 和 SQL thread: mysql> SHOW PROCESSLISTG *************************** 1. row *************************** Id: 10 User: system user Host: db: NULL Command: Connect Time: 11 State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 11 User: system user Host: db: NULL Command: Connect Time: 11 State: Has read all relay log; waiting for the slave I/O thread to update it Info: NULL 三、分析 根据上面的原理，由于slave是单线程(I/O thread)读取数据，单线程(SQL thread)更新数据，而master是多线程写入，那么只要master写入的频率大于slave读取更新的频率，就有可能出现主从延迟的情况，如: master写入tps较高，大于slave更新速度； slave执行某些语句耗时较长，如持有锁等； master执行某些DDL语句时，执行的时间较长，在slave也执行相同的时间； 此处创建了索引，咨询 DBA，产生的bin log文件有100多G，数据量太大，导致从库I/O thread一直读取DDL操作产生的bin log事件，而影响到正常的业务DML事件的更新，从而表现为主从同步延迟。 四、解决方案 从主从延迟的原因来看，解决方案可以从以下几个方向入手： 业务选型，对于无法忍受从库延迟的架构，可选择分布式架构等，避开从库延迟问题 执行时间，对大表进行线上DDL操作尽量选择凌晨等业务量较小的时候 硬件配置，升级从库硬件配置，如SSD 减少请求，增加缓存层，减少读请求落库 总结 以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对亿速云的支持。 （编辑：应用网_丽江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330468号