redis主从复制故障恢复及持久化的意义
服务器配置：（centos7）
坚守“ 做人真诚 · 做事靠谱 · 口碑至上 · 高效敬业 ”的价值观，专业网站建设服务10余年为成都成都发电机回收小微创业公司专业提供企业网站设计营销网站建设商城网站建设手机网站建设小程序网站建设网站改版，从内容策划、视觉设计、底层架构、网页布局、功能开发迭代于一体的高端网站建设服务。
| 服务器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（自动不成功有时需要使用手动切主，暂时还没找到具体原因）
当前名称：redis主从复制故障恢复及持久化的意义
URL链接：http://myzitong.com/article/gshicg.html