大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说处理mysql主从不同步问题,希望您对编程的造诣更进一步.
问题描述：发现主库操作数据从库没有变动问题，可能原因是从库重启导致的无法同步问题。
排查思路：
1、查看主从复制状态
发现从库的IO和SQL进程都是no(正常状态应该是yes)
注意：mysql replication中slave机器上有两个关键进程，死一个都不行，一个是slave_sql_running,一个是slave_io_running，一个负责与主机的IO通信，一个负责自己的slave mysql进程。
2、解决办法如下：
>stop slave; ##停止同步
> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; ##设置counter为1,启动同步
>show slave statusG; ##查看同步状态
3、发现SQL进程还是No
提示信息显示如下：
Last_Errno: 1396
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction “fab1fc64-d0f2-11ec-a2a6-000c2950bca1:9” at master log mybinlog.000001, end_log_pos 1966. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
4、根据上面的提示，查询到的异常数据出现在opp_starck表中
#select * from performance_schema.replication_applier_status_by_workerG; 确定事务发生在表opp_strack上，定位在表上，再去排查是哪张表
可以参考：https://blog.csdn.net/memory6364/article/details/86152717
5、主从数据恢复一致后需要在slave上跳过报错的事务，在从库中执行
使用GTID跳过错误的方法：找到错误的GTID跳过（通过exec_master_log_pos去binlog里找GTID，或者则通过监控表replication_applier_status_by_worker找到GTID，也可以通过excured_gtid_set算GTID），这里使用监控来找到错误的GTID。找到GTID之后，跳过错误的步骤：
>stop slave; #停止同步
>set @@session.gtid_next=”fab1fc64-d0f2-11ec-a2a6-000c2950bca1:9″; #跳过错误的GTID
>begin; #提交一个空事务，因为设置gtid_next后，gtid的生命周期就开始了，必须通过显性的提交一个事务来结束，否则报错：ERROR
>commit
>set @@session.gtid_next=automatic; #设置回自动模式
>start slave; #启动同步
>show slave statusG; #再次确认状态
6、如下图主从复制恢复正常
GTID：是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。
GTID核心参数
重要参数：
gtid-mode=on —启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true —强制GTID的一致性
log-slave-updates=1 –slave更新是否记入日志
原文地址：https://www.cnblogs.com/rickenl/archive/2022/05/21/16293811.html
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/5228.html
