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

積跬步_成千裡發表於2018-11-19
Redis持久化

為了能夠重用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 " "

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

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相同

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

總結(Which one)

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

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

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

同時開啟兩種持久化方式

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

效能建議

  因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要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檔案，載入較新的那個,新浪微博就選用了這種架構。

相關文章