Redis 通過 RDB 方式進行資料備份與還原
阿新 • • 發佈：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
-