主从复制监控
利用命令监控
show slave status;
相关数据解析
-
主库相关信息
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 -
中继日志执行到的位置点(回放了多少):
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 320 -
从库线程状态监控
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
报错信息:
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error: -
过滤复制有关配置
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: -
从库回放的relay和主库binlog的对应关系
Exec_Master_Log_Pos: 444 # 主库对应position号
Relay_Log_Space: 526 # 从库relay号 -
主从延时时间
这个时间只能判断是否有延时 (有/没有) 没有什么参考价值
Seconds_Behind_Master: 0 -
延时从库有关配置
SQL_Delay: 0
SQL_Remaining_Delay: NULL -
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线程出现故障分析
-
连接主库 (connecting)
连接信息有误
网络不通
防火墙
时间戳
传输用户没创建
skip_name_resolve
解决办法:在从库利用change master 的信息进行登陆查看那个书写错误 -
请求日志
日志位置点不对.
主库日志不完整.
解决办法: 重新搭建主从
利用reset master ;命令从建主从
思路:
停主库业务,等待从完全同步完
执行命令 恢复主库:
1.stop slave
2.change master to xxxx
3.start slave;
- 落地日志
relaylog 丢失
处理方法:
停止从库线程
判断并截取缺失部分日志,恢复到从库 启动从库线程
SQL线程故障
sql线程主要用于 回放relay : 执行SQL语句
故障:
- relay无法访问
- 主从版本,SQL_Mode(sql语句协议),参数不一致,系统配置不一致
- 需要创建的对象已经存在 , 要修改的对象不存在
原因1: 主从复制不一致,导致SQL故障
原因2: 从库提前写入 - 约束冲突
主要就是: 主键 或者 唯一键
从库提前写解决方法
方法一：
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号
主从延时原因分析
主库
-
二进制日志书写不及时
解决方法: 使用双一标准sync_binlog=1强制写入 -
主库IO有问题 (硬盘方面)
解决思路: binlog和数据分离 分开存储 尽量存储在ssd中 -
binlogdump串行模式的原因 Classic replication中 主库可以并发执行事务,但是dump默认是串行工作的 高并发时,大事务多的时候,会延时很高 .
解决方法: 开启GTID + ROW模式 可以并行传输日志 -
业务繁忙时 进行表结构变更
一般是在主从分别使用PT工具进行分开执行 -
其他原因 网络抖动 主库负载过大 从库太多
从库原因分析
-
relay-log写入不及时 IO问题
解: 最好是单独存储到ssd上 -
SQL线程回放慢
Classic replication中,SQL线程只有一个,只能串行回放relaylog.
高并发时,大事务多的时候,延时较严重.
5.6 出现了GTID 技术,可以执行多SQL线程,但是只能基于不同database才能.
5.7 开启GTID,出现了真正的并行SQL回放功能,MTS,基于事务级别并发回放.logical_clock模式
网友评论