redis 數據備份持久化方案

本文連接：http://www.cnblogs.com/zhenghongxin/p/9050219.html

• 使用兩種備份方案

備份方案選擇RDB和AOF同時進行備份，必須打開AOF的持久化機制，除非能接受在故障環境下丟失幾分鐘的數據。

在redis重啓的時候，是優先經過AOF進行數據恢復的，由於AOF數據比較完整。

• RDB的生成策略

要修改的是該條命令：

save 60 10000

該條命令是60秒內，若是有1萬條命令執行，那麼就進行快照備份。這個值略大，能夠根據本身的業務量而定，能夠調小至1000。但也同時意味着，在一分鐘內，若是命令執

行了999條，且在最後一秒redis掛掉，該分鐘內的命令將會所有丟失。

注意不要用：redis-cli SHUTDOWN 這樣的方式去測試，這是一種安全退出的模式，redis會安全生成dump.rdb

它的工做流程：

（1）redis根據配置本身嘗試去生成rdb快照文件 （2）fork一個子進程出來 （3）子進程嘗試將數據dump到臨時的rdb快照文件中 （4）完成rdb快照文件的生成以後，就替換以前的舊的快照文件dump.rdb，每次生成一個新的快照，都會覆蓋以前的老快照

• AOF的生成策略

當AOF開啓以後，redis每次接收到一條寫命令，就會寫入日誌文件中，先寫入系統的 os cache中，而後隔一段時間再fsync一下。

 fsync的策略有三種：

always: 每次寫入一條數據，當即將這個數據對應的寫日誌fsync到磁盤上去，性能很是很是差，吞吐量很低; 
　　　　 若是說確保說redis裏的數據一條都不丟，那就只能這樣了

everysec: 每秒將os cache中的數據fsync到磁盤，這個最經常使用的，生產環境通常都這麼配置，性能很高，QPS仍是能夠上萬的

no：就是直接寫入os cache就無論了，讓linux自帶的機制去將數據刷入磁盤，這樣很不可控

所以咱們要配置爲everysec。

 接着配置兩條命令：

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

redis 2.4以前，還須要手動，開發一些定時任務腳本，經過BGREWRITEAOF命令去執行AOF rewrite，可是redis 2.4以後，會自動進行rewrite操做

也就是說在上一次AOF rewrite以後，日誌大小是128mb，接着再往裏面寫日誌，當總日誌大小增加的比例，超過了以前的100%，即達到256mb後，就會觸發rewrite操做。

注意，此時還要跟 auto-aof-rewrite-min-size 比較大小，256M 大於 64m，能夠觸發rewrite操做。這兩條命令，能夠根據業務進行調節大小，或者保持默認值

•  定時任務備份方案（重要）

並非說讓redis自動進行持久化備份就能夠的，而是要另開腳本，進行更細緻的備份。

1 ）每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh redis_rdb_copy_hourly.sh #!/bin/sh cur_date=`date +%Y%m%d%k` # 年月日時進行備份 rm -rf /usr/local/redis/snapshotting/$cur_date # 先刪除原有日期底下的備份目錄文件 mkdir /usr/local/redis/snapshotting/$cur_date # 建立該目錄 cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date #將快照備份 del_date=`date -d -48hour +%Y%m%d%k` # 48小時前的目錄文件名 rm -rf /usr/local/redis/snapshotting/$del_date # 刪除48小時前的目錄

 2 ）天天copy一次備份

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh redis_rdb_copy_daily.sh #!/bin/sh cur_date=`date +%Y%m%d` #年月日進行備份 rm -rf /usr/local/redis/snapshotting/$cur_date #先刪除原有的目錄 mkdir /usr/local/redis/snapshotting/$cur_date #建立該目錄 cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date //備份cp del_date=`date -d -1month +%Y%m%d` #僅保留近一個月的數據 rm -rf /usr/local/redis/snapshotting/$del_date #刪除

3）天天一次將全部數據上傳一次到遠程的雲服務器上去

 原理跟第2點同樣，只是否是用cp，而是用scp或rsync等命令將文件備份到遠程安全服務器

 以上只給了rdb的備份，aof的備份腳本基本一致。

•  數據恢復方案（重要）

 （1）若是是redis進程掛掉，那麼重啓redis進程便可，直接基於AOF日誌文件恢復數據

 （2）若是是redis進程所在機器掛掉，那麼重啓機器後，嘗試重啓redis進程，嘗試直接基於AOF日誌文件進行數據恢復

　　　若是AOF沒有破損，能夠直接基於AOF恢復的

　　　AOF append-only，順序寫入，若是AOF文件破損，那麼用redis-check-aof fix

 （3）若是redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼能夠嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復

　　   找到RDB最新的一份備份，小時級的備份能夠了，小時級的確定是最新的，copy到redis裏面去，就能夠恢復到某一個小時的數據 

 （4）若是當前機器上的全部RDB文件所有損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢復數據

恢復的過程：

（1）優先用appendonly.aof去恢復數據

（2）中止redis，關閉aof （爲何要關閉？若是不關閉，啓動redis後，redis會生成一份新的可能爲空的aof強行覆蓋目錄下的aof，致使恢復失敗）

（3）拷貝備份文件，重啓redis

（4）命令行修改redis配置，開啓aof （redis config set ）

-------------------------------------------------------------------------------------

AOF的重寫機制

隨着命令不斷寫入AOF，文件會愈來愈大，爲了解決這個問題，Redis引入AOF重寫機制壓縮文件體積。AOF文件重寫是把Rdis進程內的數據轉化爲寫命令同步到

新AOF文件的過程。

重寫後的AOF文件爲何能夠變小？有以下緣由：

（1）進程內已經超時的數據再也不寫入文件。

（2）舊的AOF文件含有無效命令，如del key一、hdel key二、srem keys、set a1十一、set a222等。重寫使用進程內數據直接生成，這樣新的AOF文件只保留最終數據的寫入命令。

（3）多條寫命令能夠合併爲一個，如：lpush list a、lpush list b、lpush list c能夠轉化爲：lpush list a b c。爲了防止單條命令過大形成客戶端緩衝區溢出，對於list、set、hash、zset等類型操做，以64個元素爲界拆分爲多條。

（4）AOF重寫下降了文件佔用空間，除此以外，另外一個目的是：更小的AOF文件能夠更快地被Redis加載。