Redis高併發5-redis數據持久化之企業應用

到這裏爲止，其實仍是停留在簡單學習知識的程度，學會了redis的持久化的原理和操做，可是在企業中，持久化究竟是怎麼去用得呢？

企業級的數據備份和各類災難下的數據恢復，是怎麼作得呢？

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

在企業中，RDB的生成策略，用默認的也差很少

save 60 10000：若是你但願儘量確保說，RDB最多丟1分鐘的數據，那麼儘可能就是每隔1分鐘都生成一個快照，低峯期，數據量不多，也不必

10000->生成RDB，1000->RDB，這個根據你本身的應用和業務的數據量，你本身去決定

AOF必定要打開，fsync，everysec

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

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

RDB很是適合作冷備，每次生成以後，就不會再有修改了

數據備份方案

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

/usr/local/redis

每小時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日誌文件恢復數據

不演示了，在AOF數據恢復那一塊，演示了，fsync everysec，最多就丟一秒的數

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

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

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

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

當前最新的AOF和RDB文件都出現了丟失/損壞到沒法恢復，通常不是機器的故障，人爲

大數據系統，hadoop，有人不當心就把hadoop中存儲的大量的數據文件對應的目錄，rm -rf一下，我朋友的一個小公司，運維不太靠譜，權限也弄的不太好

/var/redis/6379下的文件給刪除了

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

容災演練

appendonly.aof + dump.rdb，優先用appendonly.aof去恢復數據，可是咱們發現redis自動生成的appendonly.aof是沒有數據的

而後咱們本身的dump.rdb是有數據的，可是明顯沒用咱們的數據

redis啓動的時候，自動從新基於內存的數據，生成了一份最新的rdb快照，直接用空的數據，覆蓋掉了咱們有數據的，拷貝過去的那份dump.rdb

你中止redis以後，其實應該先刪除appendonly.aof，而後將咱們的dump.rdb拷貝過去，而後再重啓redis

很簡單，就是雖然你刪除了appendonly.aof，可是由於打開了aof持久化，redis就必定會優先基於aof去恢復，即便文件不在，那就建立一個新的空的aof文件

中止redis，暫時在配置中關閉aof，而後拷貝一份rdb過來，再重啓redis，數據能不能恢復過來，能夠恢復過來

腦子一熱，再關掉redis，手動修改配置文件，打開aof，再重啓redis，數據又沒了，空的aof文件，全部數據又沒了

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

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

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

redis config set熱修改配置參數，可能配置文件中的實際的參數沒有被持久化的修改，再次中止redis，手動修改配置文件，打開aof的命令，再次重啓redis

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

（5）若是是發現有重大的數據錯誤，好比某個小時上線的程序一會兒將數據所有污染了，數據全錯了，那麼能夠選擇某個更早的時間點，對數據進行恢復

舉個例子，12點上線了代碼，發現代碼有bug，致使代碼生成的全部的緩存數據，寫入redis，所有錯了

找到一份11點的rdb的冷備，而後按照上面的步驟，去恢復到11點的數據，不就能夠了嗎