SHOW SLAVE STATUS\G 是定位MySQL主从复制中断的唯一可靠入口，需检查IO/SQL线程状态、Seconds_Behind_Master及Last_IO/SQL_Error等关键字段。
主从复制中断后如何快速定位原因
MySQL 主从复制断开时，SHOW SLAVE STATUS\G 是唯一可靠入口。重点关注 Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes，以及 Seconds_Behind_Master 是否持续增长或为 NULL。
常见中断现象与对应线索：
-
IO线程停止：通常指向网络、权限或主库 binlog 不存在（如被误删、过期清理）；检查Last_IO_Error -
SQL线程停止：多因从库执行 SQL 失败，比如主键冲突、表结构不一致、DDL 被跳过但后续 DML 依赖该结构；看Last_SQL_Error -
Seconds_Behind_Master = NULL且两个线程都为Yes：说明 IO 已拉取日志但 SQL 线程卡在某个事件，需结合Relay_Log_Pos和Exec_Master_Log_Pos对比判断是否积压
跳过单条错误继续同步的实操边界
仅当确认错误是**可安全忽略的数据层冲突**（例如主库重复插入同一主键，且业务允许从库以主库为准覆盖），才使用跳过机制。不可用于结构变更失败、字符集不兼容、GTID 模式下位置错乱等场景。
具体操作分两种模式：
- 传统 binlog 位置模式：
STOP SLAVE;<br>SET GLOBAL sql_slave_skip_counter = 1;<br>START SLAVE;
- GTID 模式（推荐）：
STOP SLAVE;<br>SET GTID_NEXT='ac6a95c2-1234-11ef-8001-00155d012345:12345';<br>BEGIN; COMMIT;<br>SET GTID_NEXT='AUTOMATIC';<br>START SLAVE;
其中ac6a95c2-...:12345需替换为SHOW SLAVE STATUS\G中Retrieved_Gtid_Set里缺失的那个事务号
注意：sql_slave_skip_counter 在 GTID 模式下被禁用，强行设置会报错 ERROR 1776 (HY000): Cannot use sql_slave_skip_counter when @@GLOBAL.GTID_MODE = ON。
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
全量重做同步前必须验证的三件事
当数据不一致严重、跳过不可行或无法定位源头时，重做同步是稳妥选择，但代价高，务必先确认：
- 主库
my.cnf中已启用log-bin且server-id唯一；否则从库无法获取新日志 - 主库当前
SHOW MASTER STATUS的File和Position值未被 purge（可通过SHOW BINARY LOGS查看最老 binlog 文件名，对比是否仍存在） - 从库上无正在运行的写入应用，且已停掉所有可能修改数据的定时任务或脚本；否则 mysqldump 导出期间数据会变动，导致 dump 不一致
典型重做流程（GTID 模式）：
mysqldump --all-databases --single-transaction --triggers --routines --events --host=master_ip --user=replica_user --password=xxx > full_dump.sql<br># 在从库停复制、清空数据、导入<br>mysql -e "STOP SLAVE; RESET SLAVE ALL;"<br>mysql < full_dump.sql<br>mysql -e "SET GLOBAL gtid_purged='ac6a95c2-1234-11ef-8001-00155d012345:1-12345'; START SLAVE;"其中
gtid_purged 值必须与主库 SELECT @@global.gtid_executed; 输出完全一致，否则启动失败报 error 1236。
从库延迟突增却显示“正常运行”的隐藏陷阱
Seconds_Behind_Master = 0 并不等于实时同步完成。它只反映 SQL 线程已执行完 relay log 中最后一个事件，但若主库正批量写入大事务（如 ALTER TABLE、百万级 INSERT ... SELECT），从库可能仍在回放该事务内部语句，此时监控看到的延迟是滞后的。
真正有效的观测方式：
- 查
SHOW PROCESSLIST中 Slave_SQL 线程状态，长期停留在executing或updating，说明正在处理大事务 - 对比主库
SHOW MASTER STATUS的Position与从库Exec_Master_Log_Pos差值（非 GTID 模式下），差值持续增大即真实延迟 - 开启
performance_schema表replication_applier_status_by_coordinator，观察APPLYING_EVENT的耗时分布
这类延迟无法靠重启复制解决，只能优化主库事务粒度、升级从库硬件或启用并行复制（slave_parallel_workers > 0 且 slave_parallel_type = LOGICAL_CLOCK）。
