[TOC] # 同時出現RDB和AOF是沖突呢？還是協作？ ~~~ 答案：是協作，不會沖突!那么是如何協作，首先加載哪一個文件呢？ 進行測試，生成dump.rdb和appendonly.aof文件，然后在appendonly.aof使文件最后隨便加入一些東西，使文件出錯，然后重新啟動redis服務，發現服務沒有啟動成功！那么就可以知道首先加載的是aof文件，使用redis-check-aof 工具修復aof文件，重新啟動，發現啟動成功！ 總結：兩者可以共存，但是首先啟動找的是aof。 ~~~ # 重啟時將按照以下優先級恢復數據到內存 ~~~ 如果只配置AOF,重啟時加載AOF文件恢復數據； 如果同時 配置了RBD和AOF,啟動是只加載AOF文件恢復數據; 如果只配置RBD,啟動是講加載dump文件恢復數據。 恢復時需要注意，要是主庫掛了不能直接重啟主庫，否則會直接覆蓋掉從庫的AOF文件，一定要確保要恢復的文件都正確才能啟動，否則會沖掉原來的文件。 ~~~ 如何修復：redis-check-aof –fix appendonly.aof # Redis的AOF是什么？ 官網-AOF中文：http://www.redis.cn/topics/persistence.html 以日志的形式來記錄每個寫操作（讀操作不記錄），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。 # 相關配置 ~~~ appendonly yes //啟用 aof 持久化方式 appendfilename appendonly.aof //保存命令的文件 # appendfsync always //每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用。 appendfsync everysec //每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦 # appendfsync no //完全依賴 os，性能最好,持久化沒保證,隨機 ~~~ ## 默認AOF沒有開啟 ~~~ appendonly no #如果要開啟，改為yes ~~~ 啟動：修改為yes，啟動，這里要注意的是啟動的目錄和保存aof文件目錄是否一致！查看目錄命令(config get dir)，這一點在上一篇RDB中講過 修復：使用redis-check-aof –fix 進行修復 恢復：重啟redis然后重新加載 ## 默認名稱 ~~~ appendonlyfilename appendonly.aof ~~~ ## 三種appendfsysnc：同步策略 ~~~ #always：同步持久化，每次發生數據變更會立即記錄到磁盤，性能較差到數據完整性比較好 everysec：出廠的默認推薦，異步同步，每秒記錄一次 #no：不同步 ~~~ # 重寫是什么？ AOF采用文件追加方式，文件會越來越大為避免出現此種情況，新增了重寫機制,當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof！ ~~~ aof文件的重寫，就是把文件中內容，逆化成命令存儲。 比如：10次 incr age 轉成 set age 14 一條命令 可以執行手動重寫：bgrewriteaof ~~~ # 重寫原理 ~~~ AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)， 遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件， 而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似 ~~~ # 觸發機制 ~~~ Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發。默認64M。 --看觸發機制配置，知道公司實力！ ~~~ # 優點 每修改同步：appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好 每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內宕機，有數據丟失 不同步：appendfsync no 從不同步 # 缺點 相同數據集的數據而言aof文件要遠大于rdb文件，恢復速度慢于rdb aof運行效率要慢于rdb,每秒同步策略效率較好，不同步效率和rdb相同 # 總結 客戶端--->命令請求--->服務器 ------->網絡協議格式的命令內容-->AOF文件 * AOF 文件是一個只進行追加的日志文件 * Redis可以在AOF文件體積變得過大時，自動地在后臺對AOF進行重寫 * AOF文件有序地保存了對數據庫執行所有寫入操作，這些寫入操作作為redis協議的格式保存，因此AOF文件的內容非常容易被人讀懂，對文件進行分析也很輕松 * 對于相同的數據集來說，AOF文件的體積通常大于RDB文件的體積，根據所使用的fsync策略，AOF的速度可能會慢于RDB