Redis的AOF持久化測試
阿新 • • 發佈:2019-02-07
AOF檔案:
上面已經多次講過,RDB的快照定時dump機制無法保證很好的資料永續性。如果我們的應用確實非常關注此點,我們可以考慮使用Redis中的AOF機制。對於Redis伺服器而言,其預設的機制是RDB,如果需要使用AOF,則需要修改配置檔案中的以下條目:
將appendonly no改為appendonly yes
從現在起,Redis在每一次接收到資料修改的命令之後,都會將其追加到AOF檔案中。在Redis下一次重新啟動時,需要載入AOF檔案中的資訊來構建最新的資料到記憶體中。
redis.conf:(修改配置的配置檔案)
APPEND ONLY MODE:
appendonly no --改為yes,redis啟動時會載入AOF
appendfilename "appendonly.aof" --aof檔案的名稱,預設不變即可
#appendfsync always #每次有資料修改發生時都會寫入AOF檔案。
appendfsync everysec #每秒鐘同步一次,該策略為AOF的預設策略。
#appendfsync no #從不同步。高效但是資料不會被持久化。
no-appendfsync-on-rewrite no
--在預設情況下,當aof進行重寫時,aof的同步資訊不是關閉的。在這種情況下,子程序rewrite(bgrewriteaof命令可進行aof檔案非同步重寫)在寫磁碟,在rewrite的過程中 子程序對主程序造成了磁碟阻塞(disk io衝突),導致了報警資訊的產生。
--但是這個引數修改成 yes之後 ,又會有安全上的問題。因為這時候並沒有執行磁碟操作,只是將命令寫入了緩衝區。當rewrite的過程中 要是redis服務down掉的話 丟失的資料 就不是之前appendfsync 定下的策略。而是整個 rewrite 過程中的所有資料。
auto-aof-rewrite-percentage 100 --重啟後,如果aof檔案當前大小比重啟時增長了百分之100就觸發重寫aof,做整合
auto-aof-rewrite-min-size 64mb --重啟後,如果aof檔案大小達到了64m就觸發重寫,做整合
aof-load-truncated yes --如果aof檔案是被清空了的,重啟時是否過載。有時候會有異常被清空,但是如果人家真的是想清空的,那也是得裝載,所以預設為yes就好。
開始測試:
第一步:按照上面把配置檔案redis.conf修改好,然後啟動redis服務和客戶端(分兩個終端)
cd /usr/local/redis
./bin/redis-server redis.conf
cd/usr/local/redis
./bin/redis-cli
第二步:在客戶端新建一個key,然後新開終端進/var/redis裡面看是否產生了aof檔案,產生了即AOF持久化生效
set strkey aa
可以看到命令已經存進來了。第一個命令是選擇資料庫,預設為資料庫0。第二條命令就是set strkey aa,其中 *3 表示的是命令由三部分組成。
第三步:重啟伺服器,看key是否還存在
keys *
第四步:設定一個String型別的key,值為2,然後重複incr key命令,看aof檔案內容。
命令如下:
set key1 1
incr key
incr key
..
..
aof內容如下:
可以發現,重複的命令會重複地寫進aof檔案裡面,此時如果我們進行重寫,結果會程式設計什麼樣呢?
第五步:在客戶端執行bgrewriteaof命令,可進行後臺程序重寫aof。重寫後看看aof檔案內容。
可發現:最後省去所有命令,將key1的最後值賦給key1,即命令set key1 最後值
所以:上面的關於重寫的命令auto-aof-rewrite-percentage,auto-aof-rewrite-min-size都是問了檔案達到了一定的大小就進行重寫,就是對aof檔案進行整合:將多餘的命令都省去,直接改為賦值。