背景：
機房級掉電演練，機房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）
redis中的RDB快照檔案恢復
在redis中我們使用rdb快照檔案恢復資料時，如果我們開啟了redis主從，我們需要先把redis從關掉，然後我們才能來執行redisrdb快照檔案恢復 因為從庫開啟，會導致redis主庫重啟讀取不到rdb檔案，會導致重啟過後rdb檔案是redis初始化的rdb，不是你要恢復的rdb檔案，我們把r...
Redis使用rdb檔案恢復資料
只在單台redis恢復，未使用集群。注意3個配置引數 dbfilename dump.rdb dir data root izbp143t3oxhfc3ar7jey0z redis 4.0.12 redis cli 127.0.0.1 6379 keys 1 user 127.0.0.1 6379 ...
如何解析 redis 的 rdb 檔案
目錄常見問題 faq 參考pip install rdbtools python lzf或者 git clone cd redis rdb tools sudo python setup.py installusage usage rdb options path to dump.rdb examp...