尚硅谷redis7 41-46 redis持久化之AOF異常恢復演示

AOF每一秒鐘寫入一次。當內容才寫了一小半,沒有寫完整時，突然,redis掛了,導致aof文件錯誤。

故意亂寫正常的AOF文件,模擬網絡閃斷文件寫error
重啟 Redis 之后就會進行AOF文件的載入,發現啟動都失敗

首先cd /usr/local/bin 異常修復命令:redis-check-aof -- fix 進行修復

不需要三個都修復，修復incr即可。

重新OK

42 redis持久化之AOF優缺點案例總結

AOF優勢

1.使用AOF Redis更加持久:您可以有不同的fsync【寫回】策略:根本不fsync、每秒fsync、每次查詢時fsync。使用每秒fsync的默認策略。寫入性能仍然很棒。fsync是使用后臺線程執行的,當沒有fsync正在進行時,主線程將努力執行寫入,因此您只能丟失一秒鐘的寫入【最差的情況就是丟失1秒】。

2.AOF日志是一個僅附加日志,因此不會出現尋道問題,也不會在斷電時出現損壞問題。即使由于某種原因(磁盤已滿或其他原因)日志以當一半的命令結尾,redis-check-aof 工具也能夠輕松修復它。

僅附加日志：AOF 文件在記錄數據變更時是追加寫入（append-only）的。每次執行寫命令（如 SET, DEL, INCR 等），Redis 都會把這個命令的文本形式寫入到 AOF 文件的末尾。

不會修改已有的數據內容。

類似于一個不斷增長的操作歷史記錄。

尋道問題：傳統關系型數據庫（如 MySQL、PostgreSQL）使用的是復雜的數據結構和存儲策略，比如：B+樹索引結構。寫入一條記錄可能要更新記錄頁，索引頁等等，這些頁通常分散在磁盤的不同位置，因此需要多次尋道來定位并修改。而AOF因為只做追加寫入，文件指針總是在文件末尾，不需要頻繁地移動文件指針來讀寫不同位置（這就叫“尋道”）。

為什么不會在斷電時出現損壞問題？

由于 AOF 是順序寫，且每條寫命令在寫入前可以通過 fsync 或 fdatasync 確保刷入磁盤，即使突然斷電：

只可能丟失“最后一條命令”，而不是導致整個文件損壞。

不會出現“中間內容被破壞”的問題。

3.當AOF變得太大時,Redis能夠在后臺自動重寫AOF,重寫是完全安全的,因為當Redis繼續附加到舊文件時,會使用創建當前數據集所需的最少操作集生成一個全新的文件,一旦第二個文件準備就緒,Redis就會切換兩者并開始附加到新的那一個。

4.·AOF以易于理解和解析的格式依次包含所有操作的日志。您甚至可以輕松導出AOF文件。例
如,即便您不小心使用該FLUSHALL命令刷新了所有內容,只要在此期間沒有執行日志重寫,您
仍然可以通過停止服務器、刪除最新命令并重新啟動Redis來保存您的數據集。

進入aof文件存儲的路徑

vim appendonly.aof.1.incr.aof

刪除最后一條FLUSHALL命令

總結：更好的保護數據不丟失，性能高，可做緊急恢復

AOF缺點

1.AOF文件通常比相同數據集的等效RDB文件大。
2.根據確切的fsync策略,AOF可能比RDB慢。一般來說,將fsync設置為每秒性能仍然非常高,并且在禁用fsync的情況下,即使在高負載下它也應該與RDB一樣快。即使在巨大的寫入負載的情況下,RDB仍然能夠提供關于最大延遲的更多保證。

總結：

相同數據集的數據而言aof文件要遠大于rdb文件,恢復速度慢于rdb
aof運行效率要慢于rdb,每秒同步策略效率較好,不同步效率和rdb相同

43 redis持久化之AOF重寫機制案例

由于AOF持久化是Redis不斷將寫命令記錄到AOF文件中,隨著Redis不斷的進行,AOF的文件會越來越大。文件越大,占用服務器內存越大以及AOF恢復要求時間越長。

為了解決這個問題,Redis新增了重寫機制,當AOF文件的大小超過所設定的峰值時,Redis就會自動啟動AOF文件的內容壓縮,只保留可以恢復數據的最小指令集或者可以手動使用命令 bgrewriteaof 來重新。

自動觸發

auto- aof- rewrite- percentage 100
auto- aof- rewrite-mil size 64mb

滿足配置文件中的選項后,Redis會記錄上次重寫時的AOF大小,默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時才會自動觸發

注意,同時滿足,且的關系才會觸發
1 根據上次重寫后的aof大小,判斷當前aof大小是不是增長了1倍
2 重寫時滿足文件大小

為什么需要壓縮？

啟動AOF文件的內容壓縮,只保留可以恢復數據的最小指令集。

