十七、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 如果现实非以上信息,说明主从之间的关系出现了问题
[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
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)ping主库的ip #2)查看防火墙是否阻止
主库缺失日志 从库方面,二进制日志位置点不对 在主库执行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无法执行
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'
方案一：以从库为核心的处理方案(不建议使用)
方法一： 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、外在因素
网络
主从硬件差异较大
版本差异
参数因素
(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. 大事务拆成多个小事务,可以有效的减少主从延时.
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]
I have a dream so I study hard!!!
