Redis老rdb文件产生脏数据

背景：

机房级掉电演练，机房1的Redis集群被下电，现网集群没有开启持久化，靠双活机房数据实时同步做数据可靠性方案，机房1的集群恢复后，需要先恢复机房2到机房1的实时同步（增量），然后通过脚本执行存量数据全量同步，由于机房1为空集群，所以为了提升全量数据同步性能，一般不要求加--replace参数，即对端已有数据会被丢弃不同步。

问题：

机房1主集群数据恢复后，业务请求从机房2的Redis集群切回到机房1，开始并未发现异常，到业务高峰期，业务方通过AIOps监控发现成功率下降，分析发现从Redis集群中取到了错误数据，实际拿到了很早之前的value。

分析：

怀疑是机房2的源数据有问题，随机抽取一个问题key进行比对，发现机房2的value是正确的，于是先将业务请求切换到机房2恢复业务，同时分析机房1脏数据原因，通过redis日志发现，机房1的集群启动时先加载了本地rdb文件，然后才接受的机房2的数据，查看rdb文件最近修改时间，发现已经是2周以前了。

根因：

2周之前机房1Redis集群内部出现了单台主机故障，问题主机重启后从主节点同步了全量数据，redis主从全量同步时主节点会fork子进程把数据持久化到本地rdb文件中，拷贝到从节点所在主机，这样1份rdb文件会同时存在2台主机上，导致机房1的Redis集群掉电恢复之后优先加载了本地的2周之前的rdb文件，又因为掉电演练恢复数据时采用的不覆盖方式，这样2周之前的数据就存在机房1了，业务高峰时返回的错误值对业务成功率产生了影响。

规避：

1. 人为掉电演练前，增加排查删除rdb文件的环节；

2. 数据全量同步默认使用覆盖方式（--replace）