Redis 通過 RDB 方式進行資料備份與還原

WeihanLi發表於2021-03-14

Redis 通過 RDB 方式進行資料備份與還原

Intro

有的時候我們需要對 Redis 的資料進行遷移,今天介紹一下通過 RDB(快照)檔案進行 Redis 資料的備份和還原

Redis 持久化

Redis 的資料持久化有兩種機制,一種是 RDB(Redis Database),一種是 AOF(Append Only File)

Redis 提供了不同級別的持久化方式:

  • RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存.
  • AOF持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加儲存每次寫的操作到檔案末尾.Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大.
  • 如果你只希望你的資料在伺服器執行的時候存在,你也可以不使用任何持久化方式.
  • 你也可以同時開啟兩種持久化方式, 在這種情況下, 當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整.

RDB的優點

  • RDB是一個非常緊湊的檔案,它儲存了某個時間點得資料集,非常適用於資料集的備份,比如你可以在每個小時報儲存一下過去24小時內的資料,同時每天儲存過去30天的資料,這樣即使出了問題你也可以根據需求恢復到不同版本的資料集.

  • RDB是一個緊湊的單一檔案,很方便傳送到另一個遠端資料中心或者亞馬遜的S3(可能加密),非常適用於災難恢復.

  • RDB在儲存RDB檔案時父程式唯一需要做的就是fork出一個子程式,接下來的工作全部由子程式來做,父程式不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的效能.

  • 與AOF相比,在恢復大的資料集的時候,RDB方式會更快一些.

RDB的缺點

  • 如果你希望在redis意外停止工作(例如電源中斷)的情況下丟失的資料最少的話,那麼RDB不適合你.雖然你可以配置不同的save時間點(例如每隔5分鐘並且對資料集有100個寫的操作),是Redis要完整的儲存整個資料集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的儲存,萬一在Redis意外當機,你可能會丟失幾分鐘的資料.

  • RDB 需要經常fork子程式來儲存資料集到硬碟上,當資料集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果資料集巨大並且CPU效能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日誌檔案的頻率來提高資料集的耐久度.

AOF 優點

  • 使用AOF 會讓你的Redis更加耐久: 你可以使用不同的fsync策略:無fsync,每秒fsync,每次寫的時候fsync.使用預設的每秒fsync策略,Redis的效能依然很好(fsync是由後臺執行緒進行處理的,主執行緒會盡力處理客戶端請求),一旦出現故障,你最多丟失1秒的資料.

  • AOF檔案是一個只進行追加的日誌檔案,所以不需要寫入seek,即使由於某些原因(磁碟空間已滿,寫的過程中當機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題.

  • Redis 可以在 AOF 檔案體積變得過大時,自動地在後臺對 AOF 進行重寫: 重寫後的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的,因為 Redis 在建立新 AOF 檔案的過程中,會繼續將命令追加到現有的 AOF 檔案裡面,即使重寫過程中發生停機,現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢,Redis 就會從舊 AOF 檔案切換到新 AOF 檔案,並開始對新 AOF 檔案進行追加操作。

  • AOF 檔案有序地儲存了對資料庫執行的所有寫入操作, 這些寫入操作以 Redis 協議的格式儲存, 因此 AOF 檔案的內容非常容易被人讀懂, 對檔案進行分析(parse)也很輕鬆。 匯出(export) AOF 檔案也非常簡單: 舉個例子, 如果你不小心執行了 FLUSHALL 命令, 但只要 AOF 檔案未被重寫, 那麼只要停止伺服器, 移除 AOF 檔案末尾的 FLUSHALL 命令, 並重啟 Redis , 就可以將資料集恢復到 FLUSHALL 執行之前的狀態。

AOF 缺點

  • 對於相同的資料集來說,AOF 檔案的體積通常要大於 RDB 檔案的體積。

  • 根據所使用的 fsync 策略,AOF 的速度可能會慢於 RDB 。 在一般情況下, 每秒 fsync 的效能依然非常高, 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快, 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時,RDB 可以提供更有保證的最大延遲時間(latency)。

廢話不多說直接看下面的示例吧,通過 docker 執行一個 redis 例項,並設定一些資料,然後匯出 RDB 檔案,再執行一個 redis 例項通過 RDB 檔案還原資料

備份

通過 docker run -d --name redis-test-1 redis:alpine 命令來建立一個 redis 例項,接著 SET 一個 key 儲存到我們的 redis,使用命令 SET hello world 寫入測試資料,你也可以寫入別的自己想寫的資料,接著可以使用 keys * 來驗證資料是否寫入成功

測試資料寫入成功後使用 SAVE 命令來建立 RDB 檔案,命令執行成功後我們可以在 /data 目錄下看到會有一個 dump.rdb 檔案,這就是我們想要的 RDB 檔案,通過 docker cp 命令可以把這個檔案拷貝到 host 目錄下

還原

通過上面 RDB 檔案我們可以在 redis 啟動的時候還原 RDB 檔案中的資料,只需要在 Redis 啟動前把 RDB 檔案放在 redis 的 data 目錄下就可以了。

執行 docker run --rm --name redis-test-2 -v ${pwd}/data:/data redis:alpine

這個命令我是在 powershell 上執行的,如果執行在 Linux 上執行需要把 ${pwd} 換成 $(pwd) 來表示當前目錄

可以看到上面的日誌裡有 Loading RDB ... 就是在載入 RDB 檔案中的資料

我們再來驗證一下 RDB 檔案裡的資料是否真的載入到了新的 redis 例項中,先來驗證一下 data 目錄是否正常掛載了,執行 docker exec -it redis-test-2 sh 來進入到 redis 例項容器中,ls 檢視 data 目錄中的檔案看是否有我們期望的 RDB 檔案,接著進入 redis-cli 來驗證資料是否存在

使用 keys * 來列出來所有的 key 資訊,可以看到有我們在上一個 redis 裡寫入的測試資料了,再來使用 GET hello 來驗證資料是否正確,至此我們的資料就還原到新的 redis 例項中了~~

More

當 Redis 需要儲存 dump.rdb 檔案時, 伺服器執行以下操作:

  • Redis 呼叫forks. 同時擁有父程式和子程式。
  • 子程式將資料集寫入到一個臨時 RDB 檔案中。
  • 當子程式完成對新 RDB 檔案的寫入時,Redis 用新 RDB 檔案替換原來的 RDB 檔案,並刪除舊的 RDB 檔案。

這種工作方式使得 Redis 可以從寫時複製(copy-on-write)機制中獲益。

如果 redis 被訪問的比較頻繁,可以使用 BGSAVE 代替 SAVE 來非同步建立 RDB 備份

如果 redis 不是使用 docker 來使用的,/data 目錄可以在 redis-cli 中使用 CONFIG GET dir 來獲取儲存 rdb 檔案的目錄,預設儲存的 RDB 檔名稱是 dump.rdb,如果有修改過,可以通過 CONFIG GET dbfilename 來獲取當前使用的檔名

References

相關文章