Redis的持久化有2種方式1快照2是日志
- 持久化: 即把數據存儲於斷電后不會丟失的設備中,通常是硬盤.
常見的持久化方式:
- 主從:通過從服務器保存和持久化,如mongoDB的replication sets配置
- 日志:操作生成相關日志,並通過日志來恢復數據couchDB對於數據內容,不修改,只追加,則文件本身就是日志,不會丟失數據.
1、Rdb快照
rdb的工作原理: 實際上就是內存快照的形式。
每隔N分鍾或N次寫操作后, 從內存dump數據形成rdb文件,壓縮放在備份目錄
注:紅色部分可通過參數來配置
配置選項
save 900 1 // 900內,有1條寫入,則產生快照 save 300 1000 // 如果300秒內有1000次寫入,則產生快照 save 60 10000 // 如果60秒內有10000次寫入,則產生快照
(這3個選項都屏蔽,則rdb禁用) 理解的話可以倒着向上看
stop-writes-on-bgsave-error yes // 后台備份進程出錯時,主進程停不停止寫入? 主進程不停止 容易造成數據不一致 rdbcompression yes // 導出的rdb文件是否壓縮 如果rdb的大小很大的話建議這么做 Rdbchecksum yes // 導入rbd恢復時數據時,要不要檢驗rdb的完整性 驗證版本是不是一致 dbfilename dump.rdb //導出來的rdb文件名 dir ./ //rdb的放置路徑
在2個保存點之間,斷電,將會丟失1-N分鍾的數據 ,對於商業上面的應用，丟失的數據就是個disaster。 但是這個方式下 數據恢復的比較快。 建議使用 rdb 跟 aof 配合使用。
出於對持久化的更精細要求,redis增添了aof方式 append only file
2、Aof
1:每個命令重寫一次aof? 是 當然還有重寫規則 aof文件過大的話 ，觸發重寫，gbwrite 。
2:某key操作100次,產生100行記錄,aof文件會很大,怎么解決?
配置 aof 主要記錄執行的命令 aof文件的路徑直接修改 跟 rdb不一樣 rdb 修改有單獨的配置選項：dir選項。
appendonly no // 是否打開aof日志功能 aof跟 rdb都打開的情況下 appendfsync always // 每1個命令,都立即同步到aof. 安全,速度慢 appendfsync everysec // 折衷方案,每秒寫1次 appendfsync no // 寫入工作交給操作系統,由操作系統判斷緩沖區大小,統一寫入到aof. 同步頻率低,速度快,
no-appendfsync-on-rewrite yes: // 正在導出rdb快照的過程中,要不要停止同步aof auto-aof-rewrite-percentage 100 //aof文件大小比起上次重寫時的大小,增長率100%時,重寫 缺點 剛開始的時候重復重寫多次 auto-aof-rewrite-min-size 64mb //aof文件,至少超過64M時,重寫
配置好以上文件之后測試使用 redis-benchmark -n 10000 表示 執行請求10000次，執行ls 發現出現 rdb 跟 aof文件。
appendonly.aof dump.rdb
3、注意的事項
注: 在dump rdb過程中,aof如果停止同步,會不會丟失?
答: 不會,所有的操作緩存在內存的隊列里, dump完成后,統一操作.
注: aof重寫是指什么?
答: aof重寫是指把內存中的數據,逆化成命令,寫入到.aof日志里.
以解決aof日志過大的問題.
問: 如果rdb文件,和aof文件都存在,優先用誰來恢復數據?
答: aof
問: 2種是否可以同時用?
答: 可以,而且推薦這么做
問: 恢復時rdb和aof哪個恢復的快
答: rdb快,因為其是數據的內存映射,直接載入到內存,而aof是命令,需要逐條執行