首页 > 代码库 > mysql5.7 主从不同步GTID_NEXT
mysql5.7 主从不同步GTID_NEXT
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 运维” 博客,谢绝转载!
mysql5.7 主从不同步GTID_NEXT
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。