新主库上无法复用旧位点，因binlog文件名和position已重置；需执行show master status获取当前file和position值，再用change master to精确设置，且须确保新主库log_bin=on、read_only=off，并清空从库relay log。
主库宕机后，新主库上无法直接复用旧位点——CHANGE MASTER TO 必须指向新主库当前的 mysql-bin.* 文件和真实 Position，否则从库启动后立刻报错或重复执行。
为什么不能沿用旧主库的 binlog 位点？
旧主库的 mysql-bin.000001 和位置（比如 123456）在新主库上已失效：新主库重启或执行 RESET MASTER 后，binlog 文件名重置、起始位置不一定是 4，且所有写入都落在新文件里。硬填旧值会导致 ERROR 1236 (HY000): Could not parse relay log event entry 或跳过大量事务。
如何获取新主库当前合法的复制起点？
在新主库上执行 SHOW MASTER STATUS\G，只取两行关键输出：
-
File字段值（如mysql-bin.000001）——不是猜，也不是看文件列表 -
Position字段值（如154）——这是当前可追加写入的下一个字节偏移，不是“最后一条事件结束位置”
注意：Position 值受 binlog_format 和 binlog_checksum 影响，MySQL 5.7+ 默认为 ROW + CRC32，所以首条事件位置通常不是 4，而是 154 左右；设成 4 反而会解析失败。
从库执行 CHANGE MASTER TO 的关键参数组合
在每个要接入新主库的从库上，执行前必须先 STOP SLAVE，再按以下顺序设置：
-
MASTER_HOST、MASTER_USER、MASTER_PASSWORD、MASTER_PORT按新主库实际配置填 -
MASTER_LOG_FILE必须严格等于SHOW MASTER STATUS返回的File值（带单引号包裹） -
MASTER_LOG_POS必须严格等于SHOW MASTER STATUS返回的Position值（不加引号） - 禁用
MASTER_AUTO_POSITION=1—— 仅当新主库已启用 GTID 且你确认gtid_mode=ON时才可用；否则强制指定位点
示例命令：
CHANGE MASTER TO MASTER_HOST='10.0.2.50', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
START SLAVE 前最容易忽略的三件事
很多操作卡在 Seconds_Behind_Master: NULL 或 SQL 线程立即报错，问题往往不在位点本身：
- 新主库的
log_bin必须为ON（SHOW VARIABLES LIKE 'log_bin'查），否则从库拉不到任何 binlog - 新主库的
read_only和super_read_only必须为OFF（SET GLOBAL仅临时生效，需同步注释掉/etc/my.cnf中对应行并重启） - 从库本地的
relay-log文件若损坏或残留（尤其relay_log_purge=OFF时），必须先执行RESET SLAVE ALL清空，再CHANGE MASTER TO
位点对了，不代表数据能通——新主库没 binlog、被只读锁死、或从库 relay log 残留脏状态，都会让 START SLAVE 形同虚设。
