主从复制故障处理
Posted wangxiang135
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了主从复制故障处理相关的知识，希望对你有一定的参考价值。
目录
主从复制线程管理命令
启动所有线程
start slave;
关闭所有线程
stop slave;
单独启停SQL线程
start slave sql_thread;
stop slave sql_thread;
单独启停IO线程
satrt slave io_thread;
stop slave io_thread;
IO 线程故障
连接主库: connecting
- 网络：
-连接信息错误或变更了,防火墙,连接数上线
排查思路
使用复制用户手工登录
[root@db01 data]# mysql -urepl -p12321321 -h 10.0.0.51 -P 3307
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user ‘repl‘@‘db01‘ (using password: YES)
[root@db01 data]# mysql -urep -p123 -h 10.0.0.51 -P 3307
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user ‘rep‘@‘db01‘ (using password: YES)
[root@db01 data]# mysql -urepl -p123 -h 10.0.0.52 -P 3307
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can‘t connect to MySQL server on ‘10.0.0.52‘ (113)
[root@db01 data]# mysql -urepl -p123 -h 10.0.0.51 -P 3309
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can‘t connect to MySQL server on ‘10.0.0.51‘ (111)
解决此类问题
1. stop slave
2. reset slave all;
3. change master to
4. start slave1.
请求日志，接收日志（Binlog）
- binlog 没开
- binlog 损坏,不存在
- binlog日志不完整，不连续
- 从库请求起点问题
- 主从server_id(server_uuid）相同
- relaylog问题
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘could not find next log; the first event ‘mysql-bin.000007‘ at 967, the last event read from ‘/binlog/3306/mysql-bin.000007‘ at 1329, the last byte read from ‘/binlog/3306/mysql-bin.000007‘ at 1329.‘
解决此类问题
- 找个业务不繁忙期间，停止业务5分钟
如果业务繁忙期间做，有可能会导致数据库hang死
- 等待从库重新放完所有的主库日志
- 主库reset master,并查看位置点信息show binary logs;
- 从库重新同步主库日志
stop slave ;
reset slave all;
CHANGE MASTER TO
MASTER_HOST=‘10.0.0.12‘,
MASTER_USER=‘repl‘,
MASTER_PASSWORD=‘123456‘,
MASTER_PORT=3306,
MASTER_LOG_FILE=‘mysql-bin.000001‘,
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
show slave statusG;
查询binlog的相关命令
查看二进制日志位置
mysql> show variables like ‘%log_bin%‘;
查看所有已存在的二进制日志
mysql> show binary logs;
mysql> flush logs;
mysql> show binary logs;
查看正在使用的二进制日志
mysql> show master status ;
或者使用第三方pt工具
SQL线程故障
SQL主要做什么工作？
回放relay-log中的日志。可以理解为执行relay-log SQL
relay-log故障本质
一条SQL语句为什么执行失败?
- insert delete update ---> t1 表 操作的对象不存在
- create table wx ---> wx 操作的对象已存在
- 约束冲突(主键,唯一键,非空..)
- 参数，版本问题
以上问题大几率出现从库写入或者双主结构中，或者参数，版本不一致的问题
解决此类问题
合理处理方法:
- 把握一个原则,一切以主库为准进行解决
- 如果出现问题,尽量进行从库反操作
- 最直接稳妥办法,重新构建主从
解决思路1：
进行从库反操作。重启线程
drop database wx;
start slave;
解决思路2：
stop slave;
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
解决思路3（暴力）：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
避免一定程度的SQL线程故障
- 从库只读
read_only
super_read_only
- 使用读写分离中间件
- atlas
- mycat
- ProxySQL
- MaxScale
主从延时监控及原因
什么是主从延时？
主库发生了操作，从库‘很久’才跟上。
主库方面原因的监控
主库:
3306 [(none)]>show master status;
+------------------+----------+--------------+------------------+----------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000001 | 319 | | | 7d1fda1c-c705-11ea-9af4-000c2925c00d:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
从库:
db02 [(none)]>show slave statusG;
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 319
Retrieved_Gtid_Set: 7d1fda1c-c705-11ea-9af4-000c2925c00d:1
Retrieved_Gtid_Set: 7d1fda1c-c705-11ea-9af4-000c2925c00d:1
Executed_Gtid_Set: 13ce935d-c710-11ea-861d-000c29753b09:1,
7d1fda1c-c705-11ea-9af4-000c2925c00d:1:5-6
主从延时的监控
粗略：
show slave statusG;
Seconds_Behind_Master: 0
准确：
日志量：主库binlog位置点：从库relay执行的位置点
如何计算延时的日志量：
show master status;
cat /data/3306/relay-log.info
从库方面原因监控:
拿了多少:
db02 [(none)]>show slave statusG;
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 319
主从复制延时原因
主库方面原因
- 外部原因：网络，硬件配置，主库业务繁忙，从库太多
主库业务繁忙：
1.拆分业务（分布式）：组件分离，垂直拆分，水平拆分
2.大事务的拆分：比如，1000w业务，拆分为20次执行
2.内部原因
1.二进制更新问题：
binlog写入不及时
sync_binlog=1
2.本版5.7之前版本，没有开GTID之前，主从可以并发事务，但是dump传输时串行传输binlog：
会导致，事务量，由于dump_t 是串型工作的，大事务时会出现比较严重延时，导致传送日志较慢
如何解决问题?
5.6+ 版本，手工开启GTID，事务在主从的全局范围内就有了唯一标志。
5.7+ 版本，无需手工开启gdit，系统会自动生成匿名的GTID信息
有了GTID之后，就可以实现并发（使用Group commit方式）传输binlog
3.主库极其繁忙
慢语句
锁等待
从库个数
网络延时
以上是关于主从复制故障处理的主要内容，如果未能解决你的问题，请参考以下文章