AOF
1 前言
RDB 的缺陷是最後一次持久化後的數據可能丟失。而AOF就是用來解決這個問題的.
2 簡介
append only file ,以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，
只許追加文件但不可以改寫文件，redis重啓後就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作.
3 AOF的重寫
- 簡介
AOF採用文件追加方式，文件會越來越大爲避免出現此種情況，新增了重寫機制,當AOF文件的大小超過所設定的閾值時，Redis就會啓動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof.
- 重寫機制
AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似.
- 觸發條件
Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發.
4 配置
#AOF持久化，是否記錄更新操作日誌，默認redis是異步（快照）把數據寫入本地磁盤
appendonly no
#指定更新日誌文件名
appendfilename "appendonly.aof"
# 每次有數據發生變化時都會寫入appendonly.aof
# appendfsync always
# 默認方式，每秒同步一次到appendonly.aof
appendfsync everysec
# 不同步，數據不會持久化
# appendfsync no
# 當AOF日誌文件即將增長到指定百分比時，redis通過調用BGREWRITEAOF是否自動重寫AOF日誌文件。
no-appendfsync-on-rewrite no
# aof自動重寫%比。當目前aof文件大小超過上一次重寫的aof文件大小的百分之多少進行重寫，即當aof文件增長到一定大小的時候Redis能夠調用bgrewriteaof對日誌文件進行重寫。當前AOF文件大小是上次日誌重寫得到AOF文件大小的二倍（設置爲100）時，自動啓動新的日誌重寫過程。
auto-aof-rewrite-percentage 100
#設置允許重寫的最小aof文件大小，避免了達到約定百分比但尺寸仍然很小的情況還要重寫
auto-aof-rewrite-min-size 64mb
#aof文件可能在尾部是不完整的，當redis啓動的時候，aof文件的數據被載入內存。重啓可能發生在redis所在的主機操作系統宕機後，尤其在ext4文件系統沒有加上data=ordered選項（redis宕機或者異常終止不會造成尾部不完整現象。）出現這種現象，可以選擇讓redis退出，或者導入儘可能多的數據。如果選擇的是yes，當截斷的aof文件被導入的時候，會自動發佈一個log給客戶端然後load。如果是no，用戶必須手動redis-check-aof修復AOF文件纔可以。
aof-load-truncated yes
5 演示
將 appendonly no 設置爲 appendonly yes.
6 修復
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-CjGaZmk5-1590223614333)(E:\redis筆記\AOF損壞.png)]
啓動服務器
發現服務器無法啓動,看到rdb和aof同時存在,說明優先讀取的是AOF文件,因爲AOF文件損壞導致啓動失敗.
修復方法:
[root@dason bin]# redis-check-aof --fix appendonly.aof
'x 6e: Expected prefix '*', got: '
AOF analyzed: size=196, ok_up_to=110, diff=86
This will shrink the AOF from 196 bytes, with 86 bytes, to 110 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@dason bin]# redis-server /myredis/redis_aof.conf
14046:C 23 Feb 2020 22:01:25.646 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
14046:C 23 Feb 2020 22:01:25.646 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=14046, just started
14046:C 23 Feb 2020 22:01:25.646 # Configuration loaded
[root@dason bin]# redis-cli -p 6379
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
7 優劣勢
優勢: 每秒同步：appendfsync everysec 異步操作，每秒記錄 .
劣勢:
相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb…
如果一秒內宕機，也會有數據丟失.
rewrite的最後將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的.