[TOC] # 問題 ## RDB可以搞定備份恢復的事情，為什么還會出現AOF？ 答案：這個問題的答案可以參看，上面說的Redis持久化之RDB備份方式保存數據中的RDB的缺點。 也就是使用RDB進行保存時候，如果Redis服務器發送故障，那么會丟失最后一次備份的數據！ AOF出現試著來解決這個問題！ ## 同時出現RDB和AOF是沖突呢？還是協作？ 答案：是協作，不會沖突!那么是如何協作，首先加載哪一個文件呢？ 進行測試，生成dump.rdb和appendonly.aof文件，然后在appendonly.aof使文件最后隨便加入一些東西，使文件出錯，然后重新啟動redis服務，發現服務沒有啟動成功！那么就可以知道首先加載的是aof文件，使用redis-check-aof 工具修復aof文件，重新啟動，發現啟動成功！ 總結：兩者可以共存，但是首先啟動找的是aof。 ## 當redis服務器掛掉時，重啟時將按照以下優先級恢復數據到內存 如果只配置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重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。 # Redis配置文件redis.conf中關于AOF相關配置 ~~~ ############################## APPEND ONLY MODE ############################### # By default Redis asynchronously dumps the dataset on disk. This mode is # good enough in many applications, but an issue with the Redis process or # a power outage may result into a few minutes of writes lost (depending on # the configured save points). # # The Append Only File is an alternative persistence mode that provides # much better durability. For instance using the default data fsync policy # (see later in the config file) Redis can lose just one second of writes in a # dramatic event like a server power outage, or a single write if something # wrong with the Redis process itself happens, but the operating system is # still running correctly. # # AOF and RDB persistence can be enabled at the same time without problems. # If the AOF is enabled on startup Redis will load the AOF, that is the file # with the better durability guarantees. # # Please check http://redis.io/topics/persistence for more information. appendonly no # The name of the append only file (default: "appendonly.aof") appendfilename "appendonly.aof" # The fsync() call tells the Operating System to actually write data on disk # instead of waiting for more data in the output buffer. Some OS will really flush # data on disk, some other OS will just try to do it ASAP. # # Redis supports three different modes: # # no: don't fsync, just let the OS flush the data when it wants. Faster. # always: fsync after every write to the append only log. Slow, Safest. # everysec: fsync only one time every second. Compromise. # # The default is "everysec", as that's usually the right compromise between # speed and data safety. It's up to you to understand if you can relax this to # "no" that will let the operating system flush the output buffer when # it wants, for better performances (but if you can live with the idea of # some data loss consider the default persistence mode that's snapshotting), # or on the contrary, use "always" that's very slow but a bit safer than # everysec. # # More details please check the following article: # http://antirez.com/post/redis-persistence-demystified.html # # If unsure, use "everysec". # appendfsync always appendfsync everysec # appendfsync no # When the AOF fsync policy is set to always or everysec, and a background # saving process (a background save or AOF log background rewriting) is # performing a lot of I/O against the disk, in some Linux configurations # Redis may block too long on the fsync() call. Note that there is no fix for # this currently, as even performing fsync in a different thread will block # our synchronous write(2) call. # # In order to mitigate this problem it's possible to use the following option # that will prevent fsync() from being called in the main process while a # BGSAVE or BGREWRITEAOF is in progress. # # This means that while another child is saving, the durability of Redis is # the same as "appendfsync none". In practical terms, this means that it is # possible to lose up to 30 seconds of log in the worst scenario (with the # default Linux settings). # # If you have latency problems turn this to "yes". Otherwise leave it as # "no" that is the safest pick from the point of view of durability. no-appendfsync-on-rewrite no # Automatic rewrite of the append only file. # Redis is able to automatically rewrite the log file implicitly calling # BGREWRITEAOF when the AOF log size grows by the specified percentage. # # This is how it works: Redis remembers the size of the AOF file after the # latest rewrite (if no rewrite has happened since the restart, the size of # the AOF at startup is used). # # This base size is compared to the current size. If the current size is # bigger than the specified percentage, the rewrite is triggered. Also # you need to specify a minimal size for the AOF file to be rewritten, this # is useful to avoid rewriting the AOF file even if the percentage increase # is reached but it is still pretty small. # # Specify a percentage of zero in order to disable the automatic AOF # rewrite feature. auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # An AOF file may be found to be truncated at the end during the Redis # startup process, when the AOF data gets loaded back into memory. # This may happen when the system where Redis is running # crashes, especially when an ext4 filesystem is mounted without the # data=ordered option (however this can't happen when Redis itself # crashes or aborts but the operating system still works correctly). # # Redis can either exit with an error when this happens, or load as much # data as possible (the default now) and start if the AOF file is found # to be truncated at the end. The following option controls this behavior. # # If aof-load-truncated is set to yes, a truncated AOF file is loaded and # the Redis server starts emitting a log to inform the user of the event. # Otherwise if the option is set to no, the server aborts with an error # and refuses to start. When the option is set to no, the user requires # to fix the AOF file using the "redis-check-aof" utility before to restart # the server. # # Note that if the AOF file will be found to be corrupted in the middle # the server will still exit with an error. This option only applies when # Redis will try to read more data from the AOF file but not enough bytes # will be found. aof-load-truncated yes ~~~ 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：不同步 ~~~ # 重寫（rewrite） （查看Linux服務器命令-free內存， df磁盤），時間換空間的思想在里面！ ## 重寫是什么？ 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