Redis

@Author:hanguixian
@Email:[email protected]

五 redis的持久化

• 官網介紹：https://redis.io/topics/persistence

  • RDB的優勢（google翻譯）

    • RDB是Redis資料的一個非常緊湊的單檔案時間點表示。RDB檔案非常適合備份。例如，您可能希望在最近24小時內每小時歸檔您的RDB檔案，並且每天儲存RDB快照30天。這使您可以在發生災難時輕鬆恢復不同版本的資料集。
    • RDB非常適合災難恢復，可以將單個壓縮檔案傳輸到遠端資料中心，也可以傳輸到Amazon S3（可能是加密的）。
    • RDB最大限度地提高了Redis的效能，因為Redis父程序為了堅持而需要做的唯一工作是分配一個將完成所有其餘工作的孩子。父例項永遠不會執行磁碟I / O或類似操作。
    • 與AOF相比，RDB允許使用大資料集更快地重啟。

  • RDB的缺點（google翻譯）

    • 如果您需要在Redis停止工作時（例如斷電後）將資料丟失的可能性降至最低，則RDB並不好。您可以配置生成RDB的不同儲存點（例如，在對資料集進行至少五分鐘和100次寫入之後，您可以擁有多個儲存點）。但是，您通常每五分鐘或更長時間建立一個RDB快照，因此如果Redis因任何原因停止工作而沒有正確關閉，您應該準備丟失最新的資料分鐘。
    • RDB經常需要fork（）才能使用子程序持久儲存在磁碟上。如果資料集很大，Fork（）可能會很耗時，如果資料集非常大且CPU效能不佳，可能會導致Redis停止服務客戶端幾毫秒甚至一秒鐘。AOF也需要fork（），但你可以調整你想要重寫日誌的頻率，而不需要對耐久性進行任何權衡。

1 RDB（Redis DataBase）

1.1 是什麼

• 在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡
• Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能。如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。

1.2 Fork

• fork的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等）數值都和原程序一致，但是是一個全新的程序，並作為原程序的子程序

1.3 rdb的儲存

• rdb 儲存的是dump.rdb檔案
• 配置位置：redis.conf的SNAPSHOTTING中

1.4 如何觸發RDB快照

• 冷拷貝後重新使用：可以cp dump.rdb dump_new.rdb
• 命令save或者是bgsave
  • Save：save時只管儲存，其它不管，全部阻塞
  • BGSAVE：Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave命令獲取最後一次成功執行快照的時間
• 執行flushall命令，也會產生dump.rdb檔案，但裡面是空的，無意義

1.5 如何恢復

• 將備份檔案 (dump.rdb) 移動到 redis 安裝目錄並啟動服務即可
• CONFIG GET dir獲取目錄

1.6 優勢

• 適合大規模的資料恢復
• 對資料完整性和一致性要求不高

1.7 劣勢

• 在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改
• fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮

1.8 如何停止

• 動態所有停止RDB儲存規則的方法：redis-cli config set save “”

1.9 示例

[[email protected] bin]# ll
total 32636
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# redis-server /hanguixian/myredis/redis.conf 
7621:C 03 Dec 2018 17:56:23.248 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7621:C 03 Dec 2018 17:56:23.248 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7621, just started
7621:C 03 Dec 2018 17:56:23.248 # Configuration loaded
[[email protected] bin]# redis-cli 
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5 
OK
127.0.0.1:6379> set k6 v6
OK
127.0.0.1:6379> set k7 v7
OK
127.0.0.1:6379> set k8 v8
OK
127.0.0.1:6379> set k9 v9
OK
127.0.0.1:6379> set k10 v10 
OK
127.0.0.1:6379> set k11 v11
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379> SHUTDOWN
not connected> exit
[[email protected] bin]# redis-server /hanguixian/myredis/redis.conf 
7627:C 03 Dec 2018 17:58:22.816 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7627:C 03 Dec 2018 17:58:22.816 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7627, just started
7627:C 03 Dec 2018 17:58:22.816 # Configuration loaded
[[email protected] bin]# redis-cli 
127.0.0.1:6379> KEYS *
 1) "k7"
 2) "k4"
 3) "k10"
 4) "k8"
 5) "k2"
 6) "k6"
 7) "k5"
 8) "k11"
 9) "k3"
