mysql5.7 主从不同步GTID_NEXT

Posted 2020-09-04

5.6的解决方案
http://suifu.blog.51cto.com/9167728/1845457
end_log_pos 有了它，根据pos值，直接就能找到，找到delete那条数据，反做（变成insert）

原因
我在从库上操作了create语句，然后主从不同步了，所以解决办法就是跳过已经执行的sql

Last_SQL_Errno: 1050
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction ‘b30dcce8-3395-11e6-902b-0050569d58f6:38435158‘ at master log mysql-bin.001313, end_log_pos 19583512. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.

解决 
1.master
mysqlbinlog mysql-bin.001313 (end_log_pos 19583512 对应#170314 19:28:02 server id 1  end_log_pos 19583512 CRC32 0xed572feb 	Quer)

mysqlbinlog mysql-bin.001313|grep -C 10 "end_log_pos 19583512"

说明这行有问题
SET @@SESSION.GTID_NEXT= ‘b30dcce8-3395-11e6-902b-0050569d58f6:38435158‘/*!*/;
# at 19581673
#170314 19:28:02 server id 1  end_log_pos 19583512 CRC32 0xed572feb 	Query	thread_id=23586111	exec_time=0	error_code=0

2.slave
stop slave;  
set @@session.gtid_next=‘b30dcce8-3395-11e6-902b-0050569d58f6:38435158‘;
begin;
commit;
set @@session.gtid_next=automatic;
start slave;

3.show slave status\G;
因为拖到早上解决，所以看下落后多少数据
Master_Log_File: mysql-bin.001319
Read_Master_Log_Pos: 2532411
Relay_Log_Pos: 27411621
Relay_Master_Log_File: mysql-bin.001313
Exec_Master_Log_Pos: 27411408
Retrieved_Gtid_Set: b30dcce8-3395-11e6-902b-0050569d58f6:38411883-38616860
Executed_Gtid_Set: 9b59f303-3433-11e6-8a48-0050569d2d94:1-146,
b30dcce8-3395-11e6-902b-0050569d58f6:1270-38443937

4.所以有必要利用pt工具强制同步

4.1
pt-table-checksum h=‘masterip‘,u=‘xx‘,p=‘xx‘,P=3306 --nocheck-replication-filters --replicate=test.checksums --no-check-binlog-format --ignore-databases=mysql --chunk-size-limit=5

4.2
pt-table-sync  --execute --replicate test.checksums  --sync-to-master h=‘slaveip‘,P=3306,u=‘xx‘,p=‘xx‘

5.show slave status变化

[MySQL FAQ]系列 — MySQL复制中slave延迟监控
Read_Master_Log_Pos: 445167889
Exec_Master_Log_Pos: 445167889
Seconds_Behind_Master: 0

好了，最后我们说下如何正确判断SLAVE的延迟情况：
1、首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差异；
2、如果Relay_Master_Log_File 和 Master_Log_File 是一样的话，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异，对比SQL线程比IO线程慢了多少个binlog事件；
3、如果Relay_Master_Log_File 和 Master_Log_File 不一样，那说明延迟可能较大，需要从MASTER上取得binlog status，判断当前的binlog和MASTER上的差距；
在第三方监控节点上，对MASTER和SLAVE同时发起SHOW BINARY LOGS和SHOW SLAVE STATUS\G的请求，最后判断二者binlog的差异，以及 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异。

UserParameter=mysql.slave.Relay_Log_Pos
UserParameter=mysql.slave.Exec_Master_Log_Pos
UserParameter=mysql.slave.Read_Master_Log_Pos

监控项目
Read_Master_Log_Pos: 5374182
Relay_Log_Pos: 27113212
Exec_Master_Log_Pos: 27112999

Relay_Master_Log_File 和 Master_Log_File(需要增加)

本文出自 “python 运维” 博客，谢绝转载！