持久化介紹
官網地址:
https://redis.io/docs/manual/persistence
- RDB(Redis DataBase)
- AOF(Append Only File)
- RDB + AOF
RDB模式(Redis DataBase)
RDB 持久性以指定的時間間隔執行數據集的時間點快照。
實現類似照片記錄效果的方式,就是把某一時刻的數據和狀態以文件的形式寫到磁盤上,也就是
快照。這樣一來即使故障宕機,快照文件也不會丟失,數據的可靠性也就得到了保證。
這個快照文件就稱為RDB文件(dump.rdb),其中,RDB就是Redis DataBase的縮寫。
在指定的時間間隔內將內存中的數據集快照寫入磁盤也就是行話講的Snapshot內存快照,它恢復時再將硬盤快照文件直接讀回到內存里。
redis.conf配置文件
-
6.0.16版本以下
-
6.2以及7.0版本
開啟備份
1.修改配置文件
5秒或2次
2. 定義dump文件保存路徑
3. 定義dump文件名稱
測試
恢復備份
1. 將備份文件移動到redis安裝目錄并啟動服務
flushall、flushdb命令也會產生備份文件
物理恢復,服務、備份需要分機隔離,防止硬盤損壞后備份文件也丟失。
手動觸發備份
redis提供了兩個命令來生成RDB文件, save
和 bgsave
。
save
會阻塞當前redis服務器,知道持久化工作完成,在執行save命令期間,redis不能處理其他命令,
生產禁止使用
。
bgsave
redis會在后臺異步進行快照操作,
不阻塞
,在進行快照同時還能響應客戶端請求,該觸發方式會fork一個子進程,由子進程復制持久化過程。
Redis會使用bgsave對當前內存中的所有數據做快照,這個操作是子進程在后臺完成的,這就允許主進程同時可以修改數據。
劣勢
在備份間隔期間redis意外down調的話,會丟失當前至最新一次快照的數據。
內存數據全量同步,如果數據量太大會造成占用大量I/O,影響服務器性能。
RDB依賴于主進程的fork,在更大的數據集中,這可能導致服務的請求的瞬間延遲,fork的時候內存中的數據被克隆了一份,需要考慮容量。
如何檢修dump.rdb文件
觸發RDB快照的情況
- 配置文件中默認的快照配置
- 執行save、bgsave命令
- 執行flushdb、flushall命令,但是生成的dump.rdb文件是空的,沒有意義。
- 屬性shutdown并且沒有設置開啟AOF持久化
- 主從復制,主節點自動觸發
禁用快照
-
啟動服務時輸入相關參數
redis -cli config set save ""
-
修改配置文件
RDB模式相關配置參數詳解
-
save <seconds> <changes> 快照的頻率
-
dbfilename 快照文件的名稱
-
dir 快照文件的目錄
-
stop-writes-on-bgsave-error
默認yes
如果配置成no,表示你不在乎數據不一致或者有其他的手段發現和控制這種不一致,那么在快照寫入失敗時,
也能確保redis繼續接受新的寫請求
-
rdbcompression
默認yes
對于存儲到磁盤中的快照,可以設置是否進行壓縮存儲。如果是的話,redis會采用LZF算法進行壓縮。
如果你不想消耗CPU來進行壓縮的話,可以設置為關閉此功能 -
rdbchecksum
默認yes
在存儲快照后,還可以讓redis使用CRC64算法來進行數據校驗,但是這樣做會增加大約10%的性能消耗,如果希望獲取到最大的性能提升,可以關閉此功能 -
rdb-del-sync-files
在沒有持久性的情況下刪除復制中使用的RDB文件啟用。默認情況下no,此選項是禁用的。
小總結
AOF模式(Append Only File)
介紹
以日志的形式來記錄每個寫操作,將Redis執行過的所有寫指令記錄下來(讀操作不記錄),只許追加文件但不可以改寫文件,redis啟動之初會讀取該文件重新構建數據,換言之,redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。
默認情況下,redis是沒有開啟AOF的,如果開啟的話需要修改配置文件。
配置AOF開啟、AOF備份文件路徑、AOF備份文件名
AOF持久化工作流程
1-Client作為命令的來源,會有多個源頭以及源源不斷的請求命令。
2-在這些命令到達Redis Server 以后并不是直接寫入AOF文件,會將其這些命令先放入AOF緩存中進行保存。這里的AOF緩沖區實際上是內存中的一片區域,存在的目的是當這些命令達到一定量以后再寫入磁盤,避免頻繁的磁盤IO操作。
3-AOF緩沖會根據AOF緩沖區同步文件的三種寫回策略將命令寫入磁盤上的AOF文件。
4-隨著寫入AOF內容的增加為避免文件膨脹,會根據規則進行命令的合并(又稱AOF重寫),從而起到AOF文件壓縮的目的。
5-當Redis Server 服務器重啟的時候會從AOF文件載入數據。
AOF緩沖區三種寫回策略
- always
同步寫回,每個寫命令執行完立刻同步的將日志寫回磁盤 - everysec
每秒寫回,每個寫命令執行完,只是先把日志寫到AOF文件內存緩沖區,每隔一秒把緩沖區的內容寫入磁盤 - no
操作系統控制的寫回,每個寫命令執行完,只是先把日志寫到AOF文件
AOF文件路徑
redis6
AOF文件與RDB文件的位置一樣,在此配置
redis7
最終保存路徑為 dir+appenddirname
AOF文件名稱
redis6
有且只有一個
redis7
恢復
正常恢復
- 配置文件中 appendonly no 改為 appendonly yes
- 重啟服務
異常恢復
- 重啟服務會進入AOF文件的載入,如果AOF文件有問題,則無法啟動
- 異常修復命令:redis -check -aof --fix
優勢
可緊急恢復、性能高、數據更不易丟失
劣勢
對于相同的數據集來說,AOF文件要遠大于RDB文件,恢復速度慢于RDB
AOF運行效率要慢于RDB,每秒同步策略較好
AOF重寫機制
介紹
由于AOF持久化是Redis不斷將寫命令記錄到 AOF 文件中,隨著Redis不斷的進行,AOF 的文件會越來越大,文件越大,占用服務器內存越大以及 AOF 恢復要求時間越長。為了解決這個問題,Redis新增了重寫機制,當AOF文件的大小超過所設定的峰值時,Redis就會自動啟動AOF文件的內容壓縮,只保留可以恢復數據的最小指令集,或者可以手動使用命令 bgrewriteaof 來重新。
觸發機制
注意 ,同時滿足,且的關系才會觸發。
1 根據上次重寫后的aof大小,判斷當前aof大小是不是增長了1倍
2 重寫時滿足的文件大小
3 滿足配置文件中的配置項后,Redis會記錄上次重寫的AOF文件大小,默認配置是當AOF文件大小是上次write后大小的一倍且文件大于64MB時
4 可以執行bgrewriteof命令
總結
AOF文件重寫并不是對原文件進行重新整理,而是直接讀取服務器現有的鍵值對,然后用一條命令去代替之前記錄這個鍵值對的多條命令,生成一個新的文件后去替換原來的AOF文件。
原理
1:在重寫開始前,redis會創建一個“重寫子進程”,這個子進程會讀取現有的AOF文件,并將其包含的指令進行分析壓縮并寫入到一個臨時文件中。
2:與此同時,主進程會將新接收到的寫指令一邊累積到內存緩沖區中,一邊繼續寫入到原有的AOF文件中,這樣做是保證原有的AOF文件的可用性,避免在重寫過程中出現意外。
3:當“重寫子進程”完成重寫工作后,它會給父進程發一個信號,父進程收到信號后就會將內存中緩存的寫指令追加到新AOF文件中
4:當追加結束后,redis就會用新AOF文件來代替舊AOF文件,之后再有新的寫指令,就都會追加到新的AOF文件中
5:重寫aof文件的操作,并沒有讀取舊的aof文件,而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件,這點和快照有點類似
配置項詳細說明
小總結
RDB-AOF混合持久化模式
在同時開啟RDB和AOF持久化時,重啟只會加載AOF文件,不會加載RDB文件。
RDB+AOF混合方式
結合了RDB和AOF的優點,既能快速加載又能避免丟失過多的數據
開啟混合方式設置
設置aof-use-rdb-preamble的值為 yes yes表示開啟,設置為no表示禁用
先使用RDB進行快照存儲,然后使用AOF持久化記錄所有的寫操作,當重寫策略滿足或手動觸發重寫的時候,將最新的數據存儲為新的RDB記錄。這樣的話,重啟服務的時候會從RDB和AOF兩部分恢復數據,既保證了數據完整性,又提高了恢復數據的性能。簡單來說:混合持久化方式產生的文件一部分是RDB格式,一部分是AOF格式。----》AOF包括了RDB頭部+AOF混寫
純緩存模式
同時關閉RDB模式和AOF模式,但仍可以使用save、bgsave命令來生成rdb文件,用bgrewriteaof命令來生成aof文件。