DevOps开发运维
成长之路

MySQL主从故障监控分析

监控主从复制状态

[root@xiaoyong tmp]# mysql -uroot -p -S /data/3308/mysql.sock
mysql [(none)]>show slave status \G
主库相关信息监控:
Master_Host: 10.0.0.200
Master_User: repl
Master_Port: 3307
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 444
从库中继日志的应用状态
Relay_Log_File: xiaoyong-relay-bin.000001
Relay_Log_Pos: 4
从库复制线程有关的状态
Slave_IO_Running: Connecting
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: 
主从延时相关状态(非人为)
Seconds_Behind_Master: 0
延时从库有关的状态(人为) 
SQL_Delay: 0
SQL_Remaining_Delay: NULL
GTID复制有关的状态
Master_SSL_Crlpath: 
Retrieved_Gtid_Set: 
Executed_Gtid_Set:

IO线程故障

连接主库

原因:
密码错误 
用户错误 
skip_name_resolve
地址错误
端口
处理方法:
[root@xiaoyong tmp]# mysql -uroot -p -S /data/3308/mysql.sock
mysql [(none)]>stop slave
mysql [(none)]>reset slave all 重置从库信息
[root@xiaoyong tmp]# mysql -uroot -p -S /data/3307/mysql.sock
mysql [rep]>show master status \G
File: mysql-bin.000003
Position: 1370
[root@xiaoyong tmp]# mysql -uroot -p -S /data/3308/mysql.sock
mysql [(none)]>CHANGE MASTER TO
MASTER_HOST='10.0.0.200',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=1370,
MASTER_CONNECT_RETRY=10;
mysql [(none)]>start slave

主库连接数上限

处理方法:
[root@xiaoyong tmp]# mysql -uroot -p -S /data/3307/mysql.sock
db01 [(none)]>set global max_connections=300;
[root@xiaoyong tmp]# mysql -uroot -p -S /data/3308/mysql.sock
db01 [(none)]>show slave staus \G 
Last_IO_Errno: 1040
Last_IO_Error: error reconnecting to master 'repl@10.0.0.51:3307' - retry-time: 10 retries: 7
[root@db01 ~]# mysql -urepl -p123 -h 10.0.0.200 -P 3307 
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1040 (HY000): Too many connections


请求二进制日志

主库缺失日志
从库方面,二进制日志位置点不对
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.'
注意: 在主从复制环境中,严令禁止主库中reset master; 可以选择expire进行定期清理主库二进制日志
解决方案:
重新构建主从

SQL 线程故障

SQL线程功能

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

导致SQL线程故障原因分析

1. 版本差异,参数设定不同,比如:数据类型的差异,SQL_MODE影响
2.要创建的数据库对象,已经存在
3.要删除或修改的对象不存在
4.DML语句不符合表定义及约束时.
归根揭底的原因都是由于从库发生了写入操作.

处理方法(以从库为核心的处理方案):

方法一:
stop slave;
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个,如果多次不同步,可以重复操作。
start slave;
但是,以上操作有时是有风险的,最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
方法二:
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
这种处理方法有隐患,生产不使用。
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
但是,以上操作有时是有风险的,最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
方法三:
(1) 可以设置从库只读.
db01 [(none)]>show variables like '%read_only%';
临时修改:
mysql [(none)]>set global read_only=1;
永久修改:配置文件添加read_only=1;
注意:
只会影响到普通用户,对管理员用户无效。
方法四:
加中间件,读写分离选择主从库。

主从延时监控及原因

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

外在因素

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

主库

(1) 二进制日志写入不及时
[rep]>select @@sync_binlog;
+---------------+
| @@sync_binlog |
+---------------+
| 1 |
+---------------+
(2) CR的主从复制中,binlog_dump线程,事件为单元,串行传送二进制日志(5.6 5.5)
1. 主库并发事务量大,主库可以并行,传送时是串行
2. 主库发生了大事务,由于是串行传送,会产生阻塞后续的事务.
解决方案:
1. 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO
2. 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,我们建议还是认为开启GTID
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]
赞(0)

评论 抢沙发

评论前必须登录!

 

LNMP社群 不仅仅是技术

关于我们网站地图