MySQL 8.0 不支持直接在线更换主库 IP，因复制线程运行时严格校验 source host 一致性；仅执行 CHANGE REPLICATION SOURCE TO 而不 STOP REPLICA，会导致 IO_THREAD 重连旧 IP、SQL_THREAD 因 relay log 来源不一致报错，出现 Connecting 卡住、Seconds_Behind_Master 异常等现象。
MySQL 8.0 不支持直接“在线更换主库 IP”——所有涉及主从关系变更的操作，都必须停写或至少暂停从库的 SQL 线程，否则会破坏复制一致性。
为什么不能直接改 CHANGE REPLICATION SOURCE TO SOURCE_HOST 后就继续跑？
MySQL 8.0 的复制线程（尤其是 SQL_THREAD）在运行时，会严格校验当前连接的 source host 是否与 performance_schema.replication_connection_configuration 中记录的一致。如果仅执行 CHANGE REPLICATION SOURCE TO 修改了 SOURCE_HOST，但未显式停止并重启线程，IO_THREAD 仍会尝试重连旧 IP，而 SQL_THREAD 可能因 relay log 中的事件来源不一致报错（如 ER_MASTER_INFO_REPOSITORY_ERROR 或 Slave SQL thread retried transaction 类警告）。
常见错误现象：
-
SHOW REPLICA STATUS\G显示Replica_IO_Running: Connecting却一直卡住 -
Seconds_Behind_Master跳变或变为NULL - 错误日志出现
error connecting to master 'repl@old-ip:3306'即使已执行过CHANGE
安全切换的三步实操流程（需短暂停写）
核心原则：先断开、再重建、最后验证。整个过程对业务影响可控（通常
- 在从库上执行：
STOP REPLICA;（MySQL 8.0.22+ 推荐用此命令，兼容性优于STOP SLAVE） - 执行变更：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='new-ip', SOURCE_PORT=3306, SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION=1;（务必补全所有必要参数，避免遗漏导致认证失败） - 重新启动：
START REPLICA;，然后立刻检查：SHOW REPLICA STATUS\G中Replica_IO_Running和Replica_SQL_Running均为Yes，且Seconds_Behind_Master开始下降
注意：SOURCE_AUTO_POSITION=1 必须与主库实际开启 GTID 模式匹配；若主库是传统 binlog file/pos 复制，此处应改为 SOURCE_LOG_FILE 和 SOURCE_LOG_POS，且需提前在新主库上执行 SHOW MASTER STATUS 获取最新位置。
如何避免 DNS 缓存或网络层干扰？
即使你改了 IP，MySQL 从库底层仍可能受系统 DNS 缓存或中间代理影响。关键点：
- 确认从库所在服务器能直连新 IP：
telnet new-ip 3306或mysql -h new-ip -u repl -p测试连通性和权限 - 禁用 MySQL 的主机名解析（推荐）：在从库配置文件
/etc/my.cnf的[mysqld]下添加skip_name_resolve=ON，重启 mysqld（否则 MySQL 可能反向解析新 IP 对应的 hostname，再正向解析回旧 IP） - 不要依赖 /etc/hosts 临时映射——它无法解决跨机房、负载均衡等场景，且容易被忽略
性能影响极小，但跳过 DNS 解析可让 IO 线程重连更快（减少每次重试的 30 秒超时等待）。
主库本身换 IP 后，哪些配置项容易被漏掉？
只改从库不够，主库的 bind 地址和防火墙策略同样关键：
- 检查主库
bind_address：默认可能是127.0.0.1或旧 IP，需改为0.0.0.0或新 IP，并重启 MySQL（systemctl restart mysqld） - 确认新 IP 的 3306 端口在主库防火墙放行：
firewall-cmd --list-ports（CentOS）或ufw status（Ubuntu） - 验证主库用户授权是否绑定旧 IP：
SELECT user,host FROM mysql.user WHERE user='repl';，若host是'old-ip'，需执行CREATE USER 'repl'@'new-ip' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'new-ip'; FLUSH PRIVILEGES;
最容易被忽略的是主库的 bind_address 和从库的 skip_name_resolve —— 这两个配置不生效时，现象就是“明明改了 IP，但从库死活连不上”，查日志也只看到超时，找不到根本原因。
