1. RDB

Redis DataBase

• 在指定的時(shí)間間隔內(nèi)，將內(nèi)存中的數(shù)據(jù)集的快照寫入磁盤；
• 默認(rèn)保存在/usr/local/bin中，文件名dump.rdb;

1.1 自動(dòng)備份

• redis是內(nèi)存數(shù)據(jù)庫(kù)，當(dāng)我們每次用完redis，關(guān)閉linux時(shí)，按道理來(lái)說(shuō)，內(nèi)存釋放，redis中的數(shù)據(jù)也會(huì)隨之消失
• 為什么我們?cè)俅螁?dòng)redis的時(shí)候，昨天的數(shù)據(jù)還在，并沒(méi)有消失呢？
• 正是因?yàn)?，每次關(guān)機(jī)時(shí)，redis會(huì)自動(dòng)將數(shù)據(jù)備份到一個(gè)文件中 ：/usr/local/bin/dump.rdb
• 接下來(lái)我們就來(lái)全方位的認(rèn)識(shí) 自動(dòng)備份機(jī)制

默認(rèn)的自動(dòng)備份策略不利于我們測(cè)試，所以修改redis.conf文件中的自動(dòng)備份策略

vim redis.conf
/SNAP  # 搜索
save 900 1   # 900秒內(nèi)，至少變更1次，才會(huì)自動(dòng)備份
save 120 10 # 120秒內(nèi)，至少變更10次，才會(huì)自動(dòng)備份
save 60 10000 # 60秒內(nèi)，至少變更10000次，才會(huì)自動(dòng)備份

當(dāng)然如果你只是用Redis的緩存功能，不需要持久化，那么你可以注釋掉所有的 save 行來(lái)停用保存功能。可以直接一個(gè)空字符串來(lái)實(shí)現(xiàn)停用：save “”

使用shutdown模擬關(guān)機(jī) ，關(guān)機(jī)之前和關(guān)機(jī)之后，對(duì)比dump.rdb文件的更新時(shí)間

注意：當(dāng)我們使用shutdown命令，redis會(huì)自動(dòng)將數(shù)據(jù)庫(kù)備份，所以，dump.rdb文件創(chuàng)建時(shí)間更新了

開機(jī)啟動(dòng)redis，我們要在120秒內(nèi)保存10條數(shù)據(jù)，再查看dump.rdb文件的更新時(shí)間（開兩個(gè)終端
窗口，方便查看）

120秒內(nèi)保存10條數(shù)據(jù)這一動(dòng)作觸發(fā)了備份指令，目前，dump.rdb文件中保存了10條數(shù)據(jù)，將
dump.rdb拷貝一份dump10.rdb，此時(shí)兩個(gè)文件中都保存10條數(shù)據(jù)

既然有數(shù)據(jù)已經(jīng)備份了，那我們就肆無(wú)忌憚的將數(shù)據(jù)全部刪除flushall，再次shutdown關(guān)機(jī)
再次啟動(dòng)redis，發(fā)現(xiàn)數(shù)據(jù)真的消失了，并沒(méi)有按照我們所想的 將dump.rdb文件中的內(nèi)容恢復(fù)到redis中。為什么？

因?yàn)椋?dāng)我們保存10條以上的數(shù)據(jù)時(shí)，數(shù)據(jù)備份起來(lái)了； 然后刪除數(shù)據(jù)庫(kù)，備份文件中的數(shù)據(jù)，也沒(méi)問(wèn)題；

但是，問(wèn)題出在shutdown上，這個(gè)命令一旦執(zhí)行，就會(huì)立刻備份，將刪除之后的空數(shù)據(jù)庫(kù)生成備份文件，將之前裝10條數(shù)據(jù)的備份文件覆蓋掉了。所以，就出現(xiàn)了上圖的結(jié)果。自動(dòng) 恢復(fù)失敗。

怎么解決這個(gè)問(wèn)題呢？要將備份文件再備份

• 將dump.rdb文件刪除，將dump10.rdb重命名為dump.rdb
• 啟動(dòng)redis服務(wù)，登錄redis，數(shù)據(jù)10條，全部恢復(fù)！

1.2 手動(dòng)備份

之前自動(dòng)備份，必須更改好多數(shù)據(jù)，例如上邊，我們改變了十多條數(shù)據(jù)，才會(huì)自動(dòng)備份；

現(xiàn)在，我只保存一條數(shù)據(jù)，就想立刻備份，應(yīng)該怎么做？

每次操作完成，執(zhí)行命令 save 就會(huì)立刻備份

1.3 與RDB相關(guān)的配置

• stop-writes-on-bgsave-error：進(jìn)水口和出水口，出水口發(fā)生故障與否
  • yes：當(dāng)后臺(tái)備份時(shí)候反生錯(cuò)誤，前臺(tái)停止寫入
  • no：不管死活，就是往里懟