10) "k9"
11) "k1"
127.0.0.1:6379> SHUTDOWN
not connected> exit
[[email protected] bin]# ll
total 32640
-rw-r--r-- 1 root root     178 Dec  3 17:58 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# cp dump.rdb dump_new.rdb 
[[email protected] bin]# rm dump.rdb 
rm: remove regular file ‘dump.rdb’? y
[[email protected] bin]# redis-server /hanguixian/myredis/redis.conf 
7636:C 03 Dec 2018 17:59:15.810 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7636:C 03 Dec 2018 17:59:15.810 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7636, just started
7636:C 03 Dec 2018 17:59:15.810 # Configuration loaded
[[email protected] bin]# redis-cli 
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> exit
[[email protected] bin]# cp dump_new.rdb dump 
dump_new.rdb  dump.rdb      
[[email protected] bin]# ll 
total 32644
-rw-r--r-- 1 root root     178 Dec  3 17:58 dump_new.rdb
-rw-r--r-- 1 root root      92 Dec  3 17:59 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# rm -f dump.rdb 
[[email protected] bin]# cp dump_new.rdb dump.rdb 
[[email protected] bin]# redis-server /hanguixian/myredis/redis.conf 
7650:C 03 Dec 2018 18:00:29.051 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7650:C 03 Dec 2018 18:00:29.051 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7650, just started
7650:C 03 Dec 2018 18:00:29.051 # Configuration loaded
[[email protected] bin]# redis-cli 
127.0.0.1:6379> KEYS *
 1) "k2"
 2) "k6"
 3) "k4"
 4) "k5"
 5) "k10"
 6) "k8"
 7) "k11"
 8) "k7"
 9) "k1"
10) "k9"
11) "k3"
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/bin"

2 AOF（Append Only File）

• 官網介紹：https://redis.io/topics/persistence

• 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而不是讀取記憶體中的資料）相比，對bug的抵抗力更強。
    • 2）我們從未向用戶提供過關於在現實世界中檢測到的AOF損壞的單一報告。

2.1 是什麼

• 以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重新構建資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作

2.2 AOF的儲存

• Aof儲存的是appendonly.aof檔案
• 配置位置：redis.conf的APPEND ONLY MODE模組

2.3 AOF啟動/修復/恢復

2.3.1 正常恢復

• 啟動：設定Yes
  • 修改預設的appendonly no，改為yes
• 將有資料的aof檔案複製一份儲存到對應目錄(config get dir)
• 恢復：重啟redis然後重新載入

#前置：設定redis.conf的appendonly yes
#操作
[[email protected] bin]# ps -ef|grep redis
root      8869  8563  0 15:34 pts/2    00:00:00 grep --color=auto redis
[[email protected] bin]# rm -f dump.rdb 
[[email protected] bin]# rm -f dump_new.rdb 
[[email protected] bin]# ll
total 32636
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# redis-server /hanguixian/myredis/redis_aof.conf 
8874:C 04 Dec 2018 15:35:28.588 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8874:C 04 Dec 2018 15:35:28.588 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8874, just started
8874:C 04 Dec 2018 15:35:28.588 # Configuration loaded
[[email protected] bin]# ll
total 32636
-rw-r--r-- 1 root root       0 Dec  4 15:35 appendonly.aof
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# vim appendonly.aof 
[[email protected] bin]# redis-cli 
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> set k2 22
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> SHUTDOWN
not connected> exit
[[email protected] bin]# cp appendonly.aof appendonly_bk.aof 
[[email protected] bin]# ll
total 32648
-rw-r--r-- 1 root root     139 Dec  4 15:36 appendonly.aof
-rw-r--r-- 1 root root     139 Dec  4 15:39 appendonly_bk.aof
-rw-r--r-- 1 root root     124 Dec  4 15:36 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# rm -f appendonly.aof 
[[email protected] bin]# rm -f dump.rdb 
[[email protected] bin]# ps -ef|grep redis
root      8895  8563  0 15:40 pts/2    00:00:00 grep --color=auto redis
[[email protected] bin]# redis-server /hanguixian/myredis/redis_aof.conf 
8896:C 04 Dec 2018 15:40:40.025 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8896:C 04 Dec 2018 15:40:40.025 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8896, just started
8896:C 04 Dec 2018 15:40:40.025 # Configuration loaded
[[email protected] bin]# redis-cli 
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> EXIT
[[email protected] bin]# cp appendonly_bk.aof appendonly.aof 
cp: overwrite ‘appendonly.aof’? y
[[email protected] bin]# redis-server /hanguixian/myredis/redis_aof.conf 
8903:C 04 Dec 2018 15:41:50.717 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8903:C 04 Dec 2018 15:41:50.717 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8903, just started
8903:C 04 Dec 2018 15:41:50.717 # Configuration loaded
[[email protected] bin]# redis-cli 
127.0.0.1:6379> keys *
1) "k1"
2) "k3"
3) "k2"
4) "k4"

