slave_skip_errors仅跳过指定错误码的sql语句，不跳binlog位置；跳pos点必须用change master to指定master_log_file和master_log_pos，并重启复制。
slave_skip_errors 配置项只跳错误，不跳POS点
很多人误以为 slave_skip_errors 能跳过某个 binlog 位置（POS），其实它完全不处理位点逻辑——它只在 SQL 线程执行 relay log 中某条语句报错时，按错误码决定是否忽略并继续。跳 POS 点必须用 CHANGE MASTER TO ... MASTER_LOG_POS 手动指定新起点。
用 CHANGE MASTER TO 强制跳到指定 POS 点的实操步骤
前提是已知目标 binlog 文件名和准确 position（比如从 SHOW MASTER STATUS 或 SHOW BINLOG EVENTS 查得），且从库 SQL 线程已停止：
- 先停复制：
STOP SLAVE; - 确认当前中继日志状态：
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File和Exec_Master_Log_Pos，避免误跳过未执行语句 - 执行跳转（示例跳到
mysql-bin.000003的12345位置）：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=12345; - 重启复制：
START SLAVE;
注意：该操作会丢弃 relay log 中尚未执行的全部事件，且不会校验跳转后数据一致性；若主库该 POS 点之前有未同步的 DDL，从库可能因表结构不匹配而后续报错。
为什么不能直接改 relay_log_pos 或 relay_master_log_pos 变量
MySQL 不允许直接 SET 这类只读状态变量。例如试图执行 SET GLOBAL Relay_Master_Log_Pos = 12345; 会报错 ERROR 1238 (HY000): Variable 'Relay_Master_Log_Pos' is a read only variable。所有位点变更必须通过 CHANGE MASTER TO 触发内部重置流程，否则 IO/SQL 线程无法对齐状态。
跳 POS 后必须验证 SQL 线程是否真正追上
START SLAVE 后别只看 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 就认为 OK。重点检查：
-
Seconds_Behind_Master是否持续下降并归零 -
Exec_Master_Log_Pos是否稳定增长，且与Read_Master_Log_Pos差值不再扩大 - 查
SHOW PROCESSLIST中 SQL 线程状态是否为Waiting for master to send event（说明已追平）或Reading event from the relay log（正在追赶）
如果 Exec_Master_Log_Pos 卡住不动，大概率是跳到了一个不合法的 position（比如跨事务中间、或指向一个被 purge 的 binlog 文件），此时需重新定位有效位点。
