對長期奮戰在一線的后端開發人員來說，都知道redis有兩種持久化方式RDB和AOF，雖說大家都知道這兩種方式大概運作方式，但想必有實操的人不會太多，
這里是自己實操兩種持久化方式的一點點記錄，
先看以下摘錄自redis官網原文解釋(原文是English，這里用google翻譯，)
<style></style>Redis持久性
Redis提供了不同的持久性選項范圍：
RDB持久性按指定的時間間隔執行資料集的時間點快照，
AOF持久性會記錄服務器接收的每個寫入操作，這些操作將在服務器啟動時再次播放，以重建原始資料集， 使用與Redis協議本身相同的格式記錄命令，并且僅采用追加方式， 當日志太大時，Redis可以在后臺重寫日志，
如果希望，只要您的資料在服務器運行時就一直存在，則可以完全禁用持久性，
可以在同一實體中同時合并AOF和RDB， 請注意，在這種情況下，當Redis重新啟動時，AOF檔案將用于重建原始資料集，因為它可以保證是最完整的，
要理解的最重要的事情是RDB與AOF持久性之間的不同權衡， 讓我們從RDB開始：
RDB的優勢
RDB是Redis資料的非常緊湊的單檔案時間點表示， RDB檔案非常適合備份， 例如，您可能希望在最近的24小時內每小時存檔一次RDB檔案，并在30天之內每天保存一次RDB快照， 這使您可以在發生災難時輕松還原資料集的不同版本，
RDB對于災難恢復非常有用，它是一個緊湊的檔案，可以傳輸到遠程資料中心或Amazon S3（可能已加密）上，
RDB最大限度地提高了Redis的性能，因為Redis父行程為了持久化所需要做的唯一作業就是分叉一個孩子，其余的都將做， 父實體將永遠不會執行磁盤I / O或類似操作，
與AOF相比，RDB允許大型資料集更快地重啟，
RDB的缺點
如果您需要在Redis停止作業（例如斷電后）的情況下最大程度地減少資料丟失的機會，則RDB不好， 您可以在生成RDB的位置配置不同的保存點 （例如，在至少五分鐘之后，對資料集進行100次寫入，但是您可以有多個保存點），
但是，通常會每隔五分鐘或更長時間創建一次RDB快照，因此，如果Redis出于任何原因在沒有正確 關閉的情況下停止作業，則應該準備丟失最新的資料分鐘，
RDB需要經常使用fork（）才能使用子行程將其持久化在磁盤上， 如果資料集很大，Fork（）可能很耗時，并且如果資料集很大且CPU性能不佳，則可能導致Redis停止為客戶端服務幾毫秒甚至一秒鐘， AOF還需要fork（），但您可以調整要重寫日志的頻率，而無需在持久性上進行權衡，
AOF的優勢
使用AOF Redis更加持久：您可以有不同的fsync策略：完全沒有fsync，每秒fsync，每個查詢fsync， 使用默認策略fsync時，每秒的寫入性能仍然很好（fsync是使用后臺執行緒執行的，并且在沒有進行fsync的情況下，主執行緒將盡力執行寫入操作，）但是您只能損失一秒鐘的寫入時間，
AOF日志僅是一個追加日志，因此，如果斷電，也不會出現尋道或損壞問題， 即使由于某種原因（磁盤已滿或其他原因）以半寫命令結束日志，redis-check-aof工具也可以輕松修復它，
Redis太大時，Redis可以在后臺自動重寫AOF， 重寫是完全安全的，因為Redis繼續追加到舊檔案時，會生成一個全新的檔案，其中包含創建當前資料集所需的最少操作集，一旦準備好第二個檔案，Redis會切換這兩個檔案并開始追加到新的那一個，
AOF以易于理解和決議的格式包含所有操作的日志， 您甚至可以輕松匯出AOF檔案， 例如，即使您使用FLUSHALL命令重繪了所有錯誤檔案 ，如果在此期間未執行任何日志重寫操作，您仍然可以保存資料集，只是停止服務器，洗掉最新命令并重新啟動Redis，
AOF的缺點
對于相同的資料集，AOF檔案通常大于等效的RDB檔案，
根據確切的fsync策略，AOF可能比RDB慢， 通常，在將fsync設定為每秒的情況下，性能仍然很高，并且在禁用fsync的情況下，即使在高負載下，它也應與RDB一樣快， 即使在巨大的寫負載情況下，RDB仍然能夠提供有關最大延遲的更多保證，
過去，我們在特定命令中遇到過罕見的錯誤（例如，其中有一個涉及阻塞命令，例如BRPOPLPUSH ）,導致生成的AOF在多載時無法重現完全相同的資料集，
這些錯誤很少見，我們在測驗套件中進行了測驗，自動創建了隨機的復雜資料集，然后重新加載它們以檢查一切是否正常， 但是，RDB持久性幾乎是不可能的， 更明確地說：Redis AOF通過增量更新現有狀態來作業，就像MySQL或MongoDB一樣，而RDB快照一次又一次地創建所有內容，從概念上講更健壯，
但是 1）應該注意的是，每次Redis重寫AOF時，都會從資料集中包含的實際資料開始從頭開始重新創建AOF，與始終附加AOF檔案相比（或重寫后的讀數），對錯誤的抵抗力更強舊的AOF，而不是讀取記憶體中的資料），
2）我們從未收到過有關真實環境中檢測到的AOF損壞的用戶報告，
以上所述就是RDB會根據組態檔的配置資訊定時全量備份時間點的資料; AOF則是根據同步策略追加寫入備份檔案，
一. RDB快照持久化
#首先我們看下組態檔的資訊 [root@guangzhou data]# systemctl status redis ● redis.service - Redis 6379 Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled) Active: active (running) since 六 2020-01-18 16:26:42 CST; 18h ago Process: 344 ExecStop=/usr/local/redis/bin/redis-cli -h 127.0.0.1 -p 6379 -a jcon shutdown (code=exited, status=0/SUCCESS) Process: 348 ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf (code=exited, status=0/SUCCESS) Main PID: 349 (redis-server) CGroup: /system.slice/redis.service └─349 /usr/local/redis/bin/redis-server *:6379 1月 18 16:26:42 guangzhou systemd[1]: Starting Redis 6379... 1月 18 16:26:42 guangzhou systemd[1]: Started Redis 6379. #更改/usr/local/redis/etc/redis.conf中配置 #10秒鐘內2次更改寫入RDB二進制檔案 save 10 2 # RDB持久化檔案名 dbfilename dump.rdb # 資料持久化檔案存盤目錄 dir /usr/local/redis/data # bgsave發生錯誤時是否停止寫入，通常為yes stop-writes-on-bgsave-error yes # rdb檔案是否使用壓縮格式 rdbcompression yes # 是否對rdb檔案進行校驗和檢驗，通常為yes rdbchecksum yes
#重啟redis
[root@guangzhou data]# systemctl restart redis
#為便于觀察先把redis資料清空，生產環境請慎重.
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty list or set)
#操作前清空RDB檔案
[root@guangzhou data]# pwd && ll
/usr/local/redis/data
總用量 0
#set兩條資料
127.0.0.1:6379> set a 100
OK
127.0.0.1:6379> set b 200
OK
#重命名RDB檔案
[root@guangzhou data]# pwd && mv dump.rdb dump.rdb2 && ll
/usr/local/redis/data
總用量 4
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb2
#再次set兩條資料
127.0.0.1:6379> set c 300
OK
127.0.0.1:6379> set d 400
OK
#查看RDB檔案,可以發現新的dump.rdb檔案大于dump.rdb2,因為RDB是全量備份,dump.rdb比dump.rdb2多了key=c和key=d
[root@guangzhou data]# ll
總用量 8
-rw-r--r-- 1 root root 120 1月 19 16:59 dump.rdb
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb2
#現在我們將檔案重命名
[root@guangzhou data]# pwd && mv dump.rdb dump.rdb3 && ll
/usr/local/redis/data
總用量 8
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb2
-rw-r--r-- 1 root root 120 1月 19 16:59 dump.rdb3
#清空資料
127.0.0.1:6379> flushdb
OK
#停止redis服務
[root@guangzhou data]# systemctl stop redis
#洗掉最新生成的rdb檔案，重命名僅含有key=a和key=b的dump.rdb2為dump.rdb
[root@guangzhou data]# pwd && rm -rf dump.rdb && mv dump.rdb2 dump.rdb && ll
/usr/local/redis/data
總用量 8
-rw-r--r-- 1 root root 108 1月 19 15:42 dump.rdb
-rw-r--r-- 1 root root 120 1月 19 16:59 dump.rdb3
#重啟redis服務(正常的話重啟后redis僅含有key=a和key=b兩個資料)
[root@guangzhou data]# systemctl restart redis
[root@guangzhou data]#
#重連redis列出所有key，果然如我們所料，只有a和b
127.0.0.1:6379> keys *
1) "a"
2) "b"
127.0.0.1:6379>
#如果對資料完整性要求較高，可以采用RDB快照，啟用定時任務備份指定時間點的資料檔案，這樣一旦發生生產事故，可以很方便資料回滾；另外單個RDB二進制檔案，方便檔案分散存盤，資料遷移挪到其他服務器，
二. AOF方式持久化
#更改/usr/local/redis/etc/redis.conf中配置 #注釋上面RDB快照持久方式的配置，并更改aof配置 #開啟AOF日志追加 appendonly yes #日志追加的檔案名 appendfilename "appendonly.aof" #寫入頻率，為了便于觀察，這里使用更新立即更新日志檔案 appendfsync always #redis服務重啟 [root@guangzhou etc]# systemctl restart redis [root@guangzhou etc]# systemctl status redis ● redis.service - Redis 6379 Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled) Active: active (running) since 一 2020-01-20 15:40:17 CST; 9s ago Process: 5493 ExecStop=/usr/local/redis/bin/redis-cli -h 127.0.0.1 -p 6379 -a jcon shutdown (code=exited, status=0/SUCCESS) Process: 5497 ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf (code=exited, status=0/SUCCESS) Main PID: 5498 (redis-server) CGroup: /system.slice/redis.service └─5498 /usr/local/redis/bin/redis-server 127.0.0.1:6379 1月 20 15:40:17 guangzhou systemd[1]: Starting Redis 6379... 1月 20 15:40:17 guangzhou systemd[1]: Started Redis 6379. #轉到/usr/local/redis/data目錄，自動生成空檔案,appendonly.aof [root@guangzhou data]# ll 總用量 0 -rw-r--r-- 1 root root 0 1月 20 15:42 appendonly.aof #命令列下錄入資料 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set a 1 OK 127.0.0.1:6379> set b 2 OK 127.0.0.1:6379> set c 3 OK 127.0.0.1:6379> #列印日志檔案 [root@guangzhou data]# ll 總用量 8 -rw-r--r-- 1 root root 104 1月 20 15:43 appendonly.aof [root@guangzhou data]# cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 set $1 a $1 1 *3 $3 set $1 b $1 2 *3 $3 set $1 c $1 3 #檔案輸出可見每次操作詳情, #現在我們模擬例外情況,先重命名appendonly.aof檔案為appendonly.aof2，停止redis服務 [root@guangzhou data]# pwd && mv appendonly.aof appendonly.aof2 && systemctl stop redis && rm -rf ./appendonly.aof && ll /usr/local/redis/data 總用量 8 -rw-r--r-- 1 root root 104 1月 20 15:43 appendonly.aof2 #在更改appendonly.aof2檔案中c的數值為999, appendonly.aof2重命名為appendonly.aof，重啟redis服務 127.0.0.1:6379> keys * 1) "c" 2) "b" 3) "a" 127.0.0.1:6379> get c "993" #可見key=c的資料已改變 $3 set $1 c $3(更改時這里需要從1變為3) 993
生產環境我們可以RDB快照和AOF兩種方式結合起來使用，RDB快照檔案可以定時備份
注意:
1) auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
意思啟用AOF時，redis會在AOF比上次完成重寫AOF時的容量大至少100%時開啟一個BGREWRITEAOF，并且AOF容量至少在64MB時發生;
2) 只配置 AOF ，重啟時加載 AOF 檔案恢復資料
同時配置了 RDB 和 AOF ，啟動是只加載 AOF 檔案恢復資料
只配置 RDB，啟動是將加載 dump 檔案恢復資料
3) 命令列下save命令保存當前時間點全量資料快照, bgsave異步保存快照
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/22927.html
標籤：NoSQL