Redis Cluster部分分片Key为0报NOREPLICAS错误如何解决

报错触发逻辑 #

NOREPLICAS Not enough good replicas to write是Redis主节点开启副本写入校验后的主动拦截逻辑：当主节点统计到符合健康要求的从节点数量低于min-replicas-to-write配置阈值时，会直接拒绝写入请求，避免数据没有足够副本带来的丢失风险。

根因排查步骤 #

• 先查异常分片主节点的副本校验配置：登录对应异常分片的master实例，执行CONFIG GET min-replicas-*，确认min-replicas-to-write、min-replicas-max-lag两个参数值。你们采用1主2从架构，如果min-replicas-to-write被设为2，只要任意一个从节点复制异常就会触发报错；如果min-replicas-max-lag设的过小（比如小于5s），服务器IO抖动就可能导致从节点被判定为不健康。
• 核查从节点复制健康状态：在异常分片master上执行CLUSTER REPLICAS <当前master的节点ID>列出所有关联从节点，再逐个登录从节点执行INFO REPLICATION，重点确认三个状态：
  • master_link_status是否为up，如果是down说明主从复制链路已经断开
  • master_last_io_seconds_ago是否超过min-replicas-max-lag阈值，超过就会被主节点判定为无效副本
  • slave-priority是否被误设为0，该值为0的从节点不会被计入有效副本列表，也不参与故障转移
• 核查分片哈希槽分配完整性：执行CLUSTER SLOTS遍历所有槽位归属，确认3个异常分片负责的哈希槽是否存在未绑定、处于迁移/导入中间态的问题。如果槽位归属异常，CRC16路由规则就不会把Key正常调度到这些分片，直接导致Key存量远低于正常分片——你们之前手动切主未走标准副本晋升流程，大概率会触发槽位归属不一致的问题。
• 核查集群节点超时配置与资源负载：执行CONFIG GET cluster-node-timeout确认节点超时阈值，同时排查服务器CPU、内存、网络IO使用率。单台Ubuntu节点跑6个Redis实例如果没做资源隔离，很容易出现资源争抢，导致节点心跳超时、从节点复制断连，被主节点判定为不健康。

对应修复方案 #

• 修复异常复制链路：如果查到从节点master_link_status为down，在从节点上执行REPLICAOF <对应master的IP> <master端口>重新建立复制关系，等INFO REPLICATION中master_sync_in_progress变为0、复制偏移量和主节点追平后，主节点就会重新将其计入健康副本列表。如果是slave-priority被误设为0，执行CONFIG SET slave-priority 1恢复默认值，再执行CONFIG REWRITE持久化到配置文件。
• 调整不合理配置参数：1主2从架构下建议将min-replicas-to-write设为1，保证只要有1个健康从节点就可以正常写入；min-replicas-max-lag建议设为10-15s，避免偶发IO抖动导致副本判定异常；cluster-node-timeout建议设为15s，不要低于10s，调整后都要执行CONFIG REWRITE持久化。
• 修复哈希槽异常：如果查到存在未分配、处于中间状态的槽位，执行CLUSTER SETSLOT <槽编号> NODE <对应分片master的节点ID>将槽位固定绑定到正确的主节点，确认16384个槽全部完成分配无遗漏后，Key会按照哈希路由规则正常写入这些分片，存量会逐步趋近正常分片的31-32K水平。
• 规范后续运维操作：后续主从切换统一走集群标准流程，需要切主时在目标从节点执行CLUSTER FAILOVER，强制场景可加TAKEOVER参数，不要直接手动修改主从映射关系不做集群视图校验。另外单节点部署多实例时建议给每个Redis实例绑定独立CPU核，预留足够内存，避免实例间资源争抢导致的连锁异常。

修复完成后可以先往异常分片所属槽位写入测试Key，确认不再报NOREPLICAS错误，再持续观察1-2小时，确认分片Key数正常增长、CLUSTER INFO中cluster_state为ok、cluster_slots_fail计数为0即可。

内容的提问来源于stack exchange，提问作者GEnc B