重置从库到主库最早记录需先执行STOP SLAVE再RESET SLAVE，然后CHANGE MASTER TO指定MASTER_LOG_FILE='mysql-bin.000001'和MASTER_LOG_POS=4（binlog起始有效位置），确保从库数据与主库初始状态一致后START SLAVE。
直接重置到主库最早记录，本质是让从库丢弃所有已同步的 binlog 位置，从主库当前 mysql-bin.000001 的起始位置（Position = 4）开始重新拉取。这不等于清空数据，而是重置复制坐标——必须确保从库数据状态与主库初始状态一致，否则会出错。
STOP SLAVE 和 RESET SLAVE 的执行顺序不能颠倒
先停复制，再清配置，是唯一安全顺序。如果先 RESET SLAVE 再 STOP SLAVE，MySQL 可能报错 ERROR 1200 (HY000): The server is not configured as slave，因为重置后复制线程已不存在。
-
STOP SLAVE;—— 立即终止 IO 和 SQL 线程，避免位点继续推进 -
RESET SLAVE;—— 清空mysql.slave_master_info和mysql.slave_relay_log_info表，删除 relay log 文件，但保留master.info（仅在旧版本中存在） - 注意：
RESET SLAVE ALL;会额外清除master.info和relay-log.info文件，适用于彻底清理；生产环境建议用RESET SLAVE即可
CHANGE MASTER TO 必须指定 Position = 4
MySQL 的每个 binlog 文件开头固定有 4 字节 magic number，实际可读事件从 Position = 4 开始。设成 0 或 1 会报错 ERROR 1236 (HY000): Could not parse relay log event entry；设成大于 4 的值（如 120），则跳过开头事件，无法做到“最早记录”。
- 主库上执行
SHOW MASTER STATUS;，确认当前最老 binlog 是mysql-bin.000001（不是mysql-bin.000002或更晚） - 从库执行：
CHANGE MASTER TO MASTER_HOST='10.0.1.100', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4;
- 如果主库已 rotate 过多次，
mysql-bin.000001可能已被 purge，此时需先在主库执行PURGE BINARY LOGS BEFORE '2026-01-01 00:00:00';留下最早的文件，再操作
START SLAVE 前必须验证数据一致性
位点能设为 4，不代表从库数据就能跟上——如果从库已有部分表、或 schema 与主库不一致（比如少建了一张表），START SLAVE 后 SQL 线程立刻报错 Table 'db.t' doesn't exist 并停止。
- 务必提前比对：主从库的
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','sys','information_schema','performance_schema'); - 检查
read_only是否关闭：SET GLOBAL read_only = OFF;（否则START SLAVE会因权限拒绝启动 SQL 线程） - 启动后立刻查：
SHOW SLAVE STATUS\G，重点关注Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Seconds_Behind_Master: NULL（刚启动时为 NULL 是正常）
真正麻烦的不是命令本身，而是位点重置后 SQL 线程能否连续执行下去——它依赖从库此刻的数据快照是否与主库 mysql-bin.000001 起始时刻完全一致。这点容易被忽略，一上来就 START SLAVE，结果卡在第一个 CREATE TABLE 就失败。