2.3.2 異常恢復

• 啟動：設定Yes
  • 修改預設的appendonly no，改為yes
• 備份被寫壞的AOF檔案
• 修復：redis-check-aof --fix進行修復
• 恢復：重啟redis然後重新載入

#當發生異常，appendonly.aof 損壞，模擬：人為的在後面新增亂七八糟的東西
*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v2
*3
$3
set
$2
k2
$2
22
*3
$3
set
$2
k3
$2
v3
*3
$3
set
$2
k4
$2
v4
sdjkfkhsfsd oipj er3r4r asod /psdcfg s
odwe s ogy70d rhesdb dfg es; hp g7es lhse rghe rkh irjhs eriokg

• appendonly.aof 損壞，redis啟動失敗，同時可以看出dump.rdb，appendonly.aof同時存在的情況下，appendonly.aof優先

[[email protected] bin]# ps -ef|grep redis
root      8916  8563  0 15:54 pts/2    00:00:00 grep --color=auto redis
[[email protected] bin]# ll
total 32648
-rw-r--r-- 1 root root     139 Dec  4 15:41 appendonly.aof
-rw-r--r-- 1 root root     139 Dec  4 15:39 appendonly_bk.aof
-rw-r--r-- 1 root root     124 Dec  4 15:54 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# vim appendonly.aof
[[email protected] bin]# redis-server /hanguixian/myredis/redis_aof.conf 
8919:C 04 Dec 2018 15:55:52.439 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8919:C 04 Dec 2018 15:55:52.439 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8919, just started
8919:C 04 Dec 2018 15:55:52.439 # Configuration loaded
[[email protected] bin]# redis-cli 
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> exit

• appendonly.aof修復

[[email protected] bin]# ps -ef|grep redis
root      8916  8563  0 15:54 pts/2    00:00:00 grep --color=auto redis
[[email protected] bin]# ll
total 32648
-rw-r--r-- 1 root root     139 Dec  4 15:41 appendonly.aof
-rw-r--r-- 1 root root     139 Dec  4 15:39 appendonly_bk.aof
-rw-r--r-- 1 root root     124 Dec  4 15:54 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[[email protected] bin]# redis-server /hanguixian/myredis/redis_aof.conf 
8919:C 04 Dec 2018 15:55:52.439 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8919:C 04 Dec 2018 15:55:52.439 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8919, just started
8919:C 04 Dec 2018 15:55:52.439 # Configuration loaded
[[email protected] bin]# redis-cli 
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> exit
[[email protected] bin]# vim appendonly.aof 
[[email protected] bin]# redis-check-aof --fix appendonly.aof 
0x              8b: Expected prefix '*', got: 's'
AOF analyzed: size=244, ok_up_to=139, diff=105
This will shrink the AOF from 244 bytes, with 105 bytes, to 139 bytes
Continue? [y/N]: y
Successfully truncated AOF
[[email protected] bin]# vim appendonly.aof 

• 修復後的appendonly.aof

*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v2
*3
$3
set
$2
k2
$2
22
*3
$3
set
$2
k3
$2
v3
*3
$3
set
$2
k4
$2
v4 

2.4 rewite 重寫

2.4.1 是什麼

• AOF採用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制,當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集.可以使用命令bgrewriteaof

2.4.2 重寫原理

• AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫(也是先寫臨時檔案最後再rename)，遍歷新程序的記憶體中資料，每條記錄有一條的Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似

2.4.3 觸發機制

• Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發

2.5 優勢和劣勢

• 優勢
  • 每修改同步：appendfsync always 同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差但資料完整性比較好
  • 每秒同步：appendfsync everysec 非同步操作，每秒記錄 如果一秒內宕機，有資料丟失
  • 不同步：appendfsync no 從不同步
• 劣勢
  • 相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢於rdb
  • aof執行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同

3 小總結

• RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存
• AOF持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加儲存每次寫的操作到檔案末尾.Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大
• 只做快取：如果你只希望你的資料在伺服器執行的時候存在,你也可以不使用任何持久化方式.
• 同時開啟兩種持久化方式
  • 在這種情況下,當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整.
  • RDB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案。那要不要只使用AOF呢？作者建議不要，因為RDB更適合用於備份資料庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
• 效能建議
  • 因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只留save 900 1這條規則。
  • 如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自己AOF檔案就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上。預設超過原大小100%大小時重寫可以改到適當的數值。
  • 如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個Master/Slave中的RDB檔案，載入較新的那個。新浪微博就選用了這種架構