模擬redis災難恢復
利用replication機制來彌補aof、snapshot性能上的不足，達到了數據可持久化。
即master上RDB和AOF都不開啟，來保證master的讀寫性能，
而slave上則同時開啟RDB和AOF來進行持久化，保證數據的安全性。
如果數據要做持久化，又想保證穩定性，建議留一半的物理內存。
因為在進行snapshot時，fork出來進行dump操作的子進程會占用與父進程一樣的內存，
真正的copy-on-write，對性能的影響和內存的耗用都是比較大的。
環境描述：
master：192.168.2.100 不開啟RDB和AOF
slave：192.168.2.200 開啟RDB和AOF
配置信息：
master：
# vim etc/redis.conf
#save 600 5 //禁用RDB
appendonly no //禁用AOF
requirepass 123456 //指定驗證密碼
slave：
# vim etc/redis.conf
save 600 5 //開啟RDB
dbfilename "dump_6379.rdb" //RDB文件
dir "/usr/local/redis-3.0.6-6379" //RDB文件路徑
appendonly yes //開啟AOF
appendfilename "appendonly.aof" //指定AOF文件
appendfsync everysec //每秒強制寫入磁盤一次
no-appendfsync-on-rewrite no //在日誌重寫時，不進行命令追加操作
auto-aof-rewrite-percentage 100 //當前AOF超過上一次AOF大小100%時重寫
auto-aof-rewrite-min-size 64mb //日誌重寫最小值
slaveof 192.168.2.100 6379 //指定主庫IP和端口
masterauth 123456 //指定主庫登錄密碼
啟動redis:
master：# redis-server etc/redis.conf
slave：# redis-server etc/redis.conf
master創建key：
# redis-cli -a 123456
127.0.0.1:6379> info replication //查看主從關系是否正確
127.0.0.1:6379> keys * //此時，master安裝目錄下是沒有RDB文件的
(empty list or set)
127.0.0.1:6379> set name zhagnsan //創建3個key
OK
127.0.0.1:6379> set age 26
OK
127.0.0.1:6379> set home beijing
OK
slave檢查同步情況：
# redis-cli
127.0.0.1:6379> keys * //數據已同步
1) "age"
2) "home"
3) "name"
模擬master故障：
# ps -ef |grep redis
root 126472 1 0 21:58 ? 00:00:02 redis-server *:6379
root 127714 2844 0 22:29 pts/0 00:00:00 grep --color=auto redis
# kill -9 126472
# rm -rf dump_6379.rdb
slave查看主從狀態：
# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.2.100
master_port:6379
master_link_status:down //我們看到master已經不可訪問了，slave正常
master_last_io_seconds_ago:-1
... ...
災難恢復：
1、取消slave的同步狀態
避免master未完成數據恢復就重啟，導致覆蓋掉slave上的數據，最終數據丟失。
127.0.0.1:6379> SLAVEOF no one //動態修改配置文件，將slavof設置為no
OK
127.0.0.1:6379> info repolication //查看主從信息，已經沒有了
127.0.0.1:6379>
2、啟動master的redis，確認數據不存在（這步可以忽略，我只是想確認下有沒有數據）
# redis-server etc/redis.conf
# redis-cli -a 123456
127.0.0.1:6379> keys *
(empty list or set)
# ps -ef |grep redis
root 128031 1 0 22:45 ? 00:00:00 redis-server *:6379
root 128050 2844 0 22:46 pts/0 00:00:00 grep --color=auto redis
# kill -9 128031 //再次異常關閉redis
# rm -rf dump_6379.rdb //再次刪除RDB文件
3、拷貝RDB文件和AOF文件給master
# scp dump_6379.rdb 192.168.2.100:/usr/local/redis-3.0.6-6379/
# scp appendonly.aof 192.168.2.100:/usr/local/redis-3.0.6-6379/
4、master開啟RDB、開啟AOF
# vim etc/redis.conf
save 600 5 //開啟RDB
dbfilename "dump_6379.rdb" //RDB文件
dir "/usr/local/redis-3.0.6-6379" //RDB文件路徑
appendonly yes //開啟AOF
appendfilename "appendonly.aof" //指定AOF文件
... ...
5、master啟動redis，查看庫，數據已恢復
# redis-server etc/redis.conf
# redis-cli -a 123456
127.0.0.1:6379> keys *
1) "home"
2) "name"
3) "age"
6、master數據恢復後，需要關閉RDB和AOF，來保證自身的讀寫性能。
但是RDB文件和AOF文件要保留（不能恢復數據後給刪除了）
雖然RDB文件和AOF文件存在，但大小不會增加，依然只是salve的AOF文件增加。
# kill [redis PID] //關閉redis
# vim etc/redis.conf //關閉RDB和AOF
#save 600 5
appendonly no
# redis-server etc/redis.conf //啟動redis
# redis-cli -a 123456
127.0.0.1:6379> keys * //關閉RDB和AOF功能，庫中的數據依然存在
1) "home"
2) "name"
3) "age"
7、slave開啟同步狀態
127.0.0.1:6379> SLAVEOF 192.168.2.100 6379 //開啟同步狀態
OK
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.2.100
master_port:6379
master_link_status:up //master可以正常訪問了
master_last_io_seconds_ago:5
master_sync_in_progress:0
... ...
8、master創建key
127.0.0.1:6379> set abc 123 //新增一個key
OK
127.0.0.1:6379> keys *
1) "abc"
2) "home"
3) "name"
4) "age"
9、slave查看同步情況
127.0.0.1:6379> keys *
1) "abc"
2) "age"
3) "home"
4) "name"
總結：
在此次恢復的過程中，我們同時使用了AOF和RDB文件，那麽到底是哪個文件完成了恢復呢？
1、如果只配置了RDB，啟動時加載的是RDB文件；
2、如果只配置了AOF，啟動時加載的是AOF文件；
3、如果同時配置了RDB和AOF，由於AOF優先級高於RDB，所以使用的是AOF文件。
而且，AOF文件的數據完整性要高於RDB文件，因為RDB是按照周期性策略進行保存的。
如果在下個周期來臨前故障，那麽將丟失上個周期到故障點的數據。
模擬redis災難恢復