Redis集群迁移数据丢失怎么排查，常见问题与定位方法

不少运维朋友做Redis集群跨版本、跨机房迁移时，经常碰到迁完做数据校验才发现丢了一些key，心里一紧。明明迁移工具没报错，日志也看不出啥，但 key 就是少了。这种时候别急着回滚，先冷静下来把几个关键点捋一遍，大部分丢数据的问题其实都能定位到。

我习惯先查两边集群的基础配置。别小看这个，maxmemory 设置不一样、淘汰策略有差异，迁移过来的 key 可能还没落地就被干掉了。比如源集群用的 allkeys-lru，目标集群设的 noeviction，写入时内存满了直接报错丢弃，工具如果没处理好重试，这批数据就丢了。还有持久化配置，源端开着 AOF 目标端只开了 RDB，主从切换时没触发一次全量保存，增量部分也会丢。这类配置不一致的坑踩过好几次，建议迁移前把两边 config get 一把对齐。

接下来看槽位分配。集群模式下数据分布在 16384 个槽上，迁移过程中如果某个槽位没完整迁过去，或者迁了一半网络断了，部分 key 会滞留在源节点，目标那边查不到。可以用 redis-cli --cluster check 看下槽位分布，再对比迁移前后的 cluster slots 信息，尤其注意那些处于 importing 或 migrating 状态的槽。有一回我们迁完以为好了，结果有个槽一直在源节点挂着，check 命令提示有 3 个 key 没迁走，手动 migrate 过去才补上。

增量同步这块也容易出问题。做在线迁移时一般会开启主从复制，让目标实例追增量。如果源端写入 QPS 很高，而复制缓冲区 repl-backlog-size 设得太小，主从断连重连后增量命令被冲掉，就只能全量同步，中间这段新写入的数据就丢了。网络抖动也是，短暂断连触发了全量同步，但工具没感知到，丢数据就成了静默的。排查时可以看 slave 的 master_link_down_since_seconds 指标，还有 repl_backlog_active 是否为 1。

最后别忘了排除业务侧的影响。有些场景下 key 设置了过期时间，迁移刚好跨过了那个点，目标端自然就没了，这不算真丢失。还有那种业务逻辑里对同一个 key 反复写删的，幂等性没处理好，也会让人误以为丢了。拿 AOF 文件或者 RDB 备份对比一下，能排除掉大部分假丢失的情况。