主从复制中断时Seconds_Behind_Master为NULL且Slave_IO_Running为No，表明IO线程已停止，常见原因包括主库binlog被清理、网络断连或权限失效；需先检查主从binlog文件与位置是否匹配，确认是否数据丢失，再针对性处理。
主从复制中断后，SHOW SLAVE STATUS 显示 Seconds_Behind_Master: NULL 且 Slave_IO_Running: No
这通常意味着 IO 线程已停止，最常见原因是主库 binlog 被清理、网络断连或权限失效。先别急着跳过错误，先确认是否真丢了数据：
- 查主库当前 binlog 文件和位置：
SHOW MASTER STATUS;
- 对比从库
Relay_Master_Log_File和Exec_Master_Log_Pos，看是否已超出主库现存 binlog 范围 - 若主库
mysql-bin.000012最大只到 position 123456，而从库正尝试读mysql-bin.000013，说明 binlog 已被PURGE BINARY LOGS清掉 —— 此时无法靠原生复制恢复，需重新初始化
能定位到具体错误（如 Got fatal error 1236 或 Duplicate entry for key 'PRIMARY'）
这类错误可针对性跳过或修复，但必须清楚后果：跳过 ≠ 恢复数据一致性，只是让复制线程继续跑。
-
SET GLOBAL sql_slave_skip_counter = 1;仅对基于语句的复制（binlog_format=STATEMENT）有效；在ROW格式下无效，改用gtid_next方式 - 若启用 GTID（
gtid_mode=ON），跳过步骤是：STOP SLAVE;<br>SET GTID_NEXT='xxx-xxx-xxx:N'; -- N 是出错事务的 GTID 序号+1<br>BEGIN; COMMIT;<br>SET GTID_NEXT='AUTOMATIC';<br>START SLAVE;
- 遇到主键冲突，先查从库该记录是否存在：
SELECT * FROM tbl WHERE id = XXX;，再决定是删从库脏数据、还是更新主库避免重复写入
从库 relay log 损坏或缺失导致 Relay_Log_Space = 0 或报错 Could not parse relay log event entry
relay log 是从库本地缓存的主库事件，损坏后无法解析，但只要主库 binlog 还在，就能重建。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 停复制：
STOP SLAVE; - 清空 relay log：
RESET SLAVE;（注意：这会清空master.info和relay-log.info，需手动重设主库连接信息） - 重新指定主库位置（若非 GTID）：
CHANGE MASTER TO<br> MASTER_HOST='xx',<br> MASTER_USER='repl',<br> MASTER_PASSWORD='xxx',<br> MASTER_LOG_FILE='mysql-bin.000012',<br> MASTER_LOG_POS=123456;<br>START SLAVE;
- GTID 模式下无需指定文件/位置，只需确保
MASTER_AUTO_POSITION=1，RESET SLAVE后直接START SLAVE即可自动追平
集群级异常（如 MGR 多主写入冲突、节点失联后无法自动重加入）
MGR 不是传统主从，不能套用 START SLAVE 思路。异常多发生在 group_replication_group_name 不一致、本地 binlog 关闭、或 performance_schema 未启用。
- 检查节点状态：
SELECT * FROM performance_schema.replication_group_members;，若自己显示OFFLINE或ERROR，先看错误日志中是否有Plugin group_replication reported: 'This member has more executed transactions than those present in the group' - 强制重新加入前，必须确认该节点数据已完全落后于组（否则会引发分裂脑）：
SELECT RECEIVED_TRANSACTION_SET FROM performance_schema.replication_connection_status\G - 安全做法是：停掉该节点 MySQL，删掉
mysqld-auto.cnf（避免 UUID 冲突），清空 data 目录（或用备份恢复），再启动并执行：START GROUP_REPLICATION;
MySQL 复制恢复最易被忽略的一点：没验证 Seconds_Behind_Master 归零后，表数据是否真一致。建议用 pt-table-checksum 做一次校验，尤其在跳过错误或重建从库后。
