Redis資料持久化

來源:互聯網
上載者:User

Redis資料持久化

總的來說有兩種持久化方案:RDB和AOF
RDB方式按照一定的時間間隔對資料集建立基於時間點的快照。
AOF方式記錄Server收到的寫操作到記錄檔,在Server重啟時通過回放這些寫操作來重建資料集。該方式類似於MySQL中基於語句格式的binlog。當日誌變大時Redis可在後台重寫日誌。
若僅期望資料在Server運行期間存在則可禁用兩種持久化方案。在同一Redis執行個體中同時開啟AOF和RDB方式的資料持久化方案也是可以的。該情況下Redis重啟時AOF檔案將用於重建未經處理資料集,因為叫RDB方式而言,AOF方式能最大限度的保證資料完整性。

兩鐘方案各自的優缺點
RDB優點
RDB是Redis資料集的基於時間點的緊湊的副本,非常適合於備份情境。比如每個小時對RDB檔案做一次小的歸檔,每天對RDB檔案做一次大的歸檔,每月對RDB檔案做一次更大的歸檔。這樣可以在必要的時刻選擇不同的備份版本進行資料恢複。
由於是一個緊湊的檔案,易於傳輸到遠端資料中心或Amazon S3,因此RDB非常適合於災難恢複。
RDB方式的開銷較低,在該種方式下Redis父進程所要做的僅是開闢一個子進程來做剩下的事情。
與AOF相比RDB在資料集較大時能夠以更快的速度恢複。

RDB缺點
若需在Redis停止工作時(例如意外斷電)儘可能保證資料不丟失,那麼RDB不是最好的方案。例如,通常會每隔5分鐘或者更長的時間來建立一次快照,如若Redis沒有被正確的關閉就可能丟失最近幾分鐘的資料。
RDB方式需經常調用fork()函數以開闢子進程來實現持久化。在資料集較大、CPU效能不夠強悍時fork()調用可能很耗時從而會導致Redis在幾毫秒甚至一秒中的時間內不能服務clients。AOF也需要調用fork()但卻可以在不影響資料持久性的條件下調整重寫logs的頻率。

AOF優點
使用AOF方式時Redis持久化更可靠:有三種不同的fsync策略供選擇:no fsync at all、fsync every second、 fsync at every query。預設為fsync every second此時的寫效能仍然很好,且最壞的情況下可能丟失一秒鐘的寫操作。
AOF日誌是append only方式產生的日誌,因此不存在隨機訪問問題以及意外斷電時造成的損毀問題。即使出於某種原因(如磁碟滿)日誌以一個寫了一半的命令結尾,仍可以使用redis-check-aof工具快速進行修複。
當AOF日誌逐漸層大後,Redis可在後台自動的重寫AOF日誌。當Redis在繼續追加舊的AOF記錄檔時重寫日誌是完全安全的。Redis利用可以重建當前資料集的最少的命令產生一個全新的記錄檔,一旦新的記錄檔建立完成Redis開始向新的記錄檔追加日誌。
AOF日誌的格式易於理解易於解析。這在某些情境非常有用。比如,不下心使用FLUSHALL命令清空了所有的資料,同時AOF日誌沒有發生重寫操作,那麼就可以簡單的通過停止Redis Server移除日誌中的最後一條FLUSHALL命令重啟Redis Server來恢複資料。

AOF缺點
同樣的資料集AOF檔案要比RDB檔案大很多。
根據使用的fsync方式不同AOF可能比RDB慢很多。在使用no fsync at all時AOF的效能基本與RDB持平,在使用fsync every second時效能有所下降但仍然較高,在使用 fsync at every query時效能較低。然而RDB方式卻能在高負載的情況下保證延遲儘可能小。
一些特定的命令可能存在bug從而導致重載AOF日誌時不能重建出完全一樣的資料集。這樣的bugs非常非常罕見,已經通過測試套件做了充分的測試。這種類型的bugs對於RDB來說幾乎是不可能的。說的更清晰一點:Redis AOF增量的更新既存的狀態而RDB快照每次都重新建立,從概念上講RDB方式更加健壯。然而,需要注意兩點:每次AOF日誌被Redis重寫的時候日誌由包含資料集的實際資料重建,與追加AOF檔案的方式相比該方式能有效減少bugs出現的機率;現實的應用情境中還未收到過任何使用者關於AOF損毀的報告。

如何選擇持久化方式?
取決於具體的應用情境,通常,兩種方式可同時使用。若比較關心資料但仍能忍受幾分鐘的資料丟失,那麼可以簡單的使用RDB方式。有許多使用者只使用AOF方式,不建議這種做法,一方面以一定時間間隔建立RDB快照是建立資料備份並快速恢複資料的極好的辦法,一方面可以避免AOF方式可能存在的bugs。出於上述原因,將來可能將AOF和RDB方式合二為一。

RDB持久化設定
預設情況下Redis在磁碟上建立二進位格式的命名為dump.rdb的資料快照。可以通過設定檔配置每隔N秒且資料集上至少有M個變化時建立快照、是否對資料進行壓縮、快照名稱、存放快照的工作目錄。redis 2.4.10的預設配置如下:

#900秒後且至少1個key發生變化時建立快照
save 900 1
#300秒後且至少10個key發生變化時建立快照
save 300 10
#60秒後且至少10000個key發生變化時建立快照
save 60 10000
#可通過注釋所有save開頭的行來禁用RDB持久化
#建立快照時對資料進行壓縮
rdbcompression yes
#快照名稱
dbfilename dump.rdb
#存放快照的目錄(AOF檔案也會被存放在此目錄)
dir /var/lib/redis/

關於配置參數的詳細資料可參閱redis.conf中的說明。

除了通過設定檔進行設定外也可以通過手工執行命令來建立快照
SAVE命令執行一個同步操作,以RDB檔案的方式儲存執行個體中所有資料的快照。一般不在生產環境直接使用SAVE 命令,因為會阻塞所有的用戶端的請求,可以使用BGSAVE命令代替。BGSAVE後台建立資料快照。命名執行結果的狀態代碼會立即返回。Redis開闢一個子進程,父進程繼續相應用戶端請求,子進程儲存DB到磁碟後退出。用戶端可通過執行LASTSAVE命令檢查操作是否成功。

建立RDB快照的工作流程
Redis需dump資料集到磁碟時會執行下列過程:
Redis forks一個子進程;
子進程寫資料集到臨時的RDB檔案;
子進程寫完新的RDB檔案後替換舊的RDB檔案。
該方式使Redis可以利用copy-on-write機制的好處。

Ubuntu 14.04下Redis安裝及簡單測試

Redis叢集明細文檔

Ubuntu 12.10下安裝Redis(圖文詳解)+ Jedis串連Redis

Redis系列-安裝部署維護篇

CentOS 6.3安裝Redis

Redis安裝部署學習筆記

Redis設定檔redis.conf 詳解

更多詳情見請繼續閱讀下一頁的精彩內容:

  • 1
  • 2
  • 下一頁

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.