04.簡單瞭解一下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，一個為了自由安逸的未來而不斷前進的的程式設計師。
如果你覺得文章對你有一點點幫助，一個小小贊，便是對我的認可，如果有不足之處，也歡迎各位指正。