Intro

有的時候我們需要對 Redis 的數據進行遷移，今天介紹一下通過 RDB（快照）文件進行 Redis 數據的備份和還原

Redis 持久化

Redis 的數據持久化有兩種機制，一種是 RDB(Redis Database)，一種是 AOF(Append Only File)

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

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

RDB的優(yōu)點

• 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性能不是很好的情況下,這種情況會持續(xù)1秒,AOF也需要fork,但是你可以調節(jié)重寫日志文件的頻率來提高數據集的耐久度.

AOF 優(yōu)點

• 使用AOF 會讓你的Redis更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用默認的每秒fsync策略,Redis的性能依然很好(fsync是由后臺線程進行處理的,主線程會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的數據.
• AOF文件是一個只進行追加的日志文件,所以不需要寫入seek,即使由于某些原因(磁盤空間已滿，寫的過程中宕機等等)未執(zhí)行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題.
• Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。
• AOF 文件有序地保存了對數據庫執(zhí)行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執(zhí)行之前的狀態(tài)。

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 命令來創(chuàng)建一個 redis 實例，接著 SET 一個 key 保存到我們的 redis，使用命令 SET hello world 寫入測試數據，你也可以寫入別的自己想寫的數據，接著可以使用 keys * 來驗證數據是否寫入成功

測試數據寫入成功后使用 SAVE 命令來創(chuàng)建 RDB 文件，命令執(zhí)行成功后我們可以在 /data 目錄下看到會有一個 dump.rdb 文件，這就是我們想要的 RDB 文件，通過 docker cp 命令可以把這個文件拷貝到 host 目錄下

還原

通過上面 RDB 文件我們可以在 redis 啟動的時候還原 RDB 文件中的數據，只需要在 Redis 啟動前把 RDB 文件放在 redis 的 data 目錄下就可以了。

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

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

可以看到上面的日志里有 Loading RDB ... 就是在加載 RDB 文件中的數據

我們再來驗證一下 RDB 文件里的數據是否真的加載到了新的 redis 實例中，先來驗證一下 data 目錄是否正常掛載了，執(zhí)行 docker exec -it redis-test-2 sh 來進入到 redis 實例容器中，ls 查看 data 目錄中的文件看是否有我們期望的 RDB 文件，接著進入 redis-cli 來驗證數據是否存在

使用 keys * 來列出來所有的 key 信息，可以看到有我們在上一個 redis 里寫入的測試數據了，再來使用 GET hello 來驗證數據是否正確，至此我們的數據就還原到新的 redis 實例中了~~

More

當 Redis 需要保存 dump.rdb 文件時， 服務器執(zhí)行以下操作:

• Redis 調用forks. 同時擁有父進程和子進程。
• 子進程將數據集寫入到一個臨時 RDB 文件中。
• 當子進程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

這種工作方式使得 Redis 可以從寫時復制（copy-on-write）機制中獲益。

如果 redis 被訪問的比較頻繁，可以使用 BGSAVE 代替 SAVE 來異步創(chuàng)建 RDB 備份

如果 redis 不是使用 docker 來使用的，/data 目錄可以在 redis-cli 中使用 CONFIG GET dir 來獲取保存 rdb 文件的目錄，默認保存的 RDB 文件名稱是 dump.rdb，如果有修改過，可以通過 CONFIG GET dbfilename 來獲取當前使用的文件名

References

https://redis.io/topics/persistence

http://redis.cn/topics/persistence.html

到此這篇關于Redis 通過 RDB 方式進行數據備份與還原的文章就介紹到這了,更多相關Redis數據備份與還原內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！