Redis 通過 RDB 方式進行數據備份與還原

2021 年 3 月 14 日
筆記
Redis, Soluntions

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 實例中了~~

當 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

Tags: Redis Soluntions