浅谈mysql主从复制延迟
1 概念解读
需要知道以下几点
1 mysql的主从同步上是异步复制，从库是串行化执行
2 mysql 5.7的并行复制能加速从库重做的速度，进一步缓解 主从同步的延迟问题
3 mysql的Seconds_Behind_Master代表延迟的状态 0为无延迟
4 mysql的Slave_SQL_Running_State:状态在异常时会有所表现，延迟出现的时候要尤为注意
5 Master_Log_File = Relay_Master_Log_File，Read_Master_Log_Pos = Exec_Master_Log_Pos 同样可认为 主从 0 延迟
2 场景分析
1 sql和io 线程正常 延迟一会就恢复，这样大多是由于短暂的事务引起的，
1 短暂小事务 不用关心
2 定期出现，需要具体分析
2 sql和io线程正常 磁盘 IO 过高 iowait很高，达到10%以上Exec_Master_Log_Pos 一直在变 证明 从库一直在追赶主库 分为几种情况
1 从库的机器硬件性能很差
2 主库执行的DML没有应用索引或者应用不当导致耗时很久，在从库回放时候很慢
3 HP机器RAID卡充放电不正常 会导致这种问题
4 主库业务过于集中,例如一台机器多个DB,导致DML非常频繁
5 从库采用ext4文件系统,jdb2占用IO太高
3 sql和io线程正常 延时瞬时很高,然后又恢复正常
4 sql和io线程正常 Slave_SQL_Running_State：Reading event from relay log，Exec_Master_Log_Pos 一直不变 分为几种情况
1 操作的表是myisam表或者没有索引
2 执行了大事务(包含DDL） 可能导致这种情况，经常见于删除大量数据场景
5 Slave_SQL_Running_State：waiting for table flush ,延迟 一直增加
1 在从库，当xtarbackup备份的时候,会flush table with read lock，这时候如果从库有慢查询在进行，会导致一直等待，waiting for table flush，延迟不断增加
6 一台从库无延迟,另一台从库出现延迟
1 在同等硬件配置情况下,主要出现在一台数据库需要写中继日志,以提供canal解析binlog服务。
7 外键检测延迟问题
1 这种情况比较少见，是我在网上搜到的案例
8 并行复制导致延迟
1 常见于大表的DDL操作
3 解决方法
前提 进行 binlog分析
1 读取Exec_Master_Log_Pos mysqlbinlog进行卡主点的解析 mysqlbinlog -vvv --base64-output=decode-rows -j 位置 mysql-bin文件 | more 确定 操作的table和DML语句 还可以根据生成的sql文本大小估算下数据量
2 针对问题2的解决方案
1 更换硬件
2 优化主库的慢日志语句，确保从库能更快的运行
3 更换RAID卡电池
3 针对问题3的解决方案
对于毛刺现象的从库延时问题 最大的可能来自于时间跨度较大的执行事务(常见于长时间才提交的事务)
4 针对问题4 的解决方案
1 将myisam表转换为innodb表
2 添加主键
3 将大事务进行拆分，尤其是大量的delele操作，很容易导致这种问题
4 将业务进行优化
1 研发进行业务优化
2 业务库进行拆分
5 针对问题4的解决方案
1 优化在从库的查询 并且调整备份数据库时间
6 针对问题6的解决方案
1 升级硬件 2 减少主库事务
7 针对问题7 8的解决方案
1 去掉外键检测 2 对于DDL没太好办法
8 通用解决方案
1 如果在数据量不是很大的情况下，重做从库是最快的方式
2 可以尝试下 提交方式设为 2 禁止写binlog等方式尝试加速复制（感觉效果并不是太好）经朋友补充 添加 innodb_flush_log_at_trx_commit=2 sync_binlog=500 效果不错，可以提升速度
3 mysql 5.7的并行复制可以加速复制，非常建议使用