执行change master to前必须先stop slave，否则配置不生效；5.7+支持reset slave all清除配置但会删relay log；选点位需确保新主库binlog位置≥从库已执行位置，且该位置真实存在。
CHANGE MASTER TO 为什么执行后 SHOW SLAVE STATUS 不更新
常见现象是执行了 CHANGE MASTER TO，但立刻查 SHOW SLAVE STATUS，发现 Master_Host、Master_Log_File 等字段没变，甚至报错 Error 1200 (HY000): The server is not configured as slave。根本原因是：mysql 要求必须先停掉复制线程，否则命令被忽略或直接失败。
- 必须先执行
STOP SLAVE，再执行CHANGE MASTER TO - 如果只改部分参数（比如只换主库 IP），其他如
MASTER_LOG_FILE和MASTER_LOG_POS没显式指定，MySQL 会沿用旧值——不是清空，也不是自动探测，就是“不碰就不动” - 5.7+ 版本支持
RESET SLAVE ALL清除所有主库配置，但会删掉 relay log 和 master.info，慎用于在线切换
在线切换主库时怎么选点位_binlog 文件名和位置怎么定
点位选错，从库一启动就报 Could not find first log file name in binary log index file 或跳过大量事务。核心原则：新主库的 binlog 位置必须 ≥ 原主库当时已同步到从库的最新位置。
- 在原主库上执行
SHOW MASTER STATUS，记下File和position；这是它当前写入的最新点位 - 在从库上执行
SHOW SLAVE STATUSG，重点看Relay_Master_Log_File和Exec_Master_Log_Pos—— 这才是它实际已执行完的原主库 binlog 位置 - 新主库必须已开启 binlog，且该点位必须存在于它的
SHOW BINARY LOGS列表中；如果新主库是刚提升的从库，需确认它已执行完所有 relay log（Seconds_Behind_Master: 0且Slave_SQL_Running_State: Slave has read all relay log）
MySQL 5.7 和 8.0 的 CHANGE MASTER TO 语法差异
8.0 把主库连接信息彻底移到了 Performance Schema 表里，CHANGE MASTER TO 默认不再写磁盘文件（如 master.info），而是存内存 + 可选持久化。这影响故障恢复和配置迁移。
- 5.7 及以前：参数如
MASTER_HOST、MASTER_USER写入master.info文件，重启后自动加载 - 8.0 默认使用
MASTER_AUTO_POSITION = 0时，仍走老路径；但若启用了 GTID（MASTER_AUTO_POSITION = 1），则完全不依赖文件，靠gtid_executed自动对齐 - 8.0 推荐加
PERSIST关键字（如CHANGE MASTER TO ... PERSIST;），确保重启后配置不丢失；否则仅内存生效
执行 CHANGE MASTER TO 后 START SLAVE 报错 ERROR 2003 或 ERROR 1045
不是语法问题，是网络或权限卡住了。错误码比报错文字更准：ERROR 2003 是连不上，ERROR 1045 是账号密码不对，ERROR 2013 是连接中途断了。
- 检查新主库的
bind_address是否监听了从库能访问的 IP（别只绑127.0.0.1） - 确认新主库的复制账号存在且有
REPLICATION SLAVE权限：运行SHOW GRANTS FOR 'repl'@'%'; - MySQL 8.0 默认认证插件是
caching_sha2_password，老客户端可能不兼容；可在创建账号时显式指定IDENTIFIED WITH mysql_native_password
点位本身不难找，难的是确认「这个点位在新主库上真实存在且可读」——很多人切完才发现新主库的 binlog 被 purged 了，或者 GTID 集合对不上。多看一眼 SHOW BINARY LOGS 和 select * FROM performance_schema.replication_connection_configuration，比反复重试快得多。