pt-slave-restart仅能跳过sql_slave_skip_counter支持的错误，如1062（重复键）、1032（行不存在）、1050（表已存在）、1051（未知表）等DML和部分DDL错误。
pt-slave-restart 能跳过哪些错误？
pt-slave-restart 本质是监听 SHOW SLAVE STATUS 中的 Seconds_Behind_Master 和 Slave_SQL_Running_State，一旦发现 SQL 线程停止（Slave_SQL_Running: No），就尝试执行 SET GLOBAL sql_slave_skip_counter = 1 或 START SLAVE UNTIL 来跳过当前事件。它**只对能被 sql_slave_skip_counter 跳过的错误有效**，比如：
-
1062（重复键）、1032（找不到要更新/删除的行）这类 DML 错误 -
1050（表已存在）、1051（未知表）等 DDL 错误（需 MySQL
它**不能处理**：1594（relay log 读取失败）、2013（连接断开）、GTID 模式下 1236（binlog position 不匹配）等 IO 或元数据类错误——这些需要手动修复 relay log 或重设复制起点。
如何指定跳过某类错误而不影响其他错误？
用 --error-numbers 参数精确控制，多个用逗号分隔，例如只跳 1062 和 1032：
pt-slave-restart --error-numbers=1062,1032 --daemonize --log=/var/log/pt-slave-restart.log
注意：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 不加
--error-numbers会跳过所有错误，非常危险 - 错误号必须是
SHOW SLAVE STATUS\G中Last_SQL_Error显示的数字部分，如Could not execute Update_rows event on table test.t; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062→ 取1062 - MySQL 8.0.23+ 开始，某些错误（如 DDL 失败）可能不触发
sql_slave_skip_counter跳过机制，此时pt-slave-restart会反复重试并报Cannot skip error
GTID 模式下还能用 pt-slave-restart 吗？
可以，但必须配合 --skip-all 或 --error-numbers + --slave-info，且底层依赖 SET GTID_NEXT + 空事务跳过。实际效果受限：
- 需确保从库
gtid_mode=ON、enforce_gtid_consistency=ON - 跳过操作会生成一个空事务（
ANONYMOUS_GTID），主库不会同步该事务，但从库 GTID set 会前进一位 - 若错误发生在 GTID 边界不清晰的位置（如混合事务中），可能跳错位置，导致后续数据不一致
- 强烈建议先在测试环境验证：执行
pt-slave-restart --dry-run --error-numbers=1062看它拟执行的语句
为什么跳过之后又立刻报错？
常见于以下情况：
- 同一张表连续多行冲突（如批量
INSERT IGNORE被主库误写成INSERT），sql_slave_skip_counter=1只跳一条，下一条继续报1062 - 从库缺失主库已存在的表或字段，导致后续所有对该表的操作都失败 —— 这不是单个错误，而是结构性不一致，
pt-slave-restart无法解决 - 使用了
--run-time或--iterations限制，工具执行完就退出，没持续监控 - 错误被跳过，但
Seconds_Behind_Master仍为非零，工具认为“还在追”，继续检查，结果发现新错误（其实是另一个独立问题）
真正可靠的跳过，往往需要结合人工判断：确认错误是否可忽略、表结构是否一致、业务是否允许丢数据。自动跳过只是应急手段，不是一致性保障方案。
