這是redis系列文章之《redis持久化【RDB+AOF】持久化雙雄》,上一篇文章【redis基礎(chǔ)】redis的十大數(shù)據(jù)類型_努力努力再努力mlx的博客-CSDN博客
感謝大家的支持~
目錄
RDB
什么是RDB
RDB的作用
配置文件關(guān)于RDB部分? 6vs7
操作步驟
修改配置文件(本案例設置5s修改2次)
修改dump文件的保存路徑
修改dump文件名稱
觸發(fā)備份
自動觸發(fā)
如何恢復
手動觸發(fā)
優(yōu)劣分析
修復RDB文件
觸發(fā)快照的情況
禁用快照
優(yōu)化配置
總結(jié)
AOF
什么是AOF
AOF的作用
AOF持久化工作流程
AOF緩沖區(qū)三種寫回策略
redis6 vs redis7配置文件關(guān)于AOF的區(qū)別
AOF文件發(fā)揮作用
AOF文件損壞后的修復
AOF的優(yōu)劣
AOF的重寫機制
AOF優(yōu)化配置
總結(jié)
RDB - AOF混合持久化
純緩存模式
RDB
什么是RDB
RDB是在指定的時間間隔內(nèi),對執(zhí)行數(shù)據(jù)集時間點進行快照。實現(xiàn)類似照片記錄效果的方式,就是把某一時刻的數(shù)據(jù)和狀態(tài)以文件的形式寫到磁盤上,也就是快照。在這種情況下,即使redis發(fā)生宕機或者其他類型的故障問題,數(shù)據(jù)也會在快照文件中有所保存,數(shù)據(jù)的可靠性也有所保證。這個快照文件就稱為RDB文件(dump.rdb),其中,RDB就是Redis DataBase的縮寫。
RDB的作用
在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤,也就是行話講的Snapshot內(nèi)存快照,它恢復時再將硬盤快照文件直接讀回到內(nèi)存里。其中redis的數(shù)據(jù)都是保存在內(nèi)存中的,在保存?zhèn)浞輹r它執(zhí)行的是全量快照,也就是說把內(nèi)存中的所有數(shù)據(jù)都記錄在磁盤中(一鍋端)
配置文件關(guān)于RDB部分? 6vs7
在redis6.0.16及以下和redis6.2、redis7.0.0的配置文件對生成快照文件的設置有所不同
redis6.0.16
redis6.2、redis7.0.0
操作步驟
修改配置文件(本案例設置5s修改2次)
修改dump文件的保存路徑
修改dump文件名稱
觸發(fā)備份
自動觸發(fā)
第一種情況:
第二種情況:因為我們設置的是5s內(nèi)變化2次會生成dump文件,所以在這種情況下不會生成dump文件
如何恢復
直接將備份文件進行恢復即可
需要注意的是:當我們進行flushdb的操作后,同樣會生成dump文件,但是這個dump文件中的內(nèi)容是空的,也就是說,它保存了空的數(shù)據(jù),對于redis數(shù)據(jù)恢復而言沒有任何意義。?
手動觸發(fā)
save
- 在主線程中執(zhí)行會阻塞redis服務器,直到持久化工作完成才能處理其他命令, 線上禁止使用
bgsave
- Redis 會在后臺異步進行快照操作,不阻塞快照同時還可以響應客戶端請求,該觸發(fā)過程會 fork 一個子進程由子進程復制持久化過程
- lastsave 命令可以獲取最后一次成功執(zhí)行快照的時間?
優(yōu)劣分析
優(yōu)勢:
- 適合大規(guī)模的數(shù)據(jù)恢復
- 按照業(yè)務定時備份
- 對數(shù)據(jù)完整性和一致性要求不高
- RDB 文件在內(nèi)存中的加載速度比AOF快得多
?劣勢:
- 在一定間隔時間做一次備份,如果redis意外down機,就會丟掉最近一次快照到down機時的數(shù)據(jù)
- 內(nèi)存數(shù)量的全量同步,如果數(shù)據(jù)量過大會導致IO嚴重影響服務器性能
- RDB依賴于主進程的 fork ,在更大的數(shù)據(jù)集中,這可能會導致服務器請求的瞬間延遲
- fork 的時候內(nèi)存中的數(shù)據(jù)被克隆了一份,大致2倍的膨脹性,需要考慮
修復RDB文件
觸發(fā)快照的情況
- 配置文件中默認的快照配置
- 手動 save/bgsave 命令
- 執(zhí)行flush / flushdb 命令也會產(chǎn)生 dump.rdb 文件,但里面是空的,無意義
- 執(zhí)行 shutdown 且沒有設置開啟 AOF 持久化
- 主從復制時,主節(jié)點自動觸發(fā)
禁用快照
動態(tài)所有停止RDB保存規(guī)則的方法:redis-cli?config?set?save?""
優(yōu)化配置
總結(jié)
AOF
什么是AOF
- 以日志的形式來記錄每個寫操作,將Redis執(zhí)行過的所有寫指令記錄下來(讀操作不記錄),只許追加文件但不可以改寫文件,redis啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù),換言之,redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復工作
- 默認情況下,redis是沒有開啟AOF的
- 開啟AOF 功能需要設置配置 : appendonly yes
?
AOF的作用
簡單來說,AOF的作用是記錄指令中的寫操作,當redis重新啟動時從生成的aof文件中賭球數(shù)據(jù),進行數(shù)據(jù)的恢復
AOF持久化工作流程
AOF緩沖區(qū)三種寫回策略
三種寫回策略
- always 同步寫回,每個寫命令執(zhí)行完立刻同步地將日志寫回磁盤
- everysec 每秒寫回,每個寫命令執(zhí)行完,只是先把日志寫到AOF緩沖區(qū),每隔1s把緩存區(qū)地數(shù)據(jù)寫入磁盤
- no 操作系統(tǒng)控制寫回,只是將日志先寫到AOF文件的內(nèi)存緩沖區(qū),由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回磁盤
?
redis6 vs redis7配置文件關(guān)于AOF的區(qū)別
aof文件-保存路徑
- Redis 6?AOF保存文件的位置和RDB保存文件的位置一樣,都是通過redis.conf配置文件的dir配置
- Redis 7 作了改變 dir/appendirname?
d. aof文件-保存名稱
- Redis 6 有且只有一個
- Redis 7 三個文件:base基本文件、incr增量文件、manifest清單文件(manifest文件會被默認清除)
AOF文件發(fā)揮作用
恢復1:
重啟redis然后重新加載,結(jié)果OK
恢復2:
- 寫入數(shù)據(jù)進redis,然后flushdb+shutdown服務器
- 新生成了dump和aof
- 備份新生成的aof.bak,然后刪除dump/aof
- 再看恢復B重啟redis然后重新加載
- 停止服務器,拿出我們的備份修改后再重新啟動服務器。
AOF文件損壞后的修復
在網(wǎng)絡閃斷時,aof文件寫了錯誤的指令,使用 異常修復命令 : redis-check-aof --fix 進行修復?
AOF的優(yōu)劣
優(yōu)勢
- 更好的保護數(shù)據(jù)不丟失、性能高、可做緊急恢復
劣勢
- 相同數(shù)據(jù)集的數(shù)據(jù)而言aof文件要遠大于rdb文件,恢復速度慢于rdb
- aof運行效率要慢于rdb,每秒同步策略效率較好,不同步效率和rdb相同
AOF的重寫機制
啟動AOF文件的內(nèi)容壓縮,只保留可以恢復數(shù)據(jù)的最小指令集
自動觸發(fā)
滿足配置文件中的選項后,Redis會記錄上次重寫時地AOF大小
默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時
手動觸發(fā)
客戶端向服務器發(fā)送 bgrewriteaof 命令
結(jié)論:也就是說AOF文件重寫并不是對原文件進行重新整理,而是直接讀取服務器現(xiàn)有的鍵值對,然后用一條命令去代替之前記錄這個鍵值對的多條命令,生成一個新的文件后去替換原來的AOF文件。
AOF文件重寫觸發(fā)機制:通過 redis.conf配置文件中的auto-aof-rewrite-percentage:默認值為100,以及auto-aof-rewritemin-size: 64mb配置,也就是說默認Redis會記錄上次重寫時的AOF大小,默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。
AOF重寫原理?
1.在重寫開始前,redis會創(chuàng)建一個“重寫子進程”,這個子進程會讀取現(xiàn)有的AOF文件,并將其包含的指令進行分析壓縮并寫入到一個臨時文件中。
2.與此同時,主進程會將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中,一邊繼續(xù)寫入到原有的AOF文件中,這樣做是保證原有的AOF文件的可用性,避免在重寫過程中出現(xiàn)意外。
3.當“重寫子進程”完成重寫工作后,它會給父進程發(fā)一個信號,父進程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中
4.當追加結(jié)束后,redis就會用新AOF文件來代替舊AOF文件,之后再有新的寫指令,就都會追加到新的AOF文件中
5.重寫aof文件的操作,并沒有讀取舊的aof文件,而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件,這點和快照有點類似
AOF優(yōu)化配置
總結(jié)
RDB - AOF混合持久化
同時開啟兩種持久化方式
當redis 重啟時候會優(yōu)先載入AOF文件來恢復原始的數(shù)據(jù),因為在通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整
RDB的數(shù)據(jù)不實時,同時使用兩者時服務器重啟也只會找AOF文件。
那要不要只使用AOF呢
安特雷茲建議不要
因為RDB更適合用于備份數(shù)據(jù)庫(AOF不斷變化不好備份),留著AOF作為一個萬一的手段
1 開啟混合方式設置
設置aof-use-rdb-preamble的值為 yes ??yes表示開啟,設置為no表示禁用
2 RDB+AOF的混合方式---------> 結(jié)論:RDB鏡像做全量持久化,AOF做增量持久化
先使用RDB進行快照存儲,然后使用AOF持久化記錄所有的寫操作,當重寫策略滿足或手動觸發(fā)重寫的時候,將最新的數(shù)據(jù)存儲為新的RDB記錄。這樣的話,重啟服務的時候會從RDB和AOF兩部分恢復數(shù)據(jù),既保證了數(shù)據(jù)完整性,又提高了恢復數(shù)據(jù)的性能。簡單來說:混合持久化方式產(chǎn)生的文件一部分是RDB格式,一部分是AOF格式。----》AOF包括了RDB頭部+AOF混寫
純緩存模式
同時關(guān)閉RDB + AOF文章來源:http://www.zghlxwxcb.cn/news/detail-473660.html
save “”
禁用rdb
禁用db持久化模式下,我們?nèi)匀豢梢允褂妹顂ave、bgsave生成rdb文件
appendonly no
禁用aof
禁用aof持久化模式下,我們?nèi)匀豢梢允褂妹?bgrewriteaof生成aof文件
?文章來源地址http://www.zghlxwxcb.cn/news/detail-473660.html
到了這里,關(guān)于redis持久化【RDB+AOF】持久化雙雄的文章就介紹完了。如果您還想了解更多內(nèi)容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!