redis主从复制故障恢复及持久化的意义
服务器配置：（centos7）
| 服务器IP | 安装组件 | 节点 | 备注 |
|---|---|---|---|
| 192.168.27.210 | redis-5.0.5 | master | 一主两从架构 |
| 192.168.26.112 | redis-5.0.5 | slave | |
| 192.168.26.206 | redis-5.0.5 | slave |
最新版下载地址到各结点：Wget http://download.redis.io/releases/redis-5.0.5.tar.gz
解压压缩包并配置：
切换用户（生产环境少用ROOT用户操作）
[jerry@master data]$ sudo chown -R jerry.root redis-5.0.5
Cd /data/redis-5.0.5/src
make
192.168.27.210配置文件：vim /data/redis-5.0.5/redis-m-7000.conf
bind 0.0.0.0
port 7000
logfile "7000.log"
dbfilename "dump-7000.rdb"
daemonize yes
rdbcompression yes
192.168.26.112配置：
Cd /data/redis-5.0.5/src
make
[jerry@BDDB redis-5.0.5]$ vim /data/redis-5.0.5/redis-s-7000.conf
bind 0.0.0.0
port 7000
logfile "7000.log"
dbfilename "dump-7000.rdb"
daemonize yes
rdbcompression yes
slaveof 192.168.27.210 7000
192.168.26.206配置：
Cd /data/redis-5.0.5/src
make
bind 0.0.0.0
port 7000
logfile "7000.log"
dbfilename "dump-7000.rdb"
daemonize yes
rdbcompression yes
slaveof 192.168.27.210 7000
分别启动各结点：
[jerry@master src]$ ./redis-server ../redis-m-7000.conf
[jerry@BDDB src]$ sudo ln -s /data/redis-5.0.5/src/redis-server /usr/bin/redis-server
[jerry@BDDB src]$ redis-server ../redis-s-7000.conf
[jerry@DGIDC src]$ sudo ln -s /data/redis-5.0.5/src/redis-server /usr/bin/redis-server
[jerry@DGIDC src]$ redis-server ../redis-s-7000.conf
[jerry@DGIDC src]$ ss -tnl
看下三台服务器主从状态信息：
接着我们创建键值，测试主从是否同步：
三个结点我们都创建一个链接，方便我们使用。
[jerry@master src]$ sudo ln -s /data/redis-5.0.5/src/redis-cli /usr/bin/redis-cli
[jerry@BDDB src]$ sudo ln -s /data/redis-5.0.5/src/redis-cli /usr/bin/redis-cli
[jerry@DGIDC src]$ sudo ln -s /data/redis-5.0.5/src/redis-cli /usr/bin/redis-cli
观察主从信息状态：
info
重启主后服务器观察发现未保存的数据将丢失：
结论：
使用主从模式时应注意master节点的持久化操作，matser节点在未使用持久化的情况详情下如果宕机，并自动重新拉起服务，从服务器会出现丢失数据的情况。数据丢失的原因：因为master服务挂了之后，重启服务后，slave节点会与master节点进行一次完整的重同步操作，所以由于master节点没有持久化，就导致slave节点上的数据也会丢失掉。所以在配置了Redis的主从模式的时候，应该打开主服务器的持久化功能。
测试使用哨兵模式，自动监视Master节点，当前挂掉后，自动将Slaver节点变为Master节点：
然后手动切换从（26.206）：
127.0.0.1:7000> slaveof 192.168.26.112 7000
127.0.0.1:7000> set name tom
小结：
- Master可读可写，Slaver只能读，不能写
- Master可以对应多个Slaver，但是数量越多压力越大，延迟就可能越严重
- Master写入后立即返回，几乎同时将写入异步同步到各个Slaver，所以基本上延迟可以忽略
- 可以通过slaveof no one命令将Slaver升级为Master（当Master挂掉时，手动将某个Slaver变为Master）
- 可以通过sentinel哨兵模式监控Master，当Master挂掉时自动选举Slaver变为Master，其它Slaver自动重连新的Master（自动不成功有时需要使用手动切主，暂时还没找到具体原因）
