十七Mysql的主从--主从故障监控分析

Posted yaowx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了十七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): Cant 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): Cant 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 Cant 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)加中间件
读写分离。

 

以上是关于十七Mysql的主从--主从故障监控分析的主要内容,如果未能解决你的问题,请参考以下文章

故障分析 | MySQL 主从不同步分析案例

企业案例 故障修复mysql主从故障解决过程

MHA mysql主从故障转移

MySQL DBA日常故障处理----主从延迟故障(171020)

mysql主从复制故障分析

mysql 主从复制原理,概念,故障的检控/分析/处理