零停机切换 MySQL 主从角色在 CentOS 7 上不可真正实现，但可通过严格控制写入窗口、精确同步等待和快速配置切换，将业务中断压缩到秒级（通常<5秒）。
零停机切换 MySQL 主从角色在 CentOS 7 上**不可真正实现**，但可通过严格控制写入窗口、精确同步等待和快速配置切换，将业务中断压缩到秒级（通常
为什么 FLUSH TABLES WITH READ LOCK 不等于“停机”
这个命令会阻塞所有 DML（INSERT/UPDATE/DELETE），但不会阻塞 SELECT，也不会终止已建立的连接。只要应用具备重试机制或读写分离路由能力，用户侧基本无感。真正风险来自两点：一是锁期间主库堆积大量未提交事务，二是从库未真正追平就解锁。
-
FLUSH TABLES WITH READ LOCK必须在确认Seconds_Behind_Master = 0后再执行，否则锁住的是“落后状态” - 执行后立即运行
SHOW MASTER STATUS，记下File和Position—— 这是后续CHANGE REPLICATION SOURCE TO的唯一可信坐标 - 锁住后不要做任何 DDL（如
ALTER TABLE），它可能隐式触发隐式提交，导致 binlog 位置跳变
用 MASTER_POS_WAIT 等待追平，别信 Seconds_Behind_Master
Seconds_Behind_Master 是估算值，网络延迟、大事务、IO 延迟都会让它显示为 0 却实际没追上。真实判断依据只有一个：MASTER_POS_WAIT() 返回非 -1 值。
- 在原从库上执行：
SELECT MASTER_POS_WAIT('mysql-bin.000012', 987654321, 30);—— 第三个参数是超时秒数，建议设为 30，避免无限挂起 - 返回值为正整数（如 0 或 1）才表示已追到指定位置；返回
NULL表示超时，必须中止切换 - 该函数只对当前 relay log 有效，所以务必在
STOP SLAVE前调用，且不能在RESET SLAVE ALL后再用
MySQL 8.0+ 必须用 SOURCE_ 前缀语法，别混用 MASTER_
CentOS 7 上若运行的是 MySQL 8.0 或更高版本（如知识库提到的 9.6.0），CHANGE MASTER TO 已被弃用，继续使用会报错 ERROR 1238 (HY000): Variable 'master_host' is a read only variable。
- 在新主库（原从库）上执行：
STOP SLAVE; RESET SLAVE ALL; - 在新从库（原主库）上执行：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.75.21', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_LOG_FILE='mysql-bin.000012', SOURCE_LOG_POS=987654321; - 启动后检查：
SHOW REPLICA STATUS\G（注意不是SLAVE）—— MySQL 8.0.23+ 已统一术语为REPLICA
切完立刻验证，但别只查 SHOW SLAVE STATUS
很多故障发生在“看起来正常”的瞬间。Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 只说明线程活着，不代表数据一致。
- 在新主库执行：
INSERT INTO test_switch VALUES (UNIX_TIMESTAMP(), 'switch_at_' || @@server_id); - 在新从库执行：
SELECT * FROM test_switch WHERE msg LIKE 'switch_at_%' ORDER BY ts DESC LIMIT 1;—— 检查时间戳是否相差 - 重点看
Retrieved_Gtid_Set和Executed_Gtid_Set是否完全相等（GTID 模式下），若不等，说明 SQL 线程卡在某条事务 - 最容易被忽略的是应用端：DNS 缓存、连接池（如 HikariCP 的
connection-test-query未指向新主）、JDBC URL 里的host还连着老地址
整个过程最脆弱的一环，是原主库执行 FLUSH TABLES WITH READ LOCK 到 UNLOCK TABLES 之间的窗口——哪怕只有 2 秒，如果应用在此期间发起长事务或批量写入，就会导致 binlog 位置漂移、后续复制断裂。这不是配置问题，而是操作节奏问题：它无法自动化，只能靠人盯住 SHOW PROCESSLIST 并预判业务低峰。
