从库提升与 REPLICAOF NO ONE
REPLICAOF NO ONE 让当前从库停止复制并把自己提升为独立主库：角色由 slave 变为 master，已有数据保留，之后不再接收旧主的写入。这是计划内切换（机房迁移、机器下线、版本升级、维护窗口）的核心动作；故障场景下的自动切换由哨兵或集群完成，但内部同样是先选出候选节点再提升。旧版本命令名是 SLAVEOF，新版本以 REPLICAOF 为准，两者语义相同。
基本信息
| 提升命令 | REPLICAOF NO ONE |
|---|---|
| 跟随命令 | REPLICAOF <host> <port>，把实例重新指向主库 |
| 历史命令 | SLAVEOF，功能等价，新版本统一用 REPLICAOF |
| 角色确认 | INFO replication 的 role 字段由 slave 变为 master |
| 提升前提 | 从库已完成追平，且旧主已停止写入 |
| 只读限制 | replica-read-only 只约束从库角色；提升为主库后该限制不再生效 |
典型使用场景
- 机房或可用区迁移：把写入切到目标机房的实例，再处理原实例
- 维护窗口：临时提升一个从库接管写入，原主修好后再改回从库角色
- 演练与压测：用接近真实数据规模的提升实例做验证，避免在线上主库上压测
- 哨兵切换后的收尾：确认新主已生效，手工把游离节点重新指向新主
- 版本升级：先让新版本实例通过复制追平，再提升为新主以缩短不可写时间
切换动作顺序
切换动作顺序
redis-cli -h 10.0.0.12 -p 6379 INFO replication | grep -E 'role:slave|slave_repl_offset|master_link_status' # 1 确认从库状态
redis-cli -h 10.0.0.11 -p 6379 INFO replication | grep master_repl_offset # 2 对比主库偏移量，确认已追平
redis-cli -h 10.0.0.12 -p 6379 REPLICAOF NO ONE # 3 提升为目标主库
redis-cli -h 10.0.0.12 -p 6379 INFO replication | grep -E 'role:master|connected_slaves' # 4 确认角色
redis-cli -h 10.0.0.13 -p 6379 REPLICAOF 10.0.0.12 6379 # 5 其余从库改指新主
redis-cli -h 10.0.0.12 -p 6379 INFO replication | grep 'slave0:' # 6 确认新拓扑已建立切换步骤与目的
| 步骤 | 动作 | 目的 |
|---|---|---|
| 停写 | 应用或代理停止往旧主写 | 避免双主同时接收写入产生分叉 |
| 追平确认 | 对比主从偏移量差值 | 确保提升后不丢未同步的最后一批写入 |
| 提升 | 在目标从库执行 REPLICAOF NO ONE | 目标实例成为新主并保留现有数据 |
| 改指向 | 其余从库执行 REPLICAOF 新主地址 | 重建复制拓扑，避免集群分裂 |
| 切流量 | 客户端、VIP、代理或 DNS 指到新主 | 应用恢复写入能力 |
| 旧主处理 | 按需设为新主的从库或直接下线 | 消除第二写入源，恢复单主结构 |
提升前要确认从库确实追平：对比主库的 master_repl_offset 与从库的 slave_repl_offset，差值为 0 或仅有极小波动才算安全；差值明显时先等收敛，或用 WAIT 让主库确认数据已落到从库再动手。切换窗口的取舍是先保数据正确再追可用性。
双主写入一旦发生，两份数据分叉后的合并成本极高，几乎没有便宜的补救手段。因此「先停写、再提升」的顺序不能颠倒，也不要指望应用层的重试把写入自动落到新主上。