本文鏈接：http://www.cnblogs.com/zhenghongxin/p/9050219.html 使用兩種備份方案 備份方案選擇RDB和AOF同時進行備份，必須打開AOF的持久化機制，除非能接受在故障環境下丟失幾分鐘的數據。 在redis重啟的時候，是優先通過AOF進行數據恢復的，因為 ...
本文鏈接：http://www.cnblogs.com/zhenghongxin/p/9050219.html
- 使用兩種備份方案
備份方案選擇RDB和AOF同時進行備份，必須打開AOF的持久化機制，除非能接受在故障環境下丟失幾分鐘的數據。
在redis重啟的時候，是優先通過AOF進行數據恢復的，因為AOF數據比較完整。
- RDB的生成策略
要修改的是該條命令：
save 60 10000
該條命令是60秒內，如果有1萬條命令執行，那麼就進行快照備份。這個值略大，可以根據自己的業務量而定，可以調小至1000。但也同時意味著，在一分鐘內，如果命令執
行了999條，且在最後一秒redis掛掉，該分鐘內的命令將會全部丟失。
註意不要用：redis-cli SHUTDOWN
這樣的方式去測試，這是一種安全退出的模式，redis會安全生成dump.rdb
它的工作流程：
（1）redis根據配置自己嘗試去生成rdb快照文件
（2）fork一個子進程出來
（3）子進程嘗試將數據dump到臨時的rdb快照文件中
（4）完成rdb快照文件的生成之後，就替換之前的舊的快照文件dump.rdb，每次生成一個新的快照，都會覆蓋之前的老快照
- AOF的生成策略
當AOF開啟之後，redis每次接收到一條寫命令，就會寫入日誌文件中，先寫入系統的 os cache中，然後隔一段時間再fsync一下。
fsync的策略有三種：
always: 每次寫入一條數據，立即將這個數據對應的寫日誌fsync到磁碟上去，性能非常非常差，吞吐量很低;
如果說確保說redis里的數據一條都不丟，那就只能這樣了
everysec: 每秒將os cache中的數據fsync到磁碟，這個最常用的，生產環境一般都這麼配置，性能很高，QPS還是可以上萬的
no：就是直接寫入os cache就不管了，讓linux自帶的機制去將數據刷入磁碟，這樣很不可控
因此我們要配置為everysec。
接著配置兩條命令：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
redis 2.4之前，還需要手動，開發一些定時任務腳本，通過BGREWRITEAOF命令去執行AOF rewrite，但是redis 2.4之後，會自動進行rewrite操作
也就是說在上一次AOF rewrite之後，日誌大小是128mb，接著再往裡面寫日誌，當總日誌大小增長的比例，超過了之前的100%，即達到256mb後，就會觸發rewrite操作。
註意，此時還要跟 auto-aof-rewrite-min-size 比較大小，256M 大於 64m，可以觸發rewrite操作。這兩條命令，可以根據業務進行調節大小，或者保持預設值
- 定時任務備份方案（重要）
並不是說讓redis自動進行持久化備份就可以的，而是要另開腳本，進行更細緻的備份。
1 ）每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份
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` # 48小時前的目錄文件名
rm -rf /usr/local/redis/snapshotting/$del_date # 刪除48小時前的目錄
2 ）每天copy一次備份
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 //備份cp
del_date=`date -d -1month +%Y%m%d` #僅保留近一個月的數據
rm -rf /usr/local/redis/snapshotting/$del_date #刪除
3）每天一次將所有數據上傳一次到遠程的雲伺服器上去
原理跟第2點一樣，只是不是用cp，而是用scp或rsync等命令將文件備份到遠程安全伺服器
以上只給了rdb的備份，aof的備份腳本基本一致。
- 數據恢復方案（重要）
（1）如果是redis進程掛掉，那麼重啟redis進程即可，直接基於AOF日誌文件恢複數據
（2）如果是redis進程所在機器掛掉，那麼重啟機器後，嘗試重啟redis進程，嘗試直接基於AOF日誌文件進行數據恢復
如果AOF沒有破損，可以直接基於AOF恢復的
AOF append-only，順序寫入，如果AOF文件破損，那麼用redis-check-aof fix
（3）如果redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼可以嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復
找到RDB最新的一份備份，小時級的備份可以了，小時級的肯定是最新的，copy到redis裡面去，就可以恢復到某一個小時的數據
（4）如果當前機器上的所有RDB文件全部損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢複數據
恢復的過程：
（1）優先用appendonly.aof去恢複數據
（2）停止redis，關閉aof （為什麼要關閉？如果不關閉，啟動redis後，redis會生成一份新的可能為空的aof強行覆蓋目錄下的aof，導致恢復失敗）
（3）拷貝備份文件，重啟redis
（4）命令行修改redis配置，開啟aof （redis config set ）
