Redis主从复制

是什么？

行话：也就是我们所说的主从复制，主机（master）数据更新后根据配置和策略，自动同步到从机（slave）的master/slaver机制，Master以写为主，Slave以读为主

能干嘛？

• 读写分离
• 容灾恢复

怎么玩？

一主二从

一台主机（master），两台从机（slave）（一主多从也是一个配置）
为了方便，我们就在一台机子上操作

第一步：准备配置文件

准备3个配置文件，修改一下名字，分别为：（redis配置文件以端口号命名）

• redis6379.conf
• redis6380.conf
• redis6381.conf

第二步：修改配置文件

因为是在一台机子上模拟，所以分别在3个配置文件中修改一下操作，便于区分

daemonize yes
修改pid文件名称
pidfile /var/run/redis6379.pid
pidfile /var/run/redis6380.pid
pidfile /var/run/redis6381.pid
修改配置端口号，分别为
port 6379
port 6380
port 6381
修改日志名称，分别为
logfile "6379.log"
logfile "6380.log"
logfile "6381.log"
修改RDB文件名，分别为
dbfilename dump6379.rdb
dbfilename dump6380.rdb
dbfilename dump6381.rdb

第四步：启动

使用指令：info replication，查看主从信息



这个时候，3个都是master
所以我们在6380和6381上使用指令SLAVEOF [新主库IP] [新主库端口]
即是 ：


这时候使用指令info replication可得到slave已经配置完成

这个时候配置主从就完成了，从配置主从完成后开始，master上的所有数据，在slave都可用获取到，无论你在master是存储数据后在配置主从，还是配置主从后再存储数据，slave都可用获取得到

注意点

1. master能进行读写操作，而slave只能进行读操作
   
   
   

2. 如果master突然宕机了，那么slave不会代替主机的位置
   
   
   
   如果master回来了，那么一切照旧

3. slave宕机了，后面复活了，没办法回到slave的位置，每当slave和master断开后，需要重新连接，常非配置进了Redis的配置文件
   

缺点

• 对master负担比较大

薪火相传

薪火相传主要是优化一主多从，由于一主多从的方式只有一台master，master负担很大，薪火相传的模式上一个slave可以是下一个slave的master，slave同样可以接收其他slave的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力

配置文件和一主多从一样，只是连接的方式不一样，6379端口的机子作为master，6380的机子成为6379的slave，而6381的机子作为6380的slave，同理，如果有多台，一直这样配置，前一台是后一台的master


6379挂在一台slave，身份为master

6380也挂在一台slave，身份是slave

反客为主

反客为主也是用来优化一主多从的，再一主多从模式中，当master宕机以后，slave是无法变成master的，反客为主就是master宕机后slave变为master，使当前数据库停止与其他数据库的同步，转成主数据库

配置为一主多从后，这个时候master宕机了，那么再从机中使用指令：SLAVEOF no one，slave瞬间变为master


另一个slave要重写挂向新master

复制原理

1. slave启动成功连接到master后会发送一个sync命令
2. master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步

• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中（首次）
• 增量复制：master继续将新的所有收集到的修改命令依次传给slave,完成同步（非首次）

注意：只要是重新连接master，一次完全同步（全量复制）将被自动执行

哨兵模式（王牌）

哨兵模式是什么？

• 反客为主的自动版（反客为主的基础是一主多从），能够后台监控master是否故障，如果故障了根据投票数自动将slave转换为master

第一步：调整结构

6379带着6380和6381

第二步：配置哨兵

在自定义目录（这里以/myredis为例）下新建sentinel.conf文件，名字绝不能错

配置sentinel.conf文件：
sentinel monitor 被监控主机的名字(自己起名字) [主机ip] [端口] [票数]
票数：表示master挂掉后salve投票看让谁接替成为master，得票数多少后成为master

 sentinel monitor host6379 127.0.0.1 6379 1

启动哨兵：
命令：redis-sentinel /myredis/sentinel.conf
上述目录依照各自的实际情况配置，可能目录不同

第四步：模拟主机宕机环境

这个时候，master突然宕机

等待哨兵选出新的master，可用看到选出了6380

结果如下：


这个时候，老master回来了，然而位置被顶替了，所以只能当slave

在6380可用看到，6379已经成为slave了

一组sentinel能同时监控多个master

缺点

• 由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重