參考資料:
redis 4.x cookbook 中文版;
redis官方文檔
注: 本文redis的版本爲: 5.0.3
RDB快照:
快照機制是redis的一種持久化策略;
簡單描述下就是:每隔一段時間(redis.conf中可以配置),將當前數據庫的內容備份到磁盤上;下次啓動服務時,將會自動從.RDB文件中恢復數據;
#下面三個設置意思是:
#每900秒,且至少進行了一次鍵值對修改;將觸發一次rdb快照;
#每300秒,且至少進行了10次鍵值對修改;將觸發一次rdb快照;
#每60秒,且至少進行了10000次鍵值對修改;將觸發一次rdb快照;
#註釋掉save,將不會觸發rdb快照;
#save "" 也會禁止rdb快照;
save 900 1
save 300 10
save 60 10000
#如果啓用RDB快照(至少配置一個保存點[save xxx xxx])並且最新的後臺保存失敗,則Redis將停止接受寫入.
#假如設定了持久化監控,那麼建議關閉此配置,這樣可以讓redis在系統和磁盤出問題的時候,依然可以接收數據;
stop-writes-on-bgsave-error yes
#是否在保存rdb快照文件時使用壓縮字符串對象;
#如果選擇'yes'將會提高cpu消耗,選擇'no'會佔用更多空間,通常'yes'更佔優;
rdbcompression yes
#持久化之前是否進行校驗;
#yes開啓校驗,有更高的抗損壞性,但是保存或讀取rdb快照文件損失10%性能;
#no關閉校驗,意味着checksum的值永久爲0,讀取rdb快照文件時將不再進行校驗;
rdbchecksum yes
#rdb快照文件名稱;
dbfilename dump.rdb
#rdb快照工作目錄,注意,此處僅能設置文件夾,生成的文件以dbfilename爲準;
dir /var/lib/redis
在客戶端在中,我們可以使用如下命令來觸發RDB持久化:
127.0.0.1:6379> set key1 value1 nx
OK
127.0.0.1:6379> keys *
1) "key1"
127.0.0.1:6379> get key1
"value1"
#手動觸發快照;注意了,save命令是阻塞的,意味着除非此命令執行完成,否則不接收其他命令;生產環境禁用;
127.0.0.1:6379> save
OK
#手動觸發快照;此處是由redis分出一個子子進程,進行快照;redis的主進程依然可以接收命令;
#子進程在快照的時候,生成一個臨時快照文件;
#在持久化完成之後,歷史快照文件將會被刪除,臨時文件將以dbfilename 配置的值重命名;
127.0.0.1:6379> bgsave
Background saving started
AOF持久化
AOF持久化是指,通過追加文件的方式進行持久化;
在配置文件中,可以決定是相隔多久向AOF文件中追加一次數據,或者是每寫入一次數據庫就追加一次;(這裏的追加,是指將數據刷新到磁盤上,也即是配置文件中的appendfsync)
#AOF是對持久化文件(AOF文件)進行追加的一種持久化方式;
#前面的RDB持久化,由於每次都需要對數據庫進行快照,所以註定是要間隔一段時間才能進行一次;
#出現斷電情況時,將會丟失幾分鐘的數據;
#AOF是每次寫入都會追加,哪怕斷電也頂多丟失一秒鐘寫入的數據;
#AOF,RDB可以同時開啓;AOF文件是非二進制壓縮文件,佔用空間大;
#RDB優點是二進制壓縮文件可以快速還原;AOF優點是,數據丟失量更少;
#默認關閉AOF
appendonly no
#aof文件名稱;
appendfilename "appendonly.aof"
#fsync,是指通知系統將從內存中輸出的數據刷新到磁盤上(某些系統根據調用立即刷新,某些系統是儘快刷新)
#下面的配置有三個值:
#no,由操作系統決定什麼時候刷新;(速度最快,但是丟失的數據較多)
#always,每個寫操作都刷新;(速度最慢,但是安全)
#everysec,每秒同步刷新一次;(妥協值)
appendfsync everysec
#當aof設置爲每秒或者是每次操作都fsync()時,後臺如果進行BGSAVE/觸發AOF追加(會有大量的磁盤IO);
#如果主線程也進行追加,也會調用fsync(),這種情況下,會觸發阻塞;linux中最長阻塞可達30s;
#如果配置爲no,則進行追加,即主線程阻塞;如果設置爲yes,則不追加,
#並將數據寫入到緩衝區aof_rewrite_buf_blocks,等到子進程的fsync()執行完成後,通知主線程進行fsync();
#因爲存在緩衝區的數據沒有持久化到數據庫,這樣就有可能會丟失阻塞時間內的數據;
#因此,如果不允許主線程出現延時,則選擇yes;通常建議no;
no-appendfsync-on-rewrite no
#觸發重寫aof文件的條件:aof文件已經達到指定值(64M),且與上次AOF文件相比,已經增加了指定百分比(100%)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#redis啓動時,發現aof文件因系統原因出現不完整現象的處理設置;
#no,中斷redis進程;(用戶可以在redis未啓動時對aof執行:redis-check-aof修復文件)
#yes,提示用戶,繼續運行;
#注意,如果aof文件中間因爲不明原因出現問題,依然會退出;
#此配置是指在aof文件末尾沒有找到足夠的字符組成數據;
aof-load-truncated yes
#以RDB文件名稱爲前綴;同時,在進行持久化時,產生AOF文件,將會以RDB結構爲開頭,後續部分內容爲AOF結構;
#在恢復的時候,redis會優先讀取AOF文件(因爲默認AOF文件數據會更完整)進行恢復;
#這種設置,可以更快的持久化,更快的恢復,更小的AOF文件;默認爲yes;
#如果不開啓aof,此處開啓了也毫無意義;
aof-use-rdb-preamble yes
#lua腳本執行的最大時間,設置0,不做限制;單位s;
lua-time-limit 5000
在客戶端,可以通過命令來主動觸發AOF文件的重寫;
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
查看上次持久化時間
127.0.0.1:6379> LASTSAVE
(integer) 1324043588
RDB與AOF混用
由於這兩者都有自己的缺點:
RDB可能會丟失較長時間的數據;
AOF會導致持久化文件臃腫以及啓動數據庫變慢;
所以最好的方式是混合使用它們;
#混用的關鍵配置:
#以RDB文件名稱爲前綴;同時,在進行持久化時,產生AOF文件,將會以RDB結構爲開頭,後續部分內容爲AOF結構;
#在恢復的時候,redis會優先讀取AOF文件(因爲默認AOF文件數據會更完整)進行恢復;
#這種設置,可以更快的持久化,更快的恢復,更小的AOF文件;默認爲yes;
#如果不開啓aof,此處開啓了也毫無意義;
aof-use-rdb-preamble yes
擴充資料: