Redis的持久化-AOF,Redis持久化-AOF
Redis的持久化AOF模式,以日誌的形式記錄伺服器所處理的每一個寫操作,在Redis服務啟動之初會讀取該檔案來重新構建資料庫,以保證啟動後資料庫中的資料是完整的。
AOF的優點:
1、可以帶來更高的資料安全性。
2、由於對記錄檔的寫入操作採用的是append模式,因此在寫入過程匯總即使出現宕機,也不會破壞記錄檔中已經存在的內容,然而如果我們本次操作寫入一半資料就出現系統崩潰,可以在Redis下一次啟動之前,通過redis-check-aof工具協助解決資料一致性的問題。
3、如果日誌過大,Redis可以啟動rewrite機制,即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中,同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改指令被執行,rewrite切換時可以更好的保證資料安全性。
4、AOF包含一個格式清晰、易於理解的記錄檔用於記錄所有的修改操作,可以通過該檔案完成資料的重建。
AOF的缺點:
1、相同的資料的資料集,AOF檔案通常要大於RDB檔案。
2、同步策略的不同,AOF在運行效率上往往會慢於RDB,每秒同步策略的效率是比較高的,同步禁用策略的效率和RDB一樣高效。
在Redis的設定檔中存在三種同步方式,它們分別是:
1、appendfsync always:每次有資料修改發生時都會寫入AOF檔案。
2、appendfsync everysec:每秒鐘同步一次,該策略為AOF的預設策略。
3、appendfsyn no:從不同步,高效的那是資料不會被持久化。
如何修複損壞的AOF檔案?
1、將現有已經損壞的AOF檔案額外複製出來一份。
2、執行'redis-check-aof -- fix <filename>'命令來修複損壞的AOF檔案。
3、用修複後的AOF檔案重新啟動Redis服務。
redis.conf的配置,將appendonly改為yes
Redis一啟動就會在dir目錄下產生appendonly.aof,開始這個檔案是0位元組的。
查看key,有多少
dump.rdb檔案時33位元組,為什麼之前設定的key,沒有了呢?
原因:一旦appendonly設定為yes,系統會優先讀appendonly.aof檔案,而不是dump.rdb
由於appendonly.aof是空的,所以看到key也是空的。
設定一些key
appendonly.aof就變成了112位元組
查看appendonly.aof檔案,其實是將上面設定的命令記錄了一下。
AOF的啟動裝載
1、AOF優先於RDB
2、RDB的效能優於AOF,因為沒有重複
3、Redis一次性將資料載入到記憶體中,一次性預熱
Redis的裝載源碼如下:
AOF的rewrite
AOF的rewrite參數