• Redis的flushall/flushdb命令可以做數(shù)據(jù)清除，對于Redis的開發(fā)和運維人員有一定幫助，然而一旦誤操作，它的破壞性也是很明顯的。怎么才能快速恢復(fù)數(shù)據(jù)，讓損失達(dá)到最小呢？本文我們將結(jié)合之前學(xué)習(xí)的Redis相關(guān)知識進(jìn)行分析，最后給出一個合理的方案

• 注意：為了方便說明，下文中除了AOF文件中的flushall/flushdb以外，其他所有的flushall/flushdb都用flush代替

• 本文假設(shè)進(jìn)行flush操作的Redis是一對主從結(jié)構(gòu)的主節(jié)點，其中鍵值對的個數(shù)是100萬，每秒寫入量是1000

一、緩存與存儲

• 被誤操作flush后，根據(jù)當(dāng)前Redis是緩存還是存儲使用策略有所不同：

• • 緩存：對于業(yè)務(wù)數(shù)據(jù)的正確性可能造成損失還小一點，因為緩存中的數(shù)據(jù)可以從數(shù)據(jù)源重新進(jìn)行構(gòu)建，但是在前面文章介紹了緩存雪崩和緩存穿透的相關(guān)知識，當(dāng)前場景也有類似的地方，如果業(yè)務(wù)方并發(fā)量很大，可能會對 后端數(shù)據(jù)源造成一定的負(fù)載壓力，這個問題也是不容忽視

  • 存儲：對業(yè)務(wù)方可能會造成巨大的影響，也許flush操作后的數(shù)據(jù)是重要配置，也可能是一些基礎(chǔ)數(shù)據(jù)，也可能是業(yè)務(wù)上的重要一環(huán)，如果沒有提 前做業(yè)務(wù)降級操作，那么最終反饋到用戶的應(yīng)用可能就是報錯或者空白頁面 等，其后果不堪設(shè)想。即使做了相應(yīng)的降級或者容錯處理，對于用戶體驗也有一定的影響

• 所以Redis無論作為緩存還是作為存儲，如何能在flush操作后快速恢復(fù)數(shù)據(jù)才是至關(guān)重要的。持久化文件肯定是恢復(fù)數(shù)據(jù)的媒介，下面將對AOF和RDB文件進(jìn)行分析

二、借助AOF機(jī)制恢復(fù)

• 關(guān)于AOF語法可以參閱：之前我發(fā)表的Redis使用篇里關(guān)于AOF的介紹

• Redis執(zhí)行了flush操作后，AOF持久化文件會受到什么影響呢？如下所示：

• • appendonly no：對AOF持久化沒有任何影響，因為根本就不存在AOF文 件

  • appendonly yes：只不過是在AOF文件中追加了一條記錄，例如下面就是AOF文件中的flush操作記錄：

*1 $8 flushall

• 雖然Redis中的數(shù)據(jù)被清除掉了，但是AOF文件還保存著flush操作之前完整的數(shù)據(jù)，這對恢復(fù)數(shù)據(jù)是很有幫助的。注意問題如下：

• • 調(diào)大AOF重寫參數(shù)auto-aof-rewrite-percentage和auto-aof-rewrite-minsize，讓Redis不能產(chǎn)生AOF自動重寫

  • 拒絕手動bgrewriteaof

  • 1）如果發(fā)生了AOF重寫，Redis遍歷所有數(shù)據(jù)庫重新生成AOF文件，并會覆蓋之前的AOF文件。所以如果AOF重寫發(fā)生了，也就意味著之前的數(shù)據(jù)就丟掉了，那么利用AOF文件來恢復(fù)的辦法就失效了。所以當(dāng)誤操作后，需要考慮如下兩件事：

  • 2）如果要用AOF文件進(jìn)行數(shù)據(jù)恢復(fù)，那么必須要將AOF文件中的flushall相關(guān)操作去掉，為了更加安全，可以在去掉之后使用redis-check-aof這個工具去檢驗和修復(fù)一下AOF文件，確保AOF文件格式正確，保證數(shù)據(jù)恢復(fù)正常

三、RDB有什么變化?

• Redis執(zhí)行了flushall操作后，RDB持久化文件會受到什么影響呢？

• 1）如果沒有開啟RDB的自動策略：那么除非手動執(zhí)行過save、bgsave或者發(fā)生了主從的全量復(fù)制，否則RDB文件也會保存flush操作之前的數(shù)據(jù)，可以作為恢復(fù)數(shù)據(jù)的數(shù)據(jù)源。注意問題如下：

• • RDB文件中的數(shù)據(jù)可能沒有AOF實時性高，也就是說，RDB文件很可能很久以前主從全量復(fù)制生成的，或者之前用save、bgsave備份的

  • 防止手動執(zhí)行save、bgsave，如果此時執(zhí)行save、bgsave，新的RDB文件就不會包含flush操作之前的數(shù)據(jù)，被老的RDB文件進(jìn)行覆蓋

• 2）如果開啟了RDB的自動策略：由于flush涉及鍵值數(shù)量較多，RDB文件會被清除，意味著使用RDB恢復(fù)基本無望

• 綜上所述，如果AOF已經(jīng)開啟了，那么用AOF來恢復(fù)是比較合理的方式，但是如果AOF關(guān)閉了，那么RDB雖然數(shù)據(jù)不是很實時，但是也能恢復(fù)部分?jǐn)?shù)據(jù)，完全取決于RDB是什么時候備份的。當(dāng)然RDB并不是一無是處，它 的恢復(fù)速度要比AOF快很多，但是總體來說對于flush操作之后不是最好的恢復(fù)數(shù)據(jù)源

四、從節(jié)點有什么變化

• Redis從節(jié)點同步了主節(jié)點的flush命令，所以從節(jié)點的數(shù)據(jù)也是被清除了，從節(jié)點的RDB和AOF的變化與主節(jié)點沒有任何區(qū)別

五、快速恢復(fù)數(shù)據(jù)

• 下面使用AOF作為數(shù)據(jù)源進(jìn)行恢復(fù)演練

• 1）防止AOF重寫。快速修改Redis主從的auto-aof-rewrite-percentage和 auto-aof-rewrite-min-size變?yōu)橐粋€很大的值，從而防止了AOF重寫的發(fā)生， 例如：

config set auto-aof-rewrite-percentage 1000 config set auto-aof-rewrite-min-size 100000000000

• 2）去掉主從AOF文件中的flush相關(guān)內(nèi)容：

*1 $8 flushall

• 3）重啟Redis主節(jié)點服務(wù)器，恢復(fù)數(shù)據(jù)

六、總結(jié)

• 本文通過flush誤操作的數(shù)據(jù)恢復(fù)，重新梳理了持久化、復(fù)制的相關(guān)知識，這里建議運維人員提前準(zhǔn)備shell腳本或者其他自動化的方式處理，因為故障不等人，對于flush這樣的危險操作，應(yīng)該通過有效的方式進(jìn)行規(guī)避，下節(jié)將介紹具體的方法

總結(jié)

以上是生活随笔為你收集整理的Redis线上救命丸:01---误操作AOF、RDB恢复数据的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。