提升从库怎么做
提升从库的动作用一串固定命令完成：停复制、清理复制元数据、关闭只读保护，然后确认服务端元信息正常。这里最容易漏的是 RESET REPLICA ALL——它清掉历史通道与中继日志，防止新主残留旧复制配置；而 server_uuid 与 server_id 保持原样即可，不需要改动。整个流程最好固化成脚本并提前演练过，真到切换那一刻才不会手忙脚乱。
基本信息
| 步骤 | STOP REPLICA → RESET REPLICA ALL → 关闭只读 → 验证 |
|---|---|
| 元数据 | server_uuid 与 server_id 保持不变 |
| 写入验证 | 写测试表并检查双写探针是否正常 |
| 后续动作 | 提升后立即做一次全量备份作为新基线 |
| 前提 | 确认从库已追平，没有落后事务 |
典型使用场景
- 计划内的主从切换
- 故障之后手工提升可用的从库
- 演练提升流程并记录实际耗时
- 下线旧主前的角色腾挪
- 重建拓扑时确定新的主库
提升命令序列
提升命令序列
STOP REPLICA;
RESET REPLICA ALL; -- 清空复制元数据与中继日志
SET GLOBAL super_read_only = OFF;
SET GLOBAL read_only = OFF;
-- 检查
SELECT @@GLOBAL.read_only, @@GLOBAL.super_read_only;
SELECT @@GLOBAL.gtid_executed;
SELECT @@GLOBAL.server_uuid;
-- 建议：提升后立即做一次全备，作为新拓扑的基线步骤与容易漏的点
| 步骤 | 作用 | 容易漏的点 |
|---|---|---|
| STOP REPLICA | 停止复制线程 | 不停就直接提升会留下半开状态 |
| RESET REPLICA ALL | 清空通道与中继日志 | 漏做会残留旧通道 |
| 关闭 super_read_only | 允许写入 | 只关 read_only 并不够 |
| 参数检查 | 确认只读开关状态 | 用 SELECT 确认，别凭记忆 |
| 立即备份 | 建立新基线 | 不做则下一次故障无从恢复 |
提升后的第一件事是验证写入：执行一条无害的写入或建一张测试表确认可写，再看应用侧是否恢复正常，别只盯着参数值。同时检查复制相关的后台线程是否已经清理干净，避免新旧状态混在一起。
旧主与其它从库的改挂是第二步：先保证新主可写、数据正确，再修拓扑。同时改动多个变量会让问题难以定位，处置时间也被拉长。
提升前必须确认从库已经追平：Seconds_Behind_Source 与 GTID 差集都要看，没追平就提升等于主动丢掉最后一段事务。