-------------------------------------------------分割線-----------------------------------------------------redis
根據官網介紹,Redis持久化,有兩種形式,一種是RDB,另一種是AOF,默認狀況下RDB持久化是開啓的,那咱們分別來介紹兩種持久化的差別跟優缺點吧
- RDB持久化
- 什麼是RDB?
- 持久性以指定的時間間隔執行數據集的時間點快照
- RDB的優勢
- 由於是定時備份,能夠設置24小時內,RDB文件歸檔一次,保存30天,這樣出現問題,你能夠隨意恢復當時的數據
- 由於是定時備份,因此主線程不須要去作持久化的操做,子線程作備份操做就行
- RDB數據量比AOF更小,因此能更快速的啓動
- RDB的缺點
- 若是Redis忽然停機,可能會致使某個時間點最新的的數據丟失
- 爲了使用子進程在磁盤上保留RDB,RDB須要常常fork()。若是數據集很大,Fork()會很費時,而且可能致使Redis在幾毫秒內中止服務,或者若是數據集很是大而且CPU性能不佳,甚至會持續一秒。
介紹過,RDB後,咱們來講說RDB的具體操做吧
- 默認狀況下,RDB是開啓的,能夠查看redis.conf文件,能夠看到以下內容
- 上述: save v1 v2, v2個key有變化,則v1秒候持久化一次
- 而後咱們能夠看到 redis目錄下會有一個dump.rdb文件,那就是RDB持久化後的文件
- 若是咱們kill掉redis進程,而後重啓,可能會丟失最新寫入的數據,重啓候,會自動把dump.rdb的文件讀入Redis當中
- 定時持久化的策略能夠本身設定, save 60 100 表示,若是有100個key有變化,則60秒後進行持久化
須要注意一點的是,若是長時間沒有進行RDB持久化的話,當你觸發了修改多少個key後,多少時間候進行持久化,不會等多少時間,而是會立刻持久化一次,除非,在上一次持久化的時間間隔內,有這麼多key修改過,纔會進行間隔時間持久化,篇幅有限,讀者能夠本身測試安全
- AOF持久化
- 什麼是AOF?
- 持久性會記錄服務器接收到的每一個寫入操做,這些操做將在服務器啓動時再次寫入,重建原始數據集
- AOF的優勢
- AOF數據更全面,由於是追加每次寫入操做,就算服務忽然中止,也只會丟1S的數據
- 當Redis數據很大的時候,AOF可以自動重寫到一個新的文件內
- RDB的缺點
- AOF文件一般比相同數據集的等效RDB文件大
- AOF啓動恢復數據,會比RDB慢。
介紹過,AOF後,咱們來講說AOF的具體操做吧
- 默認狀況下,AOF是不開啓的,因此,須要咱們手動開啓 將 appendonly no 改爲 appendonly yes
- 而後重啓redis,添加k v,在redis根目錄下 就會發現 appendonly.aof 文件,就算添加了key,殺掉進程,也能恢復最新的數據
- 若是咱們只想要RDB的持久化,那麼修改redis.conf文件的appenonly 爲no就能夠了
- 若是咱們只想要AOF的持久化,那麼修改redis.conf文件的 save 後面變爲空就能夠了
- 若是咱們是要切換持久化方式,之前是RDB,想切換成AOF方式,那麼咱們須要這麼作
- 備份最新的dump.rdb文件,轉移到安全的地方
- 進入 redis-cli 執行以下命令
- config set appendonly yes
- config set save ""
- 這樣,咱們就能夠完成,在不重啓的狀況下,完成RDB->AOF持久化方式的切換
- 若是咱們一開始持久化的方式是AOF,要切換成RDB,咱們這麼操做
- 進入 redis-cli 執行以下命令
- config set appendonly no
- config set save second chang
- 等RDB持久化後,在 redis-cli 執行
- config set appendonly no
- 這樣,咱們就能夠完成,在不重啓的狀況下,完成AOF->RDB持久化的方式
下篇咱們介紹 Redis(五)Redis主從自動切換
到這,文章就結束了!服務器
以上,均爲本人測試而得出的結果,可能會有出入,或者錯誤,歡迎指正app
歡迎轉載,請註明出處跟做者,謝謝!性能