Redis開啓AOF致使的刪庫事件

事件背景

Redis主從開啓AOF，錯誤操做致使數據被清空。
Redis主要做用：緩存、隊列。

---

事故過程

Redis搭建了主從，持久化方式爲RDB，RDB沒有定時備份，且AOF都沒有開啓。
考慮到開啓AOF會使Redis安全性更高，因此嘗試先在從機作測試，沒問題後再上主機。

Redis開啓AOF的方式很是簡單，打開Redis的conf文件，找到【appendonly】配置項，將【no】改成【yes】重啓服務便可。

Redis從機重啓後，成功在數據目錄生成了百M以上的【appendonly.aof】文件，以該aof文件單獨啓動Redis實例，生成的數據和單獨以RDB文件啓動生成的數據同樣，所以判斷從機AOF配置成功。

接着直接上了主機，Redis主機以一樣的方式配置AOF後，結果實例重啓的瞬間，Redis主從數據被清空，主從AOF及RDB文件大小接近0M。

---

問題分析

一、爲何在已經開啓RDB持久化的狀況下，還打算開啓AOF？
解答：同時開啓兩種持久化，Redis擁有足以媲美PostgreSQL的數據安全性。

RDB 持久化能夠在指定的時間間隔內生成數據集的時間點快照，經常使用作備份。
AOF 持久化記錄服務器執行的全部寫操做命令，並在服務器啓動時，經過從新執行這些命令來還原數據集。

RDB默認的快照保存配置：
save 900 1     #900秒內若是超過1個key被修改，則發起快照保存
save 300 10    #300秒內容如超過10個key被修改，則發起快照保存
save 60 10000  #60秒內容如超過10000個key被修改，則發起快照保存

而AOF默認策略則爲每秒鐘一次fsync
固然你也能夠設置不一樣的fsync策略，好比無fsync
或者每秒鐘一次fsync，或者每次執行寫入命令時fsync

AOF文件有序地保存了對數據庫執行的全部寫入操做，
這些寫入操做以Redis協議的格式保存。
所以AOF文件的內容很是容易被人讀懂，對文件進行分析也很輕鬆。 
導出AOF文件也很是簡單：舉個例子，若是你不當心執行了 FLUSHALL 命令，
但只要AOF文件未被重寫，那麼只要中止服務器，
移除AOF文件末尾的FLUSHALL命令，並重啓Redis，
就能夠將數據集恢復到FLUSHALL執行以前的狀態。

有效地利用以上的RDB和AOF特性，能使Redis擁有足以媲美PostgreSQL的數據安全性。

二、爲何在從機AOF配置成功的狀況下，主機開啓AOF，主從數據瞬間被清空？
解答：首先得明白Redis有這麼一個特性，即兩種持久化同時開啓的狀況下，Redis啓動默認加載AOF文件恢復數據。

Redis從機因爲事先沒有開啓AOF，配置重啓後，從機會生成一個空的AOF文件並默認加載，這時從機數據是空的，但因爲配置了主從，從機會同步主機數據，因此你會發現新生成的AOF文件大小在迅速增加。所以Redis從機開啓AOF後，數據最終是沒有問題的。

這時候Redis主機也配置AOF並重啓，主機生成AOF並默認加載，數據瞬間被清空，同時主機RDB發現60秒內有超過10000個key被修改，發起了快照保存，RDB數據也被清空。因爲都是內存操做，因此很是快。最後再主從同步，全部數據被刪。

三、兩種持久化同時開啓的狀況下，Redis啓動爲何默認選擇加載AOF而不是RDB文件來恢復數據？
解答：AOF默認策略爲每秒鐘一次fsync，因此一般狀況下，AOF文件所保存的數據相對RDB更完整。

四、AOF 持久化會記錄服務器執行的全部寫操做命令，那麼數據被清空後，爲何不能經過AOF文件的日誌記錄恢復數據？
解答：Redis會自動地在後臺對AOF進行重寫，重寫後的新AOF文件包含了恢復當前數據集所需的最小命令集合

爲何會重寫？

由於AOF記錄了服務器執行的全部寫操做命令，而RDB自己又是一個很是緊湊的文件
因此對於相同的數據集來講，AOF文件的體積一般要大於RDB文件的體積
而體積大了終究很差，好比Redis重啓默認加載AOF文件就要更多的時間

五、面試官若是問你，如何在不用【config set】命令的狀況下，將Redis持久化由RDB切換到AOF，你怎麼回答？
解答：呵呵，利用主從。。。從機配置AOF重啓後，將生成的AOF文件複製至主機Redis數據目錄，主機配置AOF後再重啓。

注：在 Redis 2.2 或以上版本，經過【config set】能夠在不重啓的狀況下，從 RDB 切換到 AOF。
1）爲最新的 dump.rdb 文件建立一個備份。
2）將備份放到一個安全的地方。
3）執行如下兩條命令：
redis-cli> CONFIG SET appendonly yes
redis-cli> CONFIG SET save ""

4）確保命令執行以後，數據庫的鍵的數量沒有改變。
5）確保寫命令會被正確地追加到 AOF 文件的末尾。

步驟 3 執行的第一條命令開啓了AOF功能：<font style="color:red">Redis會阻塞直到初始AOF文件建立完成爲止</font>，以後Redis會繼續處理命令請求， 並開始將寫入命令追加到 AOF 文件末尾。
步驟 3 執行的第二條命令用於關閉RDB功能。這一步是可選的，若是你願意的話，也能夠同時使用RDB和AOF這兩種持久化功能。

不過別忘了在redis.conf中打開AOF功能！不然的話，服務器重啓以後，以前經過【CONFIG SET】設置的配置就會被遺忘，程序會按原來的配置來啓動服務器。