Redis(開發與運維):59---開發運維的陷阱之（flushall/flushdb誤操作：AOF、RDB恢復數據）

原創

2020-06-10 06:05

Redis的flushall/flushdb命令可以做數據清除，對於Redis的開發和運維人員有一定幫助，然而一旦誤操作，它的破壞性也是很明顯的。怎麼才能快速恢復數據，讓損失達到最小呢？本文我們將結合之前學習的Redis相關知識進行分析，最後給出一個合理的方案
注意：爲了方便說明，下文中除了AOF文件中的flushall/flushdb以外，其他所有的flushall/flushdb都用flush代替
本文假設進行flush操作的Redis是一對主從結構的主節點，其中鍵值對的個數是100萬，每秒寫入量是1000

一、緩存與存儲

被誤操作flush後，根據當前Redis是緩存還是存儲使用策略有所不同：
- 緩存：對於業務數據的正確性可能造成損失還小一點，因爲緩存中的數據可以從數據源重新進行構建，但是在前面文章介紹了緩存雪崩和緩存穿透的相關知識，當前場景也有類似的地方，如果業務方併發量很大，可能會對後端數據源造成一定的負載壓力，這個問題也是不容忽視
- 存儲：對業務方可能會造成巨大的影響，也許flush操作後的數據是重要配置，也可能是一些基礎數據，也可能是業務上的重要一環，如果沒有提前做業務降級操作，那麼最終反饋到用戶的應用可能就是報錯或者空白頁面等，其後果不堪設想。即使做了相應的降級或者容錯處理，對於用戶體驗也有一定的影響
所以Redis無論作爲緩存還是作爲存儲，如何能在flush操作後快速恢復數據纔是至關重要的。持久化文件肯定是恢復數據的媒介，下面將對AOF和RDB文件進行分析

二、藉助AOF機制恢復

關於AOF語法可以參閱：https://blog.csdn.net/qq_41453285/article/details/106106585
Redis執行了flush操作後，AOF持久化文件會受到什麼影響呢？如下所示：
- appendonly no：對AOF持久化沒有任何影響，因爲根本就不存在AOF文件
- appendonly yes：只不過是在AOF文件中追加了一條記錄，例如下面就是AOF文件中的flush操作記錄：

*1
$8
flushall

雖然Redis中的數據被清除掉了，但是AOF文件還保存着flush操作之前完整的數據，這對恢復數據是很有幫助的。注意問題如下：
- 1）如果發生了AOF重寫，Redis遍歷所有數據庫重新生成AOF文件，並會覆蓋之前的AOF文件。所以如果AOF重寫發生了，也就意味着之前的數據就丟掉了，那麼利用AOF文件來恢復的辦法就失效了。所以當誤操作後，需要考慮如下兩件事：
  - 調大AOF重寫參數auto-aof-rewrite-percentage和auto-aof-rewrite-minsize，讓Redis不能產生AOF自動重寫
  - 拒絕手動bgrewriteaof
- 2）如果要用AOF文件進行數據恢復，那麼必須要將AOF文件中的flushall相關操作去掉，爲了更加安全，可以在去掉之後使用redis-check-aof這個工具去檢驗和修復一下AOF文件，確保AOF文件格式正確，保證數據恢復正常

關於RDB語法可以參閱：https://blog.csdn.net/qq_41453285/article/details/106106568
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操作之後不是最好的恢復數據源

下面使用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

*1
$8
flushall

本文通過flush誤操作的數據恢復，重新梳理了持久化、複製的相關知識，這裏建議運維人員提前準備shell腳本或者其他自動化的方式處理，因爲故障不等人，對於flush這樣的危險操作，應該通過有效的方式進行規避，下節將介紹具體的方法

發表評論

所有評論

還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.