探究Redis兩種持久化方式下的數據恢復

    對長期奮戰在一線的後端開發人員來講，都知道redis有兩種持久化方式RDB和AOF，雖然說你們都知道這兩種方式大概運做方式，但想必有實操瞭解得不會太多。

    這裏是本身實操兩種持久化方式的一點點記錄。 

    先看如下摘錄自redis官網原文解釋(固然原文是English，這裏用google翻譯過了。)

Redis持久性

Redis提供了不一樣的持久性選項範圍：

 

RDB持久性按指定的時間間隔執行數據集的時間點快照。

AOF持久性會記錄服務器接收的每一個寫入操做，這些操做將在服務器啓動時再次播放，以重建原始數據集。 使用與Redis協議自己相同的格式記錄命令，而且僅採用追加方式。 當日志太大時，Redis能夠在後臺重寫日誌。

若是但願，只要您的數據在服務器運行時就一直存在，則能夠徹底禁用持久性。

能夠在同一實例中同時合併AOF和RDB。 請注意，在這種狀況下，當Redis從新啓動時，AOF文件將用於重建原始數據集，由於它能夠保證是最完整的。

要理解的最重要的事情是RDB與AOF持久性之間的不一樣權衡。 讓咱們從RDB開始：

 

RDB的優點

RDB是Redis數據的很是緊湊的單文件時間點表示。 RDB文件很是適合備份。 例如，您可能但願在最近的24小時內每小時存檔一次RDB文件，並在30天以內天天保存一次RDB快照。 這使您能夠在發生災難時輕鬆還原數據集的不一樣版本。

RDB對於災難恢復很是有用，它是一個緊湊的文件，能夠傳輸到遠程數據中心或Amazon S3（可能已加密）上。

RDB最大限度地提升了Redis的性能，由於Redis父進程爲了持久化所須要作的惟一工做就是分叉一個孩子，其他的都將作。 父實例將永遠不會執行磁盤I / O或相似操做。

與AOF相比，RDB容許大型數據集更快地重啓。

 

RDB的缺點

若是您須要在Redis中止工做（例如斷電後）的狀況下最大程度地減小數據丟失的機會，則RDB很差。 您能夠在生成RDB的位置配置不一樣的保存點 （例如，在至少五分鐘以後，對數據集進行100次寫入，可是您能夠有多個保存點）。 可是，一般會每隔五分鐘或更長時間建立一次RDB快照，所以，若是Redis出於任何緣由在沒有正確關閉的狀況下中止工做，則應該準備丟失最新的數據分鐘。

RDB須要常用fork（）才能使用子進程將其持久化在磁盤上。 若是數據集很大，Fork（）可能很耗時，而且若是數據集很大且CPU性能不佳，則可能致使Redis中止爲客戶端服務幾毫秒甚至一秒鐘。 AOF還須要fork（），但您能夠調整要重寫日誌的頻率，而無需在持久性上進行權衡。

 

AOF的優點

使用AOF Redis更加持久：您能夠有不一樣的fsync策略：徹底沒有fsync，每秒fsync，每一個查詢fsync。 使用默認策略fsync時，每秒的寫入性能仍然很好（fsync是使用後臺線程執行的，而且在沒有進行fsync的狀況下，主線程將盡力執行寫入操做。）可是您只能損失一秒鐘的寫入時間。

AOF日誌僅是一個追加日誌，所以，若是斷電，也不會出現尋道或損壞問題。 即便因爲某種緣由（磁盤已滿或其餘緣由）以半寫命令結束日誌，redis-check-aof工具也能夠輕鬆修復它。

Redis太大時，Redis能夠在後臺自動重寫AOF。 重寫是徹底安全的，由於Redis繼續追加到舊文件時，會生成一個全新的文件，其中包含建立當前數據集所需的最少操做集，一旦準備好第二個文件，Redis會切換這兩個文件並開始追加到新的那一個。

AOF以易於理解和解析的格式包含全部操做的日誌。 您甚至能夠輕鬆導出AOF文件。 例如，即便您使用FLUSHALL命令刷新了全部錯誤文件 ，若是在此期間未執行任何日誌重寫操做，您仍然能夠保存數據集，只是中止服務器，刪除最新命令並從新啓動Redis。

 

AOF的缺點

對於相同的數據集，AOF文件一般大於等效的RDB文件。

根據確切的fsync策略，AOF可能比RDB慢。 一般，在將fsync設置爲每秒的狀況下，性能仍然很高，而且在禁用fsync的狀況下，即便在高負載下，它也應與RDB同樣快。 即便在巨大的寫負載狀況下，RDB仍然可以提供有關最大延遲的更多保證。

過去，咱們在特定命令中遇到過罕見的錯誤（例如，其中有一個涉及阻塞命令，例如BRPOPLPUSH ），致使生成的AOF在重載時沒法重現徹底相同的數據集。 這些錯誤不多見，咱們在測試套件中進行了測試，自動建立了隨機的複雜數據集，而後從新加載它們以檢查一切是否正常。 可是，RDB持久性幾乎是不可能的。 更明確地說：Redis AOF經過增量更新現有狀態來工做，就像MySQL或MongoDB同樣，而RDB快照一次又一次地建立全部內容，從概念上講更健壯。 可是-1）應該注意的是，每次Redis重寫AOF時，都會從數據集中包含的實際數據開始從頭開始從新建立AOF，與始終附加AOF文件相比（或重寫後的讀數），對錯誤的抵抗力更強舊的AOF，而不是讀取內存中的數據）。 2）咱們從未收到過有關真實環境中檢測到的AOF損壞的用戶報告。

 未完待續，今天困了，明天開始寫