REPLICAOF 失效常见原因为网络不通、主节点 protected-mode yes 未配 bind 或 requirepass、从节点未设 masterauth；需 telnet 测试连通，关闭 protected-mode 或 bind 0.0.0.0，配置 masterauth 并写入 redis.conf 持久化。
REPLICAOF 命令执行后没生效，主从没连上
常见现象是执行 REPLICAOF 192.168.1.10 6379 后，用 INFO replication 查看仍显示 role:master，或 master_link_status:down。根本原因通常是网络不通、主节点未开启远程连接、或主节点配置了 protected-mode yes 且没配 bind 或 requirepass。
- 先在从节点上用
telnet 192.168.1.10 6379测试连通性；不通就查防火墙、Docker 网络或云服务器安全组 - 主节点必须关闭
protected-mode（设为no），或显式配置bind地址（如bind 0.0.0.0）并确保不暴露在公网 - 如果主节点启用了密码认证，从节点需同步设置
masterauth "yourpass"，否则握手阶段就会被拒绝 -
REPLICAOF是运行时命令，重启 Redis 后失效；要持久化，得写进redis.conf里，加两行：replicaof 192.168.1.10 6379和masterauth "yourpass"
主节点拒绝同步：error: NOAUTH Authentication required
这是最典型的权限断连场景——从节点发 SYNC 请求时，主节点要求 AUTH，但从节点没带密码过去。注意：这不是客户端连接密码，而是复制链路专用的 masterauth。
- 主节点的
requirepass只控制客户端连接，不影响复制协议本身；真正控制复制身份的是从节点上的masterauth配置项 - 不能靠在从节点执行
AUTH命令来“提前登录”，REPLICAOF触发的同步流程不复用当前连接的认证状态 - 若主节点密码含特殊字符（如
@、/），masterauth值无需 URL 编码，Redis 内部直接按字符串比对 - 验证方式：在从节点执行
CONFIG GET masterauth，确认返回值和主节点requirepass一致
从节点启动即报错：Failed to establish connection with master
Redis 启动时自动加载 redis.conf 中的 replicaof 指令，但如果此时主节点不可达，会持续重试并记录错误日志，但不会阻塞自身启动。用户感知到的“报错”，往往来自日志里的反复重连失败。
- 检查主节点是否真在运行：
redis-cli -h 192.168.1.10 -p 6379 PING应返回PONG - 从节点默认每秒重试一次；可通过
repl-ping-replica-period调整间隔，但不建议设太大，否则故障发现延迟高 - 如果主节点监听的是非标准端口（比如
6380），务必确认从节点配置中端口号写对，Redis 不会自动 fallback 到 6379 - 容器环境下特别注意：别用
localhost或127.0.0.1作为主节点地址，那指的是从节点容器自己的回环，不是宿主机或其他容器
主从切换后旧主节点无法自动降级为从节点
手动执行 REPLICAOF no one 是让节点停止复制、变回主节点；反过来，想让它重新成为从节点，不能只改配置文件再 reload，必须显式执行 REPLICAOF 命令或重启进程。
-
CONFIG REWRITE不会覆盖replicaof行，它只保存 run-time 修改的非复制类参数 - 如果原主节点已写入数据，又强行用
REPLICAOF接入新主，会触发全量同步（RDB + PSYNC），原有数据将被清空——这点极易被忽略 - 生产环境做故障恢复时，优先用
redis-cli --cluster failover（集群模式）或哨兵SENTINEL failover，避免手抖执行错方向 - 没有哨兵或集群时，建议把
REPLICAOF操作封装成脚本，并加入前置检查：比如确认目标主节点role是master、connected_slaves数量合理、无loading状态等
replication backlog 就开始累积，这个缓冲区大小直接影响从节点断线重连后能否走部分重同步（PSYNC）。默认 1MB 往往不够，尤其在写入压力大的场景下，容易退化为全量同步——这个细节，上线前就得调好。 
