十七、Mysql的主从（三）--主从故障监控分析

一、实验环境

System OS: CentOS Linux release 7.6.1810
Mysql version:mysql-5.7.20-linux-glibc2.12-x86_64.tar.gz
master: 3307
slave: 3308
ip:192.168.32.201
主从搭建省略

二、主从的相关线程信息

1、主库相关线程监控

[root@vm01 ~]# mysql -S /data/3307/mysql.sock
[(none)]>show processlist;

每个从库都会有一行dump相关的信息
USER: repl
HOSTS: vm01:45614
Command: Binlog Dump
State: Master has sent all binlog to slave; waiting for more updates
如果现实非以上信息,说明主从之间的关系出现了问题   

2、从库相关线程监控

[root@vm01 ~]# mysql -S /data/3308/mysql.sock -p
[(none)]>show slave status G
*************************** 1. row ***************************
#1)主库相关信息监控
Master_Host: 192.168.32.201
Master_User: repl
Master_Port: 3307
Connect_Retry: 10
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 907
#2)从库中继日志的应用状态
Relay_Log_File: vm01-relay-bin.000002
Relay_Log_Pos: 783
#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)主从延时相关状态(非人为)
Seconds_Behind_Master: 0
#6)延时从库有关的状态(人为设置)
SQL_Delay: 0
SQL_Remaining_Delay: NULL
#7）GTID 复制有关的状态
Retrieved_Gtid_Set: 
Executed_Gtid_Set: 
Auto_Position: 0

三、主从复制故障分析

1、IO-Thread(io线程)

1.1从库连接主库

(1) 用户 密码  IP  port
Last_IO_Error: error reconnecting to master 'repl@192.168.32.201:3307' - retry-time: 10  retries: 7
[root@db01 ~]# mysql -urepl  -p123333  -h 192.168.32.201 -P 3307
ERROR 1045 (28000): Access denied for user 'repl'@'db01' (using password: YES)

原因:
密码错误 
用户错误 
skip_name_resolve
地址错误
端口
#密码错误
[root@vm01 ~]# mysql -urepl -h 192.168.32.201 -P 3307 -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'repl'@'vm01' (using password: YES)
#端口错误
[root@vm01 ~]# mysql -urepl -h 192.168.32.201 -P 33077 -p123
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.32.201' (111)
#用户错误
[root@vm01 ~]# mysql -urepl123 -h 192.168.32.201 -P 3307 -p123
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'repl123'@'vm01' (using password: YES)
#ip地址错误
[root@vm01 ~]# mysql -urepl123 -h 192.168.32.211 -P 3307 -p123
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.32.211' (111)

处理方法

 

#1、停止从库
stop  slave 
#2、清除从库信息
reset slave all 
#3、填写正确的主库信息
change master to 
MASTER_HOST='192.168.32.201',
  MASTER_USER='repl',
  MASTER_PASSWORD='123',
  MASTER_PORT=3307,
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=444,
  MASTER_CONNECT_RETRY=10;
#4、开启主从
start slave

1.2主库连接数上线,或者是主库太繁忙

show slave  staus G 
Last_IO_Errno: 1040
Last_IO_Error: error reconnecting to master 'repl@192.168.32.201:3307' - retry-time: 10  retries: 7
处理思路:
拿复制用户,手工连接一下

[root@vm01 ~]# mysql -urepl -p123 -h 192.168.3.201 -P 3307 
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1040 (HY000): Too many connections
处理方法:
[(none)]>set global max_connections=300;
#在配置文件中添加
[mysqld]
max_connectios=300

1.3、防火墙,网络不通

#1)ping主库的ip
#2)查看防火墙是否阻止

1.4主库的binlog日志损坏或缺失

 

主库缺失日志
从库方面,二进制日志位置点不对
在主库执行reset master操作
3307主库
[(none)]>reset master;
3308从库
[(none)]>show slave status G;
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.000001' at 154, the last event read from '/data/3307/data/mysql-bin.000002' at 154, the last byte read from '/data/3307/data/mysql-bin.000002' at 154.'


主库binlog被删除
主库3307
[root@vm01 ~]# rm -rf /data/3307/mysql-bin.000001
从库3308
[(none)]>show slave status G;
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not open log file'

处理方法：重新构建主从

2、SQL-Thread（SQL线程）

2.1SQL线程故障：

(1)读写relay-log.info 
(2)relay-log损坏,断节,找不到
(3)接收到的SQL无法执行

2.2导致SQL线程故障原因分析：

1. 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响
2.要创建的数据库对象,已经存在
3.要删除或修改的对象不存在  
4.DML语句不符合表定义及约束时.  
归根揭底的原因都是由于从库发生了写入操作.
以下为从库有db数据库了，主库在创建db数据库
Last_SQL_Error: Error 'Can't create database 'db'; database exists' on query. Default database: 'db'. Query: 'create database db'

2.3处理方案

方案一：以从库为核心的处理方案(不建议使用)

 

方法一：
stop slave; 
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突

但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.

方案二：重新构建主从

2.4防止从库写入的方法

 

(1) 可以设置从库只读.
db01 [(none)]>show variables like '%read_only%';
注意：
只会影响到普通用户，对管理员用户无效。
(2)加中间件
读写分离。

四、主从延时监控及原因

主库做了修改操作,从库比较长时间才能追上.

1、外在因素

网络 
主从硬件差异较大
版本差异
参数因素

2、主库因素

 

(1) 二进制日志写入不及时
[rep]>select @@sync_binlog;
(2) CR(cluser replication传统模式)的主从复制中,binlog_dump线程,事件为单元,串行传送二进制日志(5.6 5.5)

1. 主库并发事务量大,主库可以并行,传送时是串行
2. 主库发生了大事务,由于是串行传送,会产生阻塞后续的事务.

解决方案:
1. 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO
2. 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,我们建议还是认为开启GTID
3. 大事务拆成多个小事务,可以有效的减少主从延时.

3、从库因素

SQL线程导致的主从延时
在CR复制情况下: 从库默认情况下只有一个SQL,只能串行回放事务SQL
1. 主库如果并发事务量较大,从库只能串行回放
2. 主库发生了大事务,会阻塞后续的所有的事务的运行

解决方案:
1. 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放.
2. 5.7 版本开始GTID之后,在SQL方面,提供了基于逻辑时钟(logical_clock),binlog加入了seq_no机制,
真正实现了基于事务级别的并发回放,这种技术我们把它称之为MTS(enhanced multi-threaded slave).
3. 大事务拆成多个小事务,可以有效的减少主从延时.
[https://dev.mysql.com/worklog/task/?id=6314]