主从复制故障处理

主从复制线程管理命令

启动所有线程
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 status\G;

查询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 status\G;
              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  status\G;
Seconds_Behind_Master: 0

准确：
日志量：主库binlog位置点：从库relay执行的位置点
如何计算延时的日志量：
show master status;
cat /data/3306/relay-log.info

从库方面原因监控:

拿了多少:

db02 [(none)]>show slave status\G;
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.主库极其繁忙
慢语句
锁等待
从库个数
网络延时

posted @ 2020-07-17 11:42 国际一级退堂鼓鼓手阅读(264) 评论(0) 编辑收藏举报

刷新页面返回顶部

国际一级退堂鼓鼓手

主从复制故障处理

主从复制线程管理命令

IO 线程故障

连接主库: connecting

排查思路

解决此类问题

请求日志，接收日志（Binlog）

解决此类问题

查询binlog的相关命令

SQL线程故障

SQL主要做什么工作？

relay-log故障本质

解决此类问题

避免一定程度的SQL线程故障

主从延时监控及原因

什么是主从延时？

主库方面原因的监控

主从延时的监控

从库方面原因监控:

主从复制延时原因

主库方面原因

公告