Redis主从复制
什么事主从复制?
就是主机数据更新后,根据配置和策略,自动同步到备份机的机制.(master/slave)
master以写为主,slave一般是只读的.
用处:
- 读写分离,性能扩展
- 容灾快速恢复
1. 配置
一主二仆模式演示:
首先准备出3份配置文件
各自的配置文件中需要修改的几处:
1. port 6379
port 6380
port 6381
2. daemonize yes
3. pidfile /var/run/redis_6379.pid
pidfile /var/run/redis_6380.pid
pidfile /var/run/redis_6381.pid
2. 分别启动3个server服务
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
再分别于3个终端窗口启动3个redis-cli
redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381
查看备份信息,这时,三个服务都是master
info replication
3. 配置一主二仆
在slave执行命令,变成salve
slaveof 127.0.0.1 6379
这时再分别执行info命令查看主从配置信息,发现6379
是master,而6380
和6381
变成了slave
info replication
4. 一主二仆模式演示(疑问猜想验证)
4.1 切入点问题
比如,在配置主从之前,6379
可能之前有过多个写请求,假设,现在master中有3个新增的key,
k1,k2,k3.
那么在这个时候,6380
和6381
才宣告,自己作为6379
的slave介入,接入之后,在master
上又执行了一次写入操作,添加了k4,那么问题来了,这时候slave
中的数据是什么样的呢?是只有k4的信息,还是k1~k4都有呢?下面我们来验证一下
1. 首先,将slave
恢复master
的身份.
slaveof no one
2. 在6379
中,新增k1,k2,k3
此时6380和6381是空的.
3. 恢复主仆模式
slaveof 127.0.0.1 6379
4. master添加k4
发现信息全都被同步了!
4.2 slave是否可写?
发现,slave可以get却不可以写
4.3 master宕机后,slave的动作
当master宕机后,slave是变成master还是原地待命呢?
1. 关闭6379的服务
SHUTDOWN
exit
这时候可以发现,master
已经down了,但是slave依然是slave.
2. 那我们再让master
回来,会是什么情景呢?
redis-server redis6379.conf
redis-cli -p 6379
发现,又重新恢复主仆模式了.
而且依然可以保持数据同步.
4.4 如果slave宕机再复原,中间的数据会丢失吗?
演示完了master
宕机、复原,我们再来演示一下slave
宕机、复原.
这次试用6380来演示
1. 首先,依旧是关闭服务,退出cli.
shutdown
exit
这时可以看到,只有一个slave
了.
2. 接下来新增几条信息
mset k6 v6 k7 v7 k8 v8
在slave查看一下.
3. 让6380复原
发现,6380复原后,不再自动变为6379的slave.
我们需要再次手动让它变为slave。
slaveof 127.0.0.1 6379
这时,信息全部被同步下来了
4.5 复制原理
- 每次联通后,slave都会给master发送sync指令
- master立即进行存盘操作,发RDB文件给slave
- slave接收到RDB文件后,进行加载.
- 之后每次master的写操作,都会立刻发给slave,来执行相同的命令.
5. 薪火相传
与一主二仆不同,熄火相传的主从模式中,上一个slave可以当做下一个slave的master,这样就不会是所有的sync都发送给master了,可以有效的减轻master的写压力,去中心化降低风险.
配置方式依然是slaveof指令.
这次,我们在6381上执行,让它变成6380的slave
slaveof 127.0.0.1 6380
这时我们可以发现,master
只有一个slave
了,就是6380,而6380虽然依然保持着slave
身份,但是它却又有了一个slave
6381,而在6381的信息中可以看到,它目前的master
是6380.
这样,就会形成一个链式解构,master
只需要负责给它的直接下属slave
发送同步即可,减轻了master
的压力,但是缺点是,如果下级的某个slave
宕机了,那么它之后的所有slave
都无法获得数据同步.
6. 反客为主
指的是,在主从关系中,如果master
宕机了,那么默认的,所有的slave
都将处于待机状态,等待master
的再次连接,但是在生产上,不可能这么做,所以,一般而言,当master
宕机后,我们可以手动的指定一个slave
来担任master
,这样,其后面的slave
不需要做任何改变.
那么我们在薪火相传的基础上来演示一下.
1. 让master宕机
老规矩
shutdown
exit
发现,6380的master
宕机,所以它现在处于待机状态.
而且,它还是只读的,也就意味着,这一段时间内,用户对redis的任何写操作,都将无法执行.
2. 让6380反客为主
slaveof on one
这时,6380变成了master
,而6381还是那个slave
,无需任何操作.
写操作也恢复了!
疑问,那么这时如果6379
再回来呢?
发现,已经没有任何slave
了.
7. 哨兵模式
上面的反客为主,是需要手动的,但是,如果凌晨2点,宕机了,难道运维兄弟还要爬起来手动给你freedom
吗…
于是,我们下面来演示一下,自动版,哨兵模式.
哨兵模式:反客为主的自动版,能够后台监控master
是否故障,如果故障了,根据自动投票,自动将slave
转为master
.
配置哨兵模式:
1. 首先调整为一主二仆模式:
还是以6379
为master
,其余为slave
2. 创建并配置sentinel.conf
touch sentinel.conf
这里的localhost 127.0.0.1
类似/etc/hosts中的配置,根据实际情况来.
sentinel monitor localhost 127.0.0.1 6379 1
3.启动哨兵
redis-sentinel
4. 让master宕机
发现,几秒钟过后,哨兵的控制台打印出了信息,宣告6380
变成了新的master
,6381
不在是6379
的slave
,而变成了6380
的slave
,再有就是6379
也变成了6380
的slave
!!!
尝试在6380
写入,看是否可以接受.
5. 让6379再回来,看看是什么结果
哨兵控制台会打印,6379
连接为6380
的slave
而且,信息可以成功的同步过来了
补充:
在配置了主从关系后,slave
的redis*.conf配置文件的末尾,会有如下信息.