（5.11）mysql复制错误
关键词：mysql复制故障处理
【1】手工处理的gtid_next（SQL线程报错）
例如：主键冲突，表、数据库不存在，row模式下的数据不存在等。
【1.1】模拟故障：GTID模式下的重复创建用户
-- 先在从库上创建一个用户，再去主库上创建一个用户 -- 从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.2】查看主从同步
（1）直接对比数据
（2）show slave status\G
这里显示的GTID，指的是，需要执行这个GTID事务失败了，也就是说，真正出问题的是pos 1357为 end 的那个事务。
【1.3】核验错误信息
根据图上的文件名和位置在主库上查看执行的信息是什么；
果然是创建用户报错了。
show binlog events in 'mysql-bin.000015'
从这个图，根据位置信息和GTID，应该就可以应征上面标红说的。
【1.4】查看更详细错误：performance_schema.replication_applier_status_by_worker
查看更详细的信息；在从库上运行
select * from performance_schema.replication_applier_status_by_worker\G
Read_Master_Log_Pos: 2174
Exec_Master_Log_Pos: 1112
记得，这个错误号，就是我们报错的那个，要对应否则可能是其他时间出现的错误信息；
【1.5】解决，跳过、屏蔽这个冲突事务
那么，我们的 set @@session.gtid_next 究竟是跳到那个gtid呢？
应该跳到上图中 Executed_gtid_Set这里，看报错的gtid是哪个，就是Executed_gtid_set 的第一个；
如上图就是 162e7475-4b35-11eb-be0b-3448edf9f2d8:1-2 （这里的1-2指的只是范围）
在从库上：直接指定，下一个执行的事务，为错误信息上显示的事务（因为这里显示的GTID，是说执行到这个点出错，这个GTID所在的事务没有执行）
set @@session.gtid_next='162e7475-4b35-11eb-be0b-3448edf9f2d8:3';
（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.6】操作后的核验
show slave status\G -- 查看进程状态与错误信息 是否OK
use test;show tables; -- 查看数据是否同步过来，OK了啊
【1.7】如果是主库的最后一条事务报错，怎么办？
这种情况极少出现，最后一条的话，可以在主库上手动 begin ; end; 启动一个空事务即可；
【Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere】
gtid空事务/跳过事务引起的问题，一般发生在初始化
有一次，mysqldump出来 其中的 gloabl gtid_purged 是这个样子的；
SET @@GLOBAL.GTID_PURGED='591de3ee-d98e-11e7-a2d6-00163e0f7337:1-2:5-36501580401:36501580403-36501580406:36501580409-36501580600';
其中有多段用: 号分割了。比如：
1-2:5-36501580401
如上面代码段，我们可以发现这中间其实少了，3、4 的 gtid的；
所以导致主从报错，最终详细报错信息如下：
Got fatal error 1236 from master when reading data from binary log: 'Cannot replicate because the master purged required binary logs.
Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period.
The GTID set sent by the slave is '591de3ee-d98e-11e7-a2d6-00163e0f7337:1-2:5-36501580401:36501580403-36501580406:36501580409-36501580600',
and the missing transactions are '591de3ee-d98e-11e7-a2d6-00163e0f7337:3-4''
如何修复？
stop slave; reset master; #注意风险 reset slave;
# 中间段全部干掉，直接最前面到最末尾（注意，有时候有些有多个以,号为分隔符的，所以逗号为界限是为一个整体）
SET @@GLOBAL.GTID_PURGED='591de3ee-d98e-11e7-a2d6-00163e0f7337:1-36501580600';
start slave;
【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 关闭此参数。
3.然后start slave io_thread 或者start slave 开启异步复制，让slave库追赶上master库。
4.然后在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 status\G;" 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 status\G;" 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 status\G; 这时的主从状态，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命令 执行完，再次查看相关信息
【9】@@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty
1、去掉mysqldump 出来的文件中的该参数
2、reset master; 清空 gtix_executed
相关文章：
【10】could not find next log; the first event 'mysql-bin.000001' at 4
Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000001' at 4,
the last event read from '/data/mysql_log/binlog/mysql-bin.000002' at 2568, the last byte read from '/data/mysql_log/binlog/mysql-bin.000002' at 2568.'
是因为主从搭建好之后，主库重新reset master 过