• rdbcompression：對(duì)于存儲(chǔ)到磁盤中的快照，是否啟動(dòng)LZF壓縮算法，一般都會(huì)啟動(dòng)，因?yàn)檫@點(diǎn)性能，多買一臺(tái)電腦，完全搞定N個(gè)來(lái)回了。
  • yes：?jiǎn)?dòng)
  • no：不啟動(dòng)（不想消耗CPU資源，可關(guān)閉）
• rdbchecksum：在存儲(chǔ)快照后，是否啟動(dòng)CRC64算法進(jìn)行數(shù)據(jù)校驗(yàn)；
  • 開啟后，大約增加10%左右的CPU消耗；
  • 如果希望獲得最大的性能提升，可以選擇關(guān)閉
• dbfilename：快照備份文件名字
• dir：快照備份文件保存的目錄，默認(rèn)為當(dāng)前目錄

優(yōu)勢(shì)and劣勢(shì)

• 優(yōu)：適合大規(guī)模數(shù)據(jù)恢復(fù)，對(duì)數(shù)據(jù)完整性和一致行要求不高；
• 劣：一定間隔備份一次，意外down掉，就失去最后一次快照的所有修改

2. AOF

Append Only File

• 以日志的形式記錄每個(gè)寫操作；
• 將redis執(zhí)行過(guò)的寫指令全部記錄下來(lái)（讀操作不記錄）；
• 只許追加文件，不可以改寫文件；
• redis在啟動(dòng)之初會(huì)讀取該文件從頭到尾執(zhí)行一遍，這樣來(lái)重新構(gòu)建數(shù)據(jù)；

2.1 開啟AOF

為了避免失誤，最好將redis.conf總配置文件備份一下，然后再修改內(nèi)容如下：

appendonly yes
appendfilename appendonly.aof

重新啟動(dòng)redis，以新配置文件啟動(dòng)

redis-server /usr/local/redis5.0.4/redis.conf

連接redis，加數(shù)據(jù)，刪庫(kù)，退出

查看當(dāng)前文件夾多一個(gè)aof文件，看看文件中的內(nèi)容,保存的都是 寫 操作

文件中最后一句要?jiǎng)h除，否則數(shù)據(jù)恢復(fù)不了編輯這個(gè)文件，最后要 :wq! 強(qiáng)制執(zhí)行

只需要重新連接，數(shù)據(jù)恢復(fù)成功

2.2 共存？誰(shuí)優(yōu)先？

我們查看redis.conf文件，AOF和RDB兩種備份策略可以同時(shí)開啟，那系統(tǒng)會(huì)怎樣選擇？

• 動(dòng)手試試，編輯appendonly.aof，胡搞亂碼，保存退出
• 啟動(dòng)redis 失敗，所以是AOF優(yōu)先載入來(lái)恢復(fù)原始數(shù)據(jù)！因?yàn)锳OF比RDB數(shù)據(jù)保存的完整性更高！
• 修復(fù)AOF文件，殺光不符合redis語(yǔ)法規(guī)范的代碼

reids-check-aof --fix appendonly.aof

2.3 與AOF相關(guān)的配置

• appendonly：開啟aof模式
• appendfilename：aof的文件名字，最好別改！
• appendfsync：追寫策略
  • always：每次數(shù)據(jù)變更，就會(huì)立即記錄到磁盤，性能較差，但數(shù)據(jù)完整性好
  • everysec：默認(rèn)設(shè)置，異步操作，每秒記錄，如果一秒內(nèi)宕機(jī)，會(huì)有數(shù)據(jù)丟失
  • no：不追寫
• no-appendfsync-on-rewrite：重寫時(shí)是否運(yùn)用Appendfsync追寫策略；用默認(rèn)no即可，保證數(shù)據(jù)安全性。
  • AOF采用文件追加的方式，文件會(huì)越來(lái)越大，為了解決這個(gè)問(wèn)題，增加了重寫機(jī)制，redis會(huì)自動(dòng)記錄上一次AOF文件的大小，當(dāng)AOF文件大小達(dá)到預(yù)先設(shè)定的大小時(shí)，redis就會(huì)啟動(dòng)AOF文件
• 進(jìn)行內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集合
• auto-aof-rewrite-percentage：如果AOF文件大小已經(jīng)超過(guò)原來(lái)的100%，也就是一倍，才重寫壓縮
• auto-aof-rewrite-min-size：如果AOF文件已經(jīng)超過(guò)了64mb，才重寫壓縮

3 總結(jié)

• RDB：只用作后備用途，建議15分鐘備份一次就好
• AOF：
  • 在最惡劣的情況下，也只丟失不超過(guò)2秒的數(shù)據(jù)，數(shù)據(jù)完整性比較高，但代價(jià)太大，會(huì)帶來(lái)持續(xù)的IO
  • 對(duì)硬盤的大小要求也高，默認(rèn)64mb太小了，企業(yè)級(jí)最少都是5G以上；
  • master/slave才是新浪微博的選擇

到此這篇關(guān)于淺談Redis持久化的幾種方式的文章就介紹到這了,更多相關(guān)Redis持久化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論