mysql案例~mysql主从复制延迟概总

浅谈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线程正常 Slave_SQL_Running_State：Reading event from relay log，Exec_Master_Log_Pos 一直不变 分为几种情况

1 操作的表是myisam表或者没有索引

2 执行了大事务(包含DDL） 可能导致这种情况，经常见于删除大量数据场景

4 Slave_SQL_Running_State：waiting for table flush ,延迟 一直增加

1 在从库，当xtarbackup备份的时候,会flush table with read lock，这时候如果从库有慢查询在进行，会导致一直等待，waiting for table flush，延迟不断增加

5  一台从库无延迟,另一台从库出现延迟

1 在同等硬件配置情况下,主要出现在一台数据库需要写中继日志,以提供canal解析binlog服务。

6  外键检测延迟问题

1 这种情况比较少见，是我在网上搜到的案例

7  并行复制导致延迟

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 的解决方案

1 将myisam表转换为innodb表

2 添加主键

3 将大事务进行拆分，尤其是大量的delele操作，很容易导致这种问题

4 将业务进行优化

1 研发进行业务优化

2 业务库进行拆分

4 针对问题4的解决方案

1  优化在从库的查询 并且调整备份数据库时间

5 针对问题5的解决方案

1 升级硬件 2 减少主库事务

6 针对问题6 7的解决方案

1 去掉外键检测 2 对于DDL没太好办法

7 通用解决方案

1  如果在数据量不是很大的情况下，重做从库是最快的方式

2 可以尝试下 提交方式设为 2 禁止写binlog等方式尝试加速复制（感觉效果并不是太好）经朋友补充  添加  innodb_flush_log_at_trx_commit=2 sync_binlog=500  效果不错，可以提升速度

3 mysql 5.7的并行复制可以加速复制，非常建议使用

这是作者关于主从延迟的一些见解 欢迎点评