（5.11）mysql高可用系列——复制中常见的SQL与IO线程故障

关键词：mysql复制故障处理

【1】手工处理的gtid_next（SQL线程报错）

　　 例如：主键冲突，表、数据库不存在，row模式下的数据不存在等。

　　【1.1】模拟故障：GTID模式下的重复创建用户

【1.1.1】先在从库上创建一个用户，再去主库上创建一个用户
-- 从202：　　　　　　　
create user 'test'@'%' identified by '123456';
grant all privileges on *.* to 'test'@'%';
flush privileges;

-- 主202：　　　　　　　
create user 'test'@'%' identified by '123456';
grant all privileges on *.* to 'test'@'%';
flush privileges;

use test;
create table test3(id int);
insert into test3 values(1);
commit;

【1.1.2】核验同步

发现不同步

在从库202执行：

　show slave statusG  -- 查看状态

　发现错误：

这里显示的GTID，指的是，需要执行这个GTID事务失败了，也就是说，真正出问题的是该GTID上面那个事务。

 【1.1.3】核验错误信息

根据图上的文件名和位置在主库上查看执行的信息是什么；

　果然是创建用户报错了。

　

　　从这个图，根据位置信息和GTID，应该就可以应征上面标红说的。

 查看更详细的信息；在从库上运行

　　select * from performance_schema.replication_applier_status_by_workerG

　　

　　Read_Master_Log_Pos: 2174

　　Exec_Master_Log_Pos: 1112

 记得，这个错误号，就是我们报错的那个，要对应否则可能是其他时间出现的错误信息；

【1.1.4】解决，跳过、屏蔽这个冲突事务

在从库上：直接指定，下一个执行的事务，为错误信息上显示的事务（因为这里显示的GTID，是说执行到这个点出错，这个GTID所在的事务没有执行）

（1）由于在这个GTID必须是连续的，正常情况同一个服务器产生的GTID是不会存在空缺的。

　　 所以不能简单的skip掉一个事务，只能通过注入空事物的方法替换掉一个实际操作事务。

（2）注入空事物的方法：

stop slave;

set @@session.gtid_next='de853101-b165-11e9-900a-000c291f4171:8';

begin;commit;

set @@session.gtid_next='automatic'; -- 不改回来，很多报错

start slave;

　　如果 set @@session.gtid_next='automatic';这时候，报错如下。

　　那么意思是还没重做完，等一下再操作即可。

mysql> set @@session.gtid_next='de853101-b165-11e9-900a-000c291f4171:18';
ERROR 1766 (HY000): The system variable gtid_next cannot be set when there is an ongoing transaction.

【1.1.5】核验

　　show slave statusG -- 查看进程状态与错误信息 是否OK

　　use test;show tables; -- 查看数据是否同步过来，OK了啊

　　

 【1.1.6】如果是主库的最后一条事务报错，怎么办？

【2】非GTID模式下跳过错误事务

1.跳过指定数量的事务：（建议如果已经出现了错误，使用这种办法）
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; #跳过一个事务
mysql>slave start;

【3】5.7增强半同步从库宕机如何重新连入主库？

增强半同步从库宕机如何重新连入主库？（或者直接重新备份还原）

1. 此2个参数rpl_semi_sync_master_enabled  和rpl_semi_sync_slave_enabled  不要直接写入到my.cnf配置文件开启。
2.在slave库上先 stop slave io_thread ;set global  rpl_semi_sync_slave_enabled=0 关闭此参数。
  然后start slave io_thread 或者start slave 开启异步复制，让slave库追赶上master库。
3.然后在slave库 set global  rpl_semi_sync_slave_enabled=1 ；stop  slave io_thread;start  slave  io_thread;

【4】Slave failed to initialize relay log

mysql> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

解决：
    reset slave;

【5】Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - master server_id is 0'

mysql -uroot -predhat -e "show slave statusG;"
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - master server_id is 0'

解决：
    修改server_id，id冲突

【6】UUID错误，删除data下的auto.cnf

The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

　或者修改这个文件内的UUID也可以

　　

【7】主从节点GTID开启不一致

mysql -uroot -predhat -e "show slave statusG;"
The replication receiver thread cannot start because the master has GTID_MODE = ON and this server has GTID_MODE = OFF

解决：
    主从节点GTID开启不一致

【8】跳过主库已经忽略的GTID事务

错误1236
Got fatal error 1236 from master when reading data from binary log: 
'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

错误1236
Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

解决：

1，不需要重新搭建主从的方式，对于主从复制报错，出现问题，虽然重新搭建主从是万能法，但尽量尝试其它方式，因为对于大数据量数据库，重新搭建主从需要耗费很长时间。

在主库上执行

mysql>show global variables like '%gtid_purged%';

或

show global variables like '%gtid%'G

查看主库的gtid_purged的value值。

在从库上也执行该命令，查看gtid_purged值是否和主库相同，如果小于主库的值如下。

2，在从库上执行

mysql>stop slave;

mysql>set @@global.gtid_purged='主库查询到的value值'；   #'set @@global.gtid_purged='a95d8cb2-3ff7-11e9-8bfa-000c299b47f8:16-23';

mysql>begin;commit;

mysql>set gtid_next='automatic';

mysql>start slave;

查看一下主从状态。

mysql>show slave statusG;

这时的主从状态，SQL线程和IO线程都是yes了。

一般两种情况会出现以上现象
1.在主库上手动执行清除二进制日志文件
2.主库重启，重新同步时
二、解决方法：
1.在主库上执行以下命令，查询gtid_purged，记录下改值
mysql> show global variables like '%gtid%'G
wKiom1hTZpKCU8WoAABPgzDyrTQ054.png
2.在从库上执行以下命令，查询已经执行过的gtid即gtid_executed，记录下主库的值，本机的不需要
wKioL1hTZp-DQZMvAAAspE0SKJ8150.png
3.在从库上执行以下命令停止同步线程及重置同步相关信息
mysql> stop slave;
mysql> reset slave;
mysql> reset master;
4.在从库上设置gtid_purged
该值有两个来源，一是在主库上查询的gtid_purged，二是在从库上查询的已经执行过的gtid_executed值（本机的就不需要，主库上gtid）
注意：一定记得加上从库上已经执行过的gtid，若只设置了主库上的gtid_purged，此时从库会重新拉取主库上所有的二进制日志文件，同步过程会出现其他错误，导致同步无法进行
mysql> set @@global.gtid_purged='4fa9ab33-3077-11e6-8ee6-fcaa14d0751b:1-18240458,6e41a42e-8529-11e6-b72e-fcaa14d07546:1-56604052:56604054-56605629:56605631-56871196,9850e381-b601-11e6-8e46-fcaa14d07546:1-3126210,c5cdcae2-9cb0-11e6-909c-fcaa14d0751b:1-1189,10a59961-c02d-11e6-a2de-fcaa14d07546:1-13381418';
注意：设置gtid_purged值时，gtid_executed值必须为空否则报错，该值清空的方法就是reset  master命令
执行完，再次查看相关信息

相关文章：

　　

　　mysql复制的日常管理维护，mysql复制常见问题处理