一、现象
凌晨对线上一张表添加索引，表数据量太大(1亿+数据，数据量50G以上)，造成主从延迟几个小时，各个依赖从库的系统无法查询数据，最终影响业务。
现在就梳理下主从延迟的原理。
二、原理
根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述，MySQL 主从复制依赖于三个线程：一个线程()，两个线程(和)。主从复制流程如下图：
master 服务器和 slave 服务器连接时，创建以发送数据：
一个对应一个 slave 服务器；
从获取数据时会加锁，获取到数据后，立即释放锁。
当 slave 服务器收到 START_SLAVE 命令时，会创建和：
以拉的方式，从 master 读取事件，并存储到 slave 服务器的中；
从中读取事件并执行；
可以按照自己的节奏读取和更新数据，也可以随意操作复制进程(启动和停止)。
注: 命令成功启动线程后，如果后面或因为某些原因停止，则不会有任何的警告，业务方无法感知。可以通过查看 slave 的 error 日志，或者通过 SHOW SLAVE STATUS 查看 slave 上的线程状态。
通过 SHOW PROCESSLIST 可查看线程状态:
Binlog dump thread:
I/O thread 和 SQL thread:
三、分析
根据上面的原理，由于是单线程()读取数据，单线程()更新数据，而是多线程写入，那么只要写入的频率大于读取更新的频率，就有可能出现主从延迟的情况，如:
写入较高，大于更新速度；
执行某些语句耗时较长，如持有锁等；
执行某些语句时，执行的时间较长，在也执行相同的时间；
此处创建了索引，咨询 DBA，产生的文件有100多G，数据量太大，导致从库一直读取操作产生的事件，而影响到正常的业务事件的更新，从而表现为主从同步延迟。
四、解决方案
从主从延迟的原因来看，解决方案可以从以下几个方向入手：
业务选型，对于无法忍受从库延迟的架构，可选择分布式架构等，避开从库延迟问题
执行时间，对大表进行线上操作尽量选择凌晨等业务量较小的时候
硬件配置，升级从库硬件配置，如SSD
减少请求，增加缓存层，减少读请求落库
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对服务器之家的支持。