Redis的flushall/flushdb命令可以做數據清除，對于Redis的開發和運維人員有一定幫助，然而一旦誤操作，它的破壞性也是很明顯的。怎么才能快速恢復數據，讓損失達到最小呢？本文我們將結合之前學習的Redis相關知識進行分析，最后給出一個合理的方案
注意：為了方便說明，下文中除了AOF文件中的flushall/flushdb以外，其他所有的flushall/flushdb都用flush代替
本文假設進行flush操作的Redis是一對主從結構的主節點，其中鍵值對的個數是100萬，每秒寫入量是1000
一、緩存與存儲
被誤操作flush后，根據當前Redis是緩存還是存儲使用策略有所不同：
緩存：對于業務數據的正確性可能造成損失還小一點，因為緩存中的數據可以從數據源重新進行構建，但是在前面文章介紹了緩存雪崩和緩存穿透的相關知識，當前場景也有類似的地方，如果業務方并發量很大，可能會對 后端數據源造成一定的負載壓力，這個問題也是不容忽視
存儲：對業務方可能會造成巨大的影響，也許flush操作后的數據是重要配置，也可能是一些基礎數據，也可能是業務上的重要一環，如果沒有提 前做業務降級操作，那么最終反饋到用戶的應用可能就是報錯或者空白頁面 等，其后果不堪設想。即使做了相應的降級或者容錯處理，對于用戶體驗也有一定的影響
所以Redis無論作為緩存還是作為存儲，如何能在flush操作后快速恢復數據才是至關重要的。持久化文件肯定是恢復數據的媒介，下面將對AOF和RDB文件進行分析
二、借助AOF機制恢復
關于AOF語法可以參閱：之前我發表的Redis使用篇里關于AOF的介紹
Redis執行了flush操作后，AOF持久化文件會受到什么影響呢？如下所示：
appendonly no：對AOF持久化沒有任何影響，因為根本就不存在AOF文 件
appendonly yes：只不過是在AOF文件中追加了一條記錄，例如下面就是AOF文件中的flush操作記錄：
*1
$8
flushall
雖然Redis中的數據被清除掉了，但是AOF文件還保存著flush操作之前完整的數據，這對恢復數據是很有幫助的。注意問題如下：
調大AOF重寫參數auto-aof-rewrite-percentage和auto-aof-rewrite-minsize，讓Redis不能產生AOF自動重寫
拒絕手動bgrewriteaof
1）如果發生了AOF重寫，Redis遍歷所有數據庫重新生成AOF文件，并會覆蓋之前的AOF文件。所以如果AOF重寫發生了，也就意味著之前的數據就丟掉了，那么利用AOF文件來恢復的辦法就失效了。所以當誤操作后，需要考慮如下兩件事：
2）如果要用AOF文件進行數據恢復，那么必須要將AOF文件中的flushall相關操作去掉，為了更加安全，可以在去掉之后使用redis-check-aof這個工具去檢驗和修復一下AOF文件，確保AOF文件格式正確，保證數據恢復正常
三、RDB有什么變化?
Redis執行了flushall操作后，RDB持久化文件會受到什么影響呢？
1）如果沒有開啟RDB的自動策略：那么除非手動執行過save、bgsave或者發生了主從的全量復制，否則RDB文件也會保存flush操作之前的數據，可以作為恢復數據的數據源。注意問題如下：
RDB文件中的數據可能沒有AOF實時性高，也就是說，RDB文件很可能很久以前主從全量復制生成的，或者之前用save、bgsave備份的
防止手動執行save、bgsave，如果此時執行save、bgsave，新的RDB文件就不會包含flush操作之前的數據，被老的RDB文件進行覆蓋
2）如果開啟了RDB的自動策略：由于flush涉及鍵值數量較多，RDB文件會被清除，意味著使用RDB恢復基本無望
綜上所述，如果AOF已經開啟了，那么用AOF來恢復是比較合理的方式，但是如果AOF關閉了，那么RDB雖然數據不是很實時，但是也能恢復部分數據，完全取決于RDB是什么時候備份的。當然RDB并不是一無是處，它 的恢復速度要比AOF快很多，但是總體來說對于flush操作之后不是最好的恢復數據源
四、從節點有什么變化
Redis從節點同步了主節點的flush命令，所以從節點的數據也是被清除了，從節點的RDB和AOF的變化與主節點沒有任何區別
五、快速恢復數據
下面使用AOF作為數據源進行恢復演練
1）防止AOF重寫。快速修改Redis主從的auto-aof-rewrite-percentage和 auto-aof-rewrite-min-size變為一個很大的值，從而防止了AOF重寫的發生， 例如：
config set auto-aof-rewrite-percentage 1000
config set auto-aof-rewrite-min-size 100000000000
2）去掉主從AOF文件中的flush相關內容：
*1
$8
flushall
3）重啟Redis主節點服務器，恢復數據
六、總結
本文通過flush誤操作的數據恢復，重新梳理了持久化、復制的相關知識，這里建議運維人員提前準備shell腳本或者其他自動化的方式處理，因為故障不等人，對于flush這樣的危險操作，應該通過有效的方式進行規避，下節將介紹具體的方法
