Redis-11-持久化詳解

共同進步吧發表於2020-11-19
Redis持久化

Redis-11-持久化

conf檔案中相關配置

# 如果900s內，如果至少有一個1 key進行了修改，我們及進行持久化操作
save 900 1
# 如果300s內，如果至少10 key進行了修改，我們及進行持久化操作
save 300 10
# 如果60s內，如果至少10000 key進行了修改，我們及進行持久化操作
save 60 10000
# 我們之後學習持久化，會自己定義這個測試！
stop-writes-on-bgsave-error yes # 持久化如果出錯，是否還需要繼續工作！
dir ./ # rdb 檔案儲存的目錄！

RDB（Redis DataBase）

在主從複製中，rdb就是備用了！從機上面！

1.conf中配置

rdbcompression yes # 是否壓縮 rdb 檔案，需要消耗一些cpu資源！
rdbchecksum yes # 儲存rdb檔案的時候，進行錯誤的檢查校驗！

2.原理

rdb儲存的是dump.rdb 都是在我們的配置檔案中快照中進行配置的！

在這裡插入圖片描述

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

有時候在生產環境我們會將這個檔案進行備份
在這裡插入圖片描述

3.觸發機制

1、save的規則滿足的情況下，會自動觸發rdb規則

2、執行 flushall 命令，也會觸發我們的rdb規則！

3、退出redis，也會產生 rdb 檔案！

備份就自動生成一個 dump.rdb

在這裡插入圖片描述

4.如果恢復rdb檔案！

1、只需要將rdb檔案放在我們redis啟動目錄就可以，redis啟動的時候會自動檢查dump.rdb 恢復其中 的資料！ 2、檢視需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在這個目錄下存在 dump.rdb 檔案，啟動就會自動恢復其中的資料

5.優點：

​ 1、適合大規模的資料恢復！ dump.rdb

​ 2、對資料的完整性要不高！

6.缺點：

​ 1、需要一定的時間間隔進行操作！如果redis意外當機了，這個最後一次修改資料就沒有的了！

​ 2、fork程式的時候，會佔用一定的內容空間

AOF（Append Only File）

將我們的所有命令都記錄下來，history，恢復的時候就把這個檔案全部在執行一遍！

預設是不開啟的，我們需要手動進行配置！我們只需要將 appendonly 改為yes就開啟了 aof！ 重啟，redis 就可以生效了

如果這個 aof 檔案有錯誤，這時候 redis 是啟動不起來的嗎，我們需要修復這個aof檔案

redis 給我們提供了一個工具 **redis-check-aof **

redis-check-aof --fix appendonly.aof

1.相關配置

appendonly no#預設是不開啟aof模式的，預設是使用rdb方式持久化的，在大部分所有的情況下，rdb完全夠用！

appendfilename "appendonly.aof" # 持久化的檔案的名字

# appendfsync always # 每次修改都會 sync。消耗效能
appendfsync everysec # 每秒執行一次 sync，可能會丟失這1s的資料！


# appendfsync no # 不執行 sync，這個時候作業系統自己同步資料，速度最快！
#rewrite 重寫

2.原理

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

Aof儲存的是 appendonly.aof 檔案 記錄所有的寫操作

在這裡插入圖片描述

3.重寫規則說明

aof 預設就是檔案的無限追加，檔案會越來越大

在這裡插入圖片描述

如果 aof 檔案大於 64m，太大了！ fork一個新的程式來將我們的檔案進行重寫！

4.優點：

​ 1、每一次修改都同步，檔案的完整會更加好！

​ 2、每秒同步一次，可能會丟失一秒的資料

​ 3、從不同步，效率最高的！

5.缺點：

​ 1、相對於資料檔案來說，aof遠遠大於 rdb，修復的速度也比 rdb慢！

​ 2、Aof 執行效率也要比 rdb 慢，所以我們redis預設的配置就是rdb持久化

擴充套件：

1、RDB 持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存

2、AOF 持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始 的資料，AOF命令以Redis 協議追加儲存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行後臺重 寫，使得AOF檔案的體積不至於過大。

3、只做快取，如果你只希望你的資料在伺服器執行的時候存在，你也可以不使用任何持久化

4、同時開啟兩種持久化方式

  • 在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF 檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
  • RDB 的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案，那要不要只使用AOF呢？作者 建議不要，因為RDB更適合用於備份資料庫（AOF在不斷變化不好備份），快速重啟，而且不會有 AOF可能潛在的Bug，留著作為一個萬一的手段。

5、效能建議

  • 因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠 了，只保留 save 900 1 這條規則。
  • 如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自 己的AOF檔案就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最後將 rewrite 過程中產 生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite 的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上，預設超過原大小100%大小重 寫可以改到適當的數值。
  • 如果不Enable AOF ，僅靠 Master-Slave Repllcation 實現高可用性也可以，能省掉一大筆IO，也 減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時倒掉，會丟失十幾分鐘的資料， 啟動指令碼也要比較兩個 Master/Slave 中的 RDB檔案，載入較新的那個，微博就是這種架構。

相關文章