04.簡單了解一下Redis企業級數據備份方案

2020 年 8 月 29 日
筆記
Redis

一、企業級的持久化的配置策略

（1）每隔1分鐘去檢查如果超過10000個可以變更，則生成一個快照。RDB最多丟1分鐘的數據。

save 60 10000

（2）AOF一定要打開，fsync，everysec

#就是當前AOF大小膨脹到超過上次100%，上次的兩倍
auto-aof-rewrite-percentage 100
#最小觸發size
auto-aof-rewrite-min-size 64mb

二、企業級的數據備份方案

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

數據備份方案

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

每小時copy一次備份，刪除48小時前的數據

crontab -e

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

每天copy一次備份

crontab -e

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

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

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

三、數據恢復方案

（1）如果是redis進程掛掉，那麼重啟redis進程即可，直接基於AOF日誌文件恢複數據
（2）如果是redis進程所在機器掛掉，那麼重啟機器後，嘗試重啟redis進程，嘗試直接基於AOF日誌文件進行數據恢復
AOF append-only，順序寫入，如果AOF文件破損，那麼用redis-check-aof fix
（3）如果redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼可以嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復
（4）如果當前機器上的所有RDB文件全部損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢複數據
（5）如果是發現有重大的數據錯誤，比如某個小時上線的程式一下子將數據全部污染了，數據全錯了，那麼可以選擇某個更早的時間點，對數據進行恢復

舉個例子，12點上線了程式碼，發現程式碼有bug，導致程式碼生成的所有的快取數據，寫入redis，全部錯了
找到一份11點的rdb的冷備，然後按照上面的步驟，去恢復到11點的數據，不就可以了嗎

四、容災演練

場景：

我們希望redis數據恢復到某一個時間點，所以選擇那個時間點的RDB文件進行恢復，我們拷貝RDB到伺服器中。把原來的aof文件刪掉。
注意：我們此時使用的是混合持久化機制。會優先用AOF文件去恢複數據，但是我們發現redis自動生成的appendonly.aof是沒有數據的，而我們拷貝的dump.rdb是有數據的。

錯誤操作

edis啟動，會自動生成一個空的AOF文件，並使用這個空的AOF恢複數據，又自動重新基於記憶體的數據生成了一份最新的空的rdb快照，覆蓋掉了我們有數據的拷貝過去的那份dump.rdb

原因分析

雖然你刪除了appendonly.aof，但是因為打開了aof持久化，redis啟動就一定會優先基於aof去恢復，即使文件不在，那就創建一個新的空的aof文件，導致redis恢復後又是空的，又生成了一個空的RDB文件，結果數據恢復失敗了。

調整操作：

停止redis，應該先暫時在配置中關閉aof，然後拷貝一份rdb過來，再重啟redis，數據就會使用RDB進行數據恢復，可以恢復過來，這一步是對的
如果此時腦子一熱，再關掉redis，手動修改配置文件，打開aof，再重啟redis，數據又沒了，空的aof文件，所有數據又沒了。

最終正確操作

在數據安全丟失的情況下，基於rdb冷備如何完美的恢複數據，同時還保持aof和rdb的雙開
（1）停止redis，配置關閉aof，拷貝rdb備份，重啟redis，確認數據恢復，直接在命令行熱修改redis配置，打開aof，這個redis就會將記憶體中的數據對應的日誌，寫入aof文件中。此時aof和rdb兩份數據文件的數據就同步了

#使用命令打開AOF
redis-cli config set appendonly yes

（2）redis config set熱修改配置參數，可是配置文件中的實際的參數沒有被持久化的修改，再次停止redis，手動修改配置文件，打開aof的命令，再次重啟redis，完美！

hi~我是Mirror，一個為了自由安逸的未來而不斷前進的的程式設計師。
如果你覺得文章對你有一點點幫助，一個小小贊，便是對我的認可，如果有不足之處，也歡迎各位指正。

Tags: Redis