角色为何会在重启后变形
复制角色属于运行期状态：REPLICAOF 改的是当前进程的身份。重启后用什么身份，取决于配置文件或启动参数里有没有把角色固化下来。只靠动态命令建立的从库，重启后可能以主库身份启动，形成两个节点都自认主库的「幽灵双主」。
基本信息
| 相关命令 | REPLICAOF <host> <port>、REPLICAOF NO ONE |
|---|---|
| 固化手段 | 配置文件里的 replicaof 指令，或 CONFIG REWRITE 把运行配置写回配置文件 |
| 容器场景 | 启动参数与镜像模板才是权威，动态命令随进程消失 |
| 核对方式 | INFO replication 的 role 与 master_host，配合启动日志 |
典型使用场景
- 计划内主从切换：切换后要确认新主库重启不会退回从库身份
- 解除复制：REPLICAOF NO ONE 之后清理配置文件里残留的 replicaof
- 容器与编排部署：角色写在启动命令或模板里，重启后的角色由参数决定
- 故障复盘：重启过实例的集群要检查有没有出现双主与数据分叉
核对与固化
核对与固化
redis-cli INFO replication | grep -E 'role|master_host' # 确认当前角色
redis-cli CONFIG GET replicaof # 配置里是否固化了角色
redis-cli CONFIG REWRITE # 把当前运行配置写回配置文件（需有可写配置文件）
# 重启前留一份配置副本，重启后对比 role 与 master_host
redis-cli REPLICAOF NO ONE # 解除复制，记得同步清理配置文件里的残留重启后的角色对照
| 场景 | 配置里的 replicaof | 重启后角色 |
|---|---|---|
| 常规从库 | 有 | 仍为从库 |
| 动态命令建立且配置文件不可写 | 无 | 可能以主库身份启动 |
| 容器内执行动态命令 | 无 | 按启动参数回到镜像默认角色 |
| 解除复制后未清理配置 | 残留 | 下次重启又变回从库 |
双主的直接后果是数据分叉：两个节点各自接受写入，谁是权威没有自动判据，恢复时通常只能保留一份数据并丢弃另一份，必须靠人工确认。
把角色当成配置项来管理：写进配置文件或启动参数，运行期命令只用于临时调整；变更之后用 INFO replication 与启动日志双重确认，而不是只看进程是否活着。