mysql跨服务器不停机迁移核心是主从复制+mysqldump初始同步+change master to接续binlog，前提是源库启用row格式binlog、server-id不冲突、网络通畅；需用--single-transaction和--master-data=2导出确保一致性快照与精准位点。
MySQL跨服务器不停机迁移，核心就一条：用主从复制 + mysqldump 初始同步 + CHANGE MASTER TO 接续 binlog，只要 binlog 位置对得上、server-id 不冲突、网络通，就能做到业务零感知切换。
确认源库 binlog 已启用且格式为 ROW
这是整个同步链路能成立的前提。如果源库没开 binlog，或者格式是 STATEMENT（尤其含非确定性函数时），后续增量数据会丢或错。
- 执行
SHOW VARIABLES LIKE 'log_bin';，返回ON才算开启 - 执行
SHOW VARIABLES LIKE 'binlog_format';，必须是ROW；若为MIXED或STATEMENT，需在my.cnf中显式设置binlog_format = ROW并重启 -
ROW格式能精确记录每行变更，避免触发器、函数、时间类函数导致的主从不一致
导出时用 --single-transaction 和 --master-data=2
这两个参数决定你能否真正“不停机”——前者保证一致性快照不锁表，后者自动埋入 CHANGE MASTER TO 所需的 binlog 文件名和 position。
-
--single-transaction依赖 InnoDB 的 MVCC，仅对事务表有效；MyISAM 表仍会被锁，务必提前检查表引擎 -
--master-data=2会在 dump 文件开头插入带注释的CHANGE MASTER TO语句，例如：-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; - 别手写
SHOW MASTER STATUS后再记位置——dump 过程中可能已有新事务提交，那个 position 就失效了
目标库配置 server-id 且不能与源库重复
MySQL 主从复制靠 server-id 区分节点身份。一旦重复，从库会拒绝启动复制，或出现循环复制（比如 A→B→A）。
- 源库
server-id通常为1，目标库必须设为其他正整数，如2、100等，写进/etc/my.cnf的[mysqld]段并重启 MySQL - 目标库也建议开启
log-bin（即使暂不升主），方便后续故障排查、审计或二次复制 - 目标库时间必须与源库同步（误差 Seconds_Behind_Master 显示异常，甚至触发 GTID 冲突
导入后执行 CHANGE MASTER TO 前先 STOP SLAVE
很多操作失败，是因为跳过了这一步：目标库默认没启动复制线程，但如果你之前试过配置又没清干净，残留的 relay_log 或 master_info_repository 可能干扰新配置。
- 导入 dump 文件后，先执行
STOP SLAVE;（哪怕显示SLAVE is not running，也建议执行） - 再从 dump 文件里提取 binlog 位置：
grep "CHANGE MASTER TO" dump.sql，复制那行去掉注释和分号 - 执行
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl_user', MASTER_PASSWORD='secure_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; - 最后
START SLAVE;，立刻用SHOW SLAVE STATUS\G检查Slave_IO_Running和Slave_SQL_Running是否都为Yes
最容易被忽略的是：目标库导入 dump 后，auto_increment 值、GTID_EXECUTED（如果开了 GTID）、以及用户权限不会自动同步。这些必须单独处理，否则切换后应用写入会失败或越权。不要只盯着数据同步成功就认为万事大吉。
