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身份，但是它却又有了一个slave6381，而在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配置文件的末尾，会有如下信息.