redis的持久化機制 (RDB&AOF)

Redis · 發表 2018-11-19 11:46:05

摘要：為了能夠重用 Redis 資料，或者防止系統故障，我們需要將 Redis 中的資料寫入到磁碟空間中，即持久化。 Redis 提供了兩種不同的持久化方法可以將資料儲存在磁碟中，一種叫快照 RDB ，另一種叫只追加檔案 AOF RDB 是什麼在指定的時間間隔內將記憶體中的資料集...

為了能夠重用 Redis 資料，或者防止系統故障，我們需要將 Redis 中的資料寫入到磁碟空間中，即持久化。 Redis 提供了兩種不同的持久化方法可以將資料儲存在磁碟中，一種叫快照 RDB ，另一種叫只追加檔案 AOF

RDB

是什麼

在指定的時間間隔內將記憶體中的資料集快照寫入磁碟( Snapshot )，它恢復時是將快照檔案直接讀到記憶體裡。

Redis 會單獨建立（ fork ）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。 RDB 的缺點是最後一次持久化後的資料可能丟失。

Fork

Fork 的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等）數值都和原程序一致，但是是一個全新的程序，並作為原程序的子程序。 Rdb 儲存的是 dump.rdb 檔案。

配置位置

Redis 的配置主要放置在 redis.conf ，可以通過修改配置檔案實現 Redis 許多特性，比如複製，持久化，叢集等。

如何觸發RDB快照

配置檔案中預設的快照配置
命令 save 或者是 bgsave

Save：save時只管儲存，其它不管，全部阻塞。
BGSAVE：Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求。
可以通過lastsave命令獲取最後一次成功執行快照的時間。
複製程式碼

執行 flushall 命令，也會產生 dump.rdb 檔案

如何恢復

將備份檔案 dump.rdb 移動到 redis 安裝目錄並啟動服務即可

優勢

適合大規模的資料恢復

對資料完整性和一致性要求不高

劣勢

在一定間隔時間做一次備份，所以如果 redis 意外 down 掉的話，就會丟失最後一次快照後的所有修改。

如何停止

動態所有停止RDB儲存規則的方法： redis-cli config set save " "

AOF(Append Only File)

是什麼

以日誌的形式來記錄每個寫操作，將 Redis 執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加檔案但不可以改寫檔案， redis 啟動之初會讀取該檔案重新構建資料，換言之， redis 重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作。 AOF儲存的是appendonly.aof檔案

AOF啟動/修復/恢復

正常恢復:
- 啟動：設定 yes ;修改預設的 appendonly no ，改為 yes
- 將有資料的 aof 檔案複製一份儲存到對應目錄( config get dir )
- 恢復：重啟 redis 然後重新載入
異常恢復:
- 啟動：設定 yes ;修改預設的 appendonly no ，改為 yes
- 備份被寫壞的 AOF 檔案
- 修復： Redis-check-aof --fix 進行修復
- 恢復：重啟 redis 然後重新載入

Rewrite

是什麼:

AOF採用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制,當AOF檔案的大小超過所設定的閾值時，
Redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集.可以使用命令bgrewriteaof
複製程式碼

重寫原理:

AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫(也是先寫臨時檔案最後再rename)，遍歷新程序的記憶體中資料，
每條記錄有一條的set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，
而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似。
複製程式碼

觸發機制：

Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。
複製程式碼

優勢

appendfsync always
appendfsync everysec
appendfsync no

劣勢

相同資料集的資料而言 aof 檔案要遠大於 rdb 檔案，恢復速度慢於 rdb
aof 執行效率要慢於 rdb ,每秒同步策略效率較好，不同步效率和 rdb 相同

總結(Which one)

RDB 持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存。

AOF 持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料, AOF 命令以 redis 協議追加儲存每次寫的操作到檔案末尾. Redis 還能對 AOF 檔案進行後臺重寫,使得 AOF 檔案的體積不至於過大。

只做快取：如果你只希望你的資料在伺服器執行的時候存在,你也可以不使用任何持久化方式。

同時開啟兩種持久化方式

在這種情況下,當 redis 重啟的時候會優先載入 AOF 檔案來恢復原始的資料,因為在通常情況下 AOF 檔案儲存的資料集要比 RDB 檔案儲存的資料集要完整. RDB的資料不實時，同時使用兩者時伺服器重啟也只會找 AOF 檔案。那要不要只使用 AOF 呢？作者建議不要，因為 RDB 更適合用於備份資料庫( AOF 在不斷變化不好備份)，快速重啟，而且不會有 AOF 可能潛在的 bug ，留著作為一個萬一的手段。

效能建議

因為 RDB 檔案只用作後備用途，建議只在 Slave 上持久化 RD B檔案，而且只要15分鐘備份一次就夠了，只保留 save 900 1 這條規則。

如果 Enalbe AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻 load 自己的 AOF 檔案就可以了。代價一是帶來了持續的 IO ，二是 AOFrewrite 的最後將 rewrite 過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少 AOFrewrite 的頻率， AOF 重寫的基礎大小預設值 64M 太小了，可以設到 5G 以上。預設超過原大小100%大小時重寫可以改到適當的數值。

如果不 Enable AOF ，僅靠 Master-Slave Replication 實現高可用性也可以。能省掉一大筆 IO 也減少了 rewrite 時帶來的系統波動。代價是如果 Master/Slave 同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個 Master/Slave 中的 RDB 檔案，載入較新的那個,新浪微博就選用了這種架構。