舉個例子:比如有個key
一開始你 set k1 v1
然后改成 set k1 v2
最后改成 set k1 v3
如果不重寫,那么這3條語句都在aof文件中,內容占空間不說啟動的時候都要執行一遍,共計3條命令;
但是,我們實際效果只需要set k1 v3這一條,所以,開啟重寫后,只需要保存set k1 v3就可以了只需要保留最后一次修改值,相當于給aof文件瘦身減肥,性能更好。

AOF重寫不僅降低了文件的占用空間,同時更小的AOF也可以更快地被Redis加載。

案例實施

前期配置

開啟aof

appendonly yes

重寫峰值修改為1k

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 1k

關閉redis和aof混合,設置為no?

aof-use-rdb-preamble no

刪除之前的全部aof和rdb,清除干擾項

PS：如果按照視頻操作之后，并沒有生成aof文件可以嘗試如下操作

1.可以連接redis后檢查一下aof是否開啟：config get appendonly

2.如果返回no就是開啟失敗。也可以不修改redis.conf文件。手動設置開啟：redis-cli CONFIG SET appendonly yes? 【這并不是永久開啟aof。僅限于當前進程】

或者是因為重新啟動redis.conf文件時還有redis進程在運行，所以開啟失敗。

1.查找reids運行的進程? ps aux | grep redis? 或者?使用 pidof 查找 Redis 主進程 PID??pidof redis-server

2.再kill 返回的PID

3.再redis-server redis.conf 【一般這個時候就會加載成功】

自動觸發

完成上述正確配置,重啟redis服務器,執行set k1 v1查看aof文件是否正常

查看三大配置文件

幾種類型文件的前綴,又追有關序列和類型的附加信息
appendfilename "appendonly.aof"

新版本端加的目錄配置項目
appenddirname "appendonlydir"

如有下的aof文件存在
1. 基本文件
appendonly.aof.1.base.rdb
2. 增量文件
appendonly.aof.1.incr.aof
appendonly.aof.2.incr.aof
3. 清單文件
appendonly.aof.manifest

I

k1不停1111111111111111111暴張

重寫觸發：超過1k之后，發現文件壓縮變小。

手動觸發重寫

客戶端向服務器發送bgrewriteaof命令

總結

AOF文件重寫并不是對原文件進行重新整理,而是直接讀取服務器現有的鍵值對,然后用一條命令去代替之前記錄這個鍵值對的多條命令,生成一個新的文件后去替換原來的AOF文件。

AOF文件重寫觸發機制:通過redis.conf 配置文件中的auto-aof-rewrite-percentage:默認值為100,以及auto-aof-rewrite-min-size:64mb配置,也就是說默認Redis會記錄上次重寫時的AOF大小,默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發。

44 redis持久化之AOF小總結

45 redis持久化之RDB+AOF混合持久化

rdb vs aof

問題

可否共存？AOF 和 RDB 持久化可以同時啟用，不會有任何問題。如果在啟動時啟用了 AOF，Redis 會加載 AOF 文件，因為它提供了更好的數據持久性保障。

數據恢復順序和加載流程【面試】

在同時開啟rdb和aof持久化時，重啟時只會加載aof文件不會加載rdb文件

怎么選？用哪個？

RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲
AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執行這些命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操作到文件末尾.

同時開啟兩種持久化的方式

在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據,因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.
RDB的數據不實時,同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？
作者建議不要,因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份),留著rdb作為一種以防萬一的手段

RDB+AOF混合持久化方式

結合了RDB和AOF的優點，既能快速加載又能避免丟失過多數據

1 開啟混合方式設置
設置aof-use-rdb-preamble的值為yes yes表示開啟,設置為no表示禁用
2 RDB+AOF的混合方式 --------- >結論:RDB鏡像做全量持久化,AOF做增量持久化
先使用RDB進行快照存儲,然后使用AOF持久化記錄所有的寫操作,當重寫策略滿足或手動觸發重寫的時候,將最新的數據存儲為新的RDB記錄。。這樣的話,重啟服務的時候會從RDB和AOF兩部分恢復數據,既保證了數據完整性,又提高了恢復數據的性能。

簡單來說:混合持久化方式產生的文件一部分是RDB格式,一部分是AOF格式。 ---- 》AOF包括了RDB頭部+AOF混寫

46 redis持久化之純緩存模式only

在 Redis 的持久化配置中，“純緩存模式”（persistence-only 模式 / cache-only 模式），通常是指 禁用所有持久化機制（RDB 和 AOF），讓 Redis 只作為內存緩存來使用。

純緩存的作用

作用	說明
?更快的性能	無磁盤 I/O，適合對延遲極其敏感的應用。
?節省磁盤資源	不產生 dump.rdb / appendonly.aof 等文件。
容器化部署	與容器生命周期一致，重啟就清空數據，適合短生命周期或臨時環境。
作為純粹的緩存使用	比如配合數據庫使用，僅緩存熱點數據，宕機沒關系，下次可重新加載。