redis主从复制故障恢复及持久化的意义

Posted 2020-11-16

服务器配置：（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

小结：

1. Master可读可写，Slaver只能读，不能写
2. Master可以对应多个Slaver，但是数量越多压力越大，延迟就可能越严重
3. Master写入后立即返回，几乎同时将写入异步同步到各个Slaver，所以基本上延迟可以忽略
4. 可以通过slaveof no one命令将Slaver升级为Master（当Master挂掉时，手动将某个Slaver变为Master）
5. 可以通过sentinel哨兵模式监控Master，当Master挂掉时自动选举Slaver变为Master，其它Slaver自动重连新的Master（自动不成功有时需要使用手动切主，暂时还没找到具体原因）