关键词：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命令 执行完，再次查看相关信息
相关文章：