Redis之RDB與AOF

標籤：size   工作   always   log   配置   快速   html   緩衝   複數   

Tip:
一.RDB與AOF同時開啟  預設先載入AOF的設定檔
二.相同資料集，AOF檔案要遠大於RDB檔案，恢複速度慢於RDB
三.AOF運行效率慢於RDB,但是同步策略效率好，不同步效率和RDB相同

RDB的優點:
RDB是一個緊湊壓縮的二進位檔案，代表Redis在某一個時間點上的資料快照。非常適合用於備份，全量複製等情境。比如每6小時執行bgsave備份，並把RDB檔案拷貝到遠程機器或者檔案系統中（如hdfs），用於災難恢複。
Redis載入RDB恢複資料遠遠快於AOF方式。

RDB的缺點:
RDB方式資料沒辦法做到即時持久化/秒級持久化。因為bgsave每次運行都要執行fork操作建立子進程，屬於重量級操作，頻繁執行成本過高。
RDB檔案使用特定二進位格式儲存，Redis版本演化過程中有多個格式的RDB笨笨，存在老版本Redis服務無法相容新版RDB格式的問題。


AOF定義：以日誌的形式記錄每個操作，將Redis執行過的所有指令全部記錄下來（讀操作不記錄），只許追加檔案但不可以修改檔案，Redis啟動時會讀取AOF設定檔重構資料
換句話說，就是Redis重啟就會根據日誌內容從頭到尾執行一次來完成資料的恢複工作。


1.RDB持久化(以快照的方式) 策略（預設）：
save 900 1       （15分鐘變更一次）
save 300 10     （5分鐘變更10次）
save 60 10000  （1分鐘變更1萬次）


2.RDB預設設定檔名稱：
dbfilename dump.rdb


3.表示是否開啟AOF持久化：
appendonly yes(預設no,關閉)


4.AOF持久化設定檔的名稱：
appendfilename "appendonly.aof"


5.AOF持久化策略(預設每秒)：
appendfsync always (同步持久化，每次發生資料變更會被立即記錄到磁碟，效能差但資料完整性比較好)
appendfsync everysec (非同步作業，每秒記錄，如果一秒鐘內宕機，有資料丟失)
appendfsync no  （將緩衝回寫的策略交給系統，linux 預設是30秒將緩衝區的資料回寫硬碟的）


6.AOF設定檔損壞修複方法：
進入redis安裝路徑 執行 redis-check-aof --fix AOF設定檔名稱


7.AOF的Rewrite(重寫) ：
定義：AOF採用檔案追加的方式持久化資料，所以檔案會越來越大，為了避免這種情況發生，增加了重寫機制。
當AOF檔案的大小超過了配置所設定的闕值時，Redis就會啟動AOF檔案壓縮，只保留可以恢複資料的最小指令集，可以使用命令bgrewriteaof。

原理：當AOF增長過大時，會fork出一條新的進程將檔案重寫(也是先寫臨時檔案最後rename)，遍曆新進程的記憶體資料，每條記錄有一條set語句。
重寫AOF檔案並沒有操作舊的AOF檔案，而是將整個記憶體中的資料內容用命令的方式重寫了一個新的aof檔案（有點類似快照）。

觸發機制：Redis會記錄上次重寫時的AOF檔案大小，預設配置時當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。
auto-aof-rewrite-percentage 100  （一倍）
auto-aof-rewrite-min-size 64mb


8.RDB與AOF的選擇：
做備份：當資料量大，且對恢複速度有要求，並且資料的一致性要求不高的話，可以只使用RDB
只做緩衝：不用開啟任何的持久化方式
兩者都開啟的建議：RDB資料不即時，同時使用兩者時伺服器只會找AOF檔案，可不可以只使用AOF?建議不要，因為RDB更適合備份資料庫(AOF在不斷變化，不好備份)，快速重啟，而且不會又AOF可能潛在的BUG,留作萬一的手段。


來源：
https://www.cnblogs.com/wangfajun/p/5787077.html
http://www.chenxm.cc/post/526.html

Redis之RDB與AOF