标签：mysql
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 运维” 博客，谢绝转载！
标签：mysql
原文地址：http://szgb17.blog.51cto.com/340201/1906790
