redis緩存架構詳解（四）-redis數據備份方案及數據恢復容災演練

3. 數據備份方案及數據恢復容災演練

以上對redis的持久化的原理和操作進行了講解，但是在企業中，持久化到底是怎麼去用得呢？

企業級的數據備份和各種災難下的數據恢復，是怎麼做得呢？本節將對redis企業級數據備份方案，以及各種踩坑的數據恢復進行容災演示。

3.1. 持久化的配置策略

在企業中，RDB的生成策略，用默認的也可以：

save 60 10000 ：1分鐘內有10000個key值發生變化，就生成RDB，這個根據應用和業務的數據量來決定。

如果你希望RDB丟失數據少，如RDB最多丟1分鐘的數據，那麼儘量就是每隔1分鐘都生成一個快照。在低峯期，數據量很少，時間上可以設置久一點。

AOF一定要打開，fsync，everysec

auto-aof-rewrite-percentage 100: 就是當前AOF大小膨脹到超過上次100%，上次的兩倍
auto-aof-rewrite-min-size 64mb: 根據你的數據量來定，16mb，32mb

3.2. 數據備份方案

RDB非常適合做冷備，每次生成之後，就不會再有修改了。

數據備份方案

1、寫crontab定時調度腳本去做數據備份；
2、每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份；
3、每天都保留一份當日的rdb的備份，到一個目錄中去，僅僅保留最近1個月的備份；
4、每次copy備份的時候，都把太舊的備份給刪了；
5、每天晚上將當前服務器上所有的數據備份，發送一份到遠程的雲服務上去。

使用crontab定時調度腳本做數據備份。

crontab 格式：

*　　*　　*　　*　　*　　command
分　 時　 日　 月　 周　  命令
第1列表示分鐘1～59 每分鐘用*或者 */1表示
第2列表示小時1～23（0表示0點）
第3列表示日期1～31
第4列表示月份1～12
第5列標識號星期0～6（0表示星期天）
第6列要運行的命令

Crontab 選項:

crontab –e : 修改 crontab 文件. 如果文件不存在會自動創建。 
crontab –l : 顯示 crontab 文件。 
crontab -r : 刪除 crontab 文件。
crontab -ir : 刪除 crontab 文件前提醒用戶。

示例1：每小時copy一次備份，刪除48小時前的數據，腳本如下：

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`
rm -rf /usr/local/redis/snapshotting/$del_date

將腳本加入到crontab定時調度任務中

crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

示例2：每天copy一次備份，刪除上一個月今天的數據，腳本如下：

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

del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

將腳本加入到crontab定時調度任務中

crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

每天一次將所有數據上傳一次到遠程的雲服務器上去

3.3. 數據恢復方案

3.3.1.常見的幾種數據恢復方案

1、如果是redis進程掛掉

如果是redis進程掛掉，那麼重啓redis進程，只要開啓了AOF持久化機制，redis會直接基於AOF日誌文件恢復數據。

我們已經在上文AOF數據恢復部分，對AOF日誌文件恢復數據，使用fsync everysec 策略進行了演示，演示結果最多丟失一秒的數。

2、如果是redis進程所在機器掛掉

如果是redis進程所在機器掛掉，那麼重啓機器後，嘗試重啓redis進程，如果AOF沒有破損，也是可以直接基於AOF日誌文件進行數據恢復。

AOF append-only，順序寫入，如果AOF文件破損，那麼用redis-check-aof fix 進行文件修復。

3、如果redis當前最新的AOF和RDB文件出現了丟失/損壞

如果redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼可以嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復。

當前最新的AOF和RDB文件都出現了丟失/損壞到無法恢復，一般不是機器的故障，大部分是人爲因素。

3.3.2. 容災演練：AOF+RDB兩種方式進行數據恢復

原理：appendonly.aof + dump.rdb，優先用appendonly.aof去恢復數據，

模擬實驗：將redis備份文件 /var/redis/6379 下的文件給刪除，然後使用備份文件進行恢復。

找到RDB最新的一份備份，copy到redis裏面去，查看數據恢復情況。

情況1：重啓redis後，redis自動生成空的appendonly.aof文件，而我們copy過來的dump.rdb是有數據，此時，redis數據沒有恢復。

分析：因爲redis恢復數據，首先是基於aof文件進行恢復，redis啓動的時候，自動重新基於內存的數據，生成一份最新的appendonly.aof，如果appendonly.aof不存在，就會生成空的appendonly.aof文件，然後redis基於空的appendonly.aof文件進行數據恢復，不會用到我們之前的冷備份文件dump.rdb,所以，數據恢復失敗。

情況2：在停止redis之後，先刪除appendonly.aof，然後將我們的dump.rdb拷貝過去，然後再重啓redis，數據恢復失敗。

分析：雖然刪除了appendonly.aof，但是因爲打開了aof持久化，redis就一定會優先基於aof去恢復，即使文件不在，那就創建一個新的空的aof文件

情況3：停止redis，暫時在配置中關閉aof，然後拷貝一份rdb過來，再重啓redis，數據能不能恢復過來，可以恢復過來。

情況4：:再關掉redis，手動修改配置文件，打開aof，再重啓redis，數據又沒了，redis又生成空的aof文件，所有數據又沒了。

3.3.3. 完美的恢復數據方法

在數據安全丟失的情況下，基於rdb冷備，如何完美的恢復數據，同時還保持aof和rdb的雙開呢？

正確操作步驟：

• 停止redis；
• 關閉aof；
• 拷貝rdb備份；
• 重啓redis，確認數據恢復；
• 直接在命令行熱修改redis配置，打開aof，這時redis就會將內存中的數據對應的日誌，寫入aof文件中。

此時aof和rdb兩份數據文件的數據就同步了

redis 熱修改配置參數命令：

root@cache01 6379]# redis-cli
127.0.0.1:6379>config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379>config set appendonly yes
OK
127.0.0.1:6379>

注意：

redis 的 config set 熱修改配置參數，可能配置文件中的實際的參數沒有被持久化的修改，當內存中的數據同步到aof文件後，再次停止redis，手動修改配置文件，打開aof的命令，再次重啓redis。

3.3.4. 當前服務器上的所有RDB全部損壞的數據恢復方案

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

3.3.5. 重大數據錯誤，導致數據污染解決方案

 如果是發現有重大的數據錯誤，比如某個小時上線的程序一下子將數據全部污染了，數據全錯了，那麼可以選擇某個更早的時間點，對數據進行恢復。

舉個例子，12點上線了代碼，發現代碼有bug，導致代碼生成的所有錯誤的緩存數據都寫入了redis，那怎麼辦呢？我們可以找到一份11點的rdb的冷備，然後按照上面的步驟，去恢復到11點的數據，就可以了。