主从复制监控及故障分析

主从复制监控

利用命令监控
show slave status;
相关数据解析

1. 主库相关信息
   Master_Host: 10.0.0.51
   Master_User: repl
   Master_Port: 3307
   Connect_Retry: 10
   Master_Log_File: mysql-bin.000001
   Read_Master_Log_Pos: 444

2. 中继日志执行到的位置点(回放了多少):
   Relay_Log_File: db01-relay-bin.000002
   Relay_Log_Pos: 320

3. 从库线程状态监控
   Slave_IO_Running: Yes
   Slave_SQL_Running: Yes
   报错信息:
   Last_IO_Errno: 0
   Last_IO_Error:
   Last_SQL_Errno: 0
   Last_SQL_Error:

4. 过滤复制有关配置
   Replicate_Do_DB:
   Replicate_Ignore_DB:
   Replicate_Do_Table:
   Replicate_Ignore_Table:
   Replicate_Wild_Do_Table:
   Replicate_Wild_Ignore_Table:

5. 从库回放的relay和主库binlog的对应关系
   Exec_Master_Log_Pos: 444 # 主库对应position号
   Relay_Log_Space: 526 # 从库relay号

6. 主从延时时间
   这个时间只能判断是否有延时 (有/没有) 没有什么参考价值
   Seconds_Behind_Master: 0

7. 延时从库有关配置
   SQL_Delay: 0
   SQL_Remaining_Delay: NULL

8. GTID复制有关信息
   Retrieved_Gtid_Set:
   Executed_Gtid_Set:
   第5章 主从复制故障分析及处理思路

线程故障分析

主要使用mysql slave status;进行监控

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error:

IO线程出现故障分析

1. 连接主库 (connecting)
   连接信息有误
   网络不通
   防火墙
   时间戳
   传输用户没创建
   skip_name_resolve
   解决办法:在从库利用change master 的信息进行登陆查看那个书写错误

2. 请求日志
   日志位置点不对.
   主库日志不完整.
   解决办法: 重新搭建主从
   利用reset master ;命令从建主从
   思路:
   停主库业务,等待从完全同步完
   执行命令 恢复主库:

1.stop slave 
2.change master to  xxxx
3.start slave;

3. 落地日志
   relaylog 丢失
   处理方法:
   停止从库线程
   判断并截取缺失部分日志,恢复到从库 启动从库线程

SQL线程故障

sql线程主要用于 回放relay : 执行SQL语句
故障:

1. relay无法访问
2. 主从版本,SQL_Mode(sql语句协议),参数不一致,系统配置不一致
3. 需要创建的对象已经存在 , 要修改的对象不存在
   原因1: 主从复制不一致,导致SQL故障
   原因2: 从库提前写入
4. 约束冲突
   主要就是: 主键 或者 唯一键

从库提前写解决方法

方法一：

stop slave; 
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;

方法二：

/etc/my.cnf
slave-skip-errors = 1032,1062,1007

主从复制时 跳过指定错误代码
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突

办法三:
从库只读 : 利用参数

read_only         
super_read_only      

方法四: 读写分离中间件

利用工具 : 检查一致性
pt-table-sync
pt-table-checksum
检查延时:
pt-heartbeat

主从延时

发现方法: 延时监控
Seconds_Behind_Master: 0
监控延时的日志 造成延时的位置点

Exec_Master_Log_Pos:    # 主库pos号
Relay_Log_Space:        # 从库relay号

主从延时原因分析

主库

1. 二进制日志书写不及时
   解决方法: 使用双一标准 sync_binlog=1强制写入

2. 主库IO有问题 (硬盘方面)
   解决思路: binlog和数据分离 分开存储 尽量存储在ssd中

3. binlogdump串行模式的原因 Classic replication中 主库可以并发执行事务,但是dump默认是串行工作的 高并发时,大事务多的时候,会延时很高 .
   解决方法: 开启GTID + ROW模式 可以并行传输日志

4. 业务繁忙时 进行表结构变更
   一般是在主从分别使用PT工具进行分开执行

5. 其他原因 网络抖动 主库负载过大 从库太多

从库原因分析

1. relay-log写入不及时 IO问题
   解: 最好是单独存储到ssd上

2. SQL线程回放慢
   Classic replication中,SQL线程只有一个,只能串行回放relaylog.
   高并发时,大事务多的时候,延时较严重.
   5.6 出现了GTID 技术,可以执行多SQL线程,但是只能基于不同database才能.
   5.7 开启GTID,出现了真正的并行SQL回放功能,MTS,基于事务级别并发回放.logical_clock模式