一、持久化配置

RBD和AOF建議同時打開（Redis4.0之后支持）
RDB做冷備，AOF做資料恢復（資料更可靠）
RDB采取默認配置即可，AOF推薦采取everysec每秒策略

AOF和RDB還不懂的，請轉移到如下幾篇：

看完這篇還不懂Redis的RDB持久化，你們來打我！

天天在用Redis，那你對Redis的AOF持久化到底了解多少呢？

二、資料備份方案

1、需求

我們需要定時備份rdb檔案來做冷備，為什么？不是有aof和rbd了嗎為什么還要單獨寫定時任務去備份？因為Redis的aof和rdb是僅僅有一個最新的，比如誰手賤再Redis宕機的時候執行rm -rf aof/rdb了，那不就GG了嗎？或者rdb/aof檔案損壞了等不可預期的情況，所以我們需要單獨備份rdb檔案以防萬一，

為什么不定時備份aof而是rdb？定時備份aof沒意義呀，定時本身就是冷備份，不是實時的，rdb檔案又小恢復又快，她哪里不香？

2、方案

寫crontab定時調度腳本去做資料備份，
每小時都copy一份redis的rdb檔案到一個其他目錄中，這個目錄里的rdb檔案僅僅保留48小時內的，也就是每小時都做備份，保留2天內的rdb，只保留48個rdb，
每天0點0分copy一份redis的rdb檔案到一個其他目錄中，這個保留一個月的，也就是按天備份，
每天半夜找個時間將當前服務上的所有rdb備份都上傳到云服務上，

3、實作

3.1、按小時

每小時copy一次備份，洗掉48小時前的資料，

crontab -e
# 每小時都執行/usr/local/redis/copy/redis_rdb_copy_hourly.sh腳本
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh


# redis_rdb_copy_hourly.sh腳本的內容如下：

#!/bin/sh 
# +%Y%m%d%k == 年月日時
cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/rdb/$cur_date
mkdir /usr/local/redis/rdb/$cur_date
# 拷貝rdb到目錄
cp /var/redis/6379/dump.rdb /usr/local/redis/rdb/$cur_date
# date -d -48hour +%Y%m%d%k == 48小時前的日期，比如今天2020060214，這個結果就是2020053114
del_date=`date -d -48hour +%Y%m%d%k`
# 洗掉48小時之前的目錄
rm -rf /usr/local/redis/rdb/$del_date

3.2、按天

每天copy一次備份，洗掉一個月前的資料，

crontab -e
# 每天0點0分開始執行/usr/local/redis/copy/redis_rdb_copy_daily.sh腳本
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/rdb/$cur_date
mkdir /usr/local/redis/rdb/$cur_date
# 拷貝rdb到目錄
cp /var/redis/6379/dump.rdb /usr/local/redis/rdb/$cur_date

# 獲取一個月前的時間，比如今天是20200602，那么del_date就是20200502
del_date=`date -d -1month +%Y%m%d`
# 洗掉一個月前的資料
rm -rf /usr/local/redis/rdb/$del_date

3.3、傳到云

沒法演示，最終目的就是磁盤備份完上傳到云，云保留多少天等策略自己看需求，

三、資料恢復方案

1、redis掛了

如果僅僅是redis行程掛了，那么直接重啟redis行程即可，Redis會按照持久化配置直接基于持久化檔案進行恢復資料，

如果有AOF則按照AOF，AOF和RDB一起開的話也走AOF，

2、持久化檔案丟了

如果持久化檔案（rdb/aof）損壞了，或者直接丟失了，那么就要采取我們上面所做的rdb備份來進行恢復了，

不要腦子一熱想著很簡單，就以為直接把rdb拖過來重啟redis行程就完事了，這種想法有很多問題，慢慢道來，

2.1、問題

問題一：直接把備份的rdb扔到redis持久化目錄下然后重啟redis不行的原因在于：redis是按照先aof后rdb進行恢復的，所以都是開啟aof的，redis啟動后會重新生成新的aof檔案，里面是空的，所以不會進行任何資料恢復，也就是說雖然你把rdb丟給redis了，但是redis會按照aof來恢復，而aof是redis啟動的時候新生成的空檔案，所以不會有任何資料進行恢復，

問題二：那么我們把rdb檔案丟給redis后，先將redis的aof關閉再啟動redis行程不就能按照rdb來進行恢復了嗎？是這樣的，沒毛病！但是新的問題來了，我們aof肯定要開的，aof對資料保障更可靠，那什么我們按照rdb檔案恢復完后再修改redis組態檔開啟aof然后重啟redis行程不就得了嘛？大哥…你打開aof然后重啟redis，這時候redis又會生成一個空的aof檔案，這時候恢復的時候又是啥資料都沒了，

因為資料是存到記憶體里，你重啟后肯定沒了，需要持久化檔案來恢復，這時候aof是空的，我恢復個雞毛啊，

2.2、具體方案

可能有人想到方案了，但是耐心看完，看看我的文采如何，

我不管你是持久化檔案丟了還是壞了，我都先rm -rf * 給他刪了，

停止redis行程
洗掉壞掉的rdb和aof持久化檔案，
修改組態檔關閉redis的aof持久化，
找到最新備份的rdb檔案扔到redis的持久化目錄里，（這里最新的肯定是按照小時備份的最后一個）
啟動Redis行程
執行set appendonly yes動態打開aof持久化，

也就是說打開aof的操作不是修改組態檔然后重啟，而是先熱修改讓他生成aof，這次生成肯定是會帶著記憶體中完整的資料的，然后再修改組態檔重啟，

等aof檔案生成后再修改redis組態檔打開aof，
重啟redis行程，
完美收官，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/173491.html

標籤：Java

上一篇：MyBatis整合雙資料源

下一篇：Java Web系列之JDBC

Redis企業級資料備份與恢復方案