第八章：（1）Redis 的复制（Master/Slave）

一、Redis 复制

　　Redis 复制是什么？

　　官网介绍：

　　

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

　　

二、主从复制（作用&好处）

　　1、读写分离

　　2、容灾恢复

三、准备工作

　　1、配从（库）不配主（库）

　　　　只需要配置从库的信息，把从库降一个等级；

　　2、从库配置：slaveof  主库IP  主库端口

　　　　配置从库中主机：

slaveof 主库IP 主库端口

　　　　 使用命令的方式配置，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件。

　　　　可以使用 Info replication 命令进行查看。

　　3、修改配置文件细节操作

　　① 拷贝多个 redis.conf 文件

　　② 开启 daemonize yes

　　　　

　　③ Pid 文件名字 

　　④ 指定端口

　　⑤ Log 文件名字

　　　　

　　⑥ Dump.rdb 名字

　　　　

四、常用三招

　　1、一主二仆

　　（1）Init

　　（2）一个 Master 两个 Slave

　　（3）日志查看

　　　　主机日志：

　　　　备机日志：

　　　　info  replication：

　　（4）主从问题演示

　　　　① 切入点问题？当都是 master 时，其中一台设置了k1，k2，k3，另外两台slave1、slave2都设置为了从库，slave1、slave2是从头开始复制还是从切入点开始复制? 比如从k4进来，那之前的三个key是否也可以复制？

　　　　　　答：slave 会从头开始复制，之前的 key 也可以复制。

　　　　② 从机 slave 是否可以写？set 命令可以吗？

　　　　　　答：从机slave不可以写，不可 set。只有主机可写。

　　　　③ 主机 shutdown 后情况如何？从机是上位还是原地待命？

　　　　　　答：从机还是原地待命（咸鱼翻身，还是咸鱼）

　　　　④ 主机又回来了，主机并且新增记录，从机是否还能顺利复制？

　　　　　　答：能连接到主机，并能顺利复制。

　　　　⑤ 其中一台从机宕机后情况如何？依照原有它能跟上大部队吗？

　　　　　　答：不能跟上，每次与 master 断开之后，都需要使用 slaveof 命令重新连接。

　　　　　　除非你配置进redis.conf文件（具体位置：redis.conf搜寻#### REPLICATION ####）

　　（5）一主二仆优劣势

　　　　缺点：中心化太严重，如果master宕机了，都无法正常运行。

　　2、薪火相传

　　（1）去中心化

　　　　上一个 Slave 可以是下一个 slave 的 Master，Slave 同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master，可以有效减轻 master 的写压力。

　　　　中途变更转向:会清除之前的数据，重新建立拷贝最新的

　　　　命令：

Slaveof 新主库IP 新主库端口

　　（2）缺点

　　　　减轻了 master 的写压力，slave 的复制传递可能会导致延时。

　　3、反客为主

　　　　当主机宕机之后，从机不会有作为（原地待命），可以在从机执行 slaveof no one 命令，使得从机转换为主机，然后再把其他slave跟在当前的master上。

　　　　当第一次的主机回来之后，与现在的一主一从形成了两个互不相关的系统。

SLAVEOF no one：使当前数据库停止与其他数据库的同步，转成主数据库

　　

五、复制原理

• slave 启动成功连接到 master 后会发送一个sync命令；
• master 接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步；
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中；
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步；
• 但是只要是重新连接master，一次完全同步（全量复制)将被自动执行；

六、哨兵模式（Sentinel）

　　1、哨兵模式是什么？

　　　　反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

　　　　一组 Sentinel 能同时监控多个 Master。

　　2、如何操作

　　（1）调整结构，6379带着80、81（一主二仆模式）

　　（2）自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

　　（3）配置哨兵，填写内容

 sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

　　　　　　

　　（4）启动哨兵

　　　　

Redis-sentinel /myredis/sentinel.conf 
上述目录依照各自的实际情况配置，可能目录不同

　　

　　（5）正常主从演示

　　（6）原有的 master 宕机了

　　（7）投票新选

　　（8）重新主从继续工作，使用 info replication 查看

　　（9）问题：如果之前的master重启回来，会不会双master冲突？

 　　　　答： 不会，原master，变成slave。

　　3、小结

　　一组sentinel能同时监控多个Master。

sentinel monitor <master-group-name> <ip> <port> <quorum>

For the sake of clarity, let’s check line by line what the configuration options mean:

The first line is used to tell Redis to monitor a master called mymaster, that is at address 127.0.0.1 and port 6379, with a quorum of 2. Everything is pretty obvious but the quorum argument:

The quorum is the number of Sentinels that need to agree about the fact the master is not reachable, in order to really mark the master as failing, and eventually start a failover procedure if possible.
However the quorum is only used to detect the failure. In order to actually perform a failover, one of the Sentinels need to be elected leader for the failover and be authorized to proceed. This only happens with the vote of the majority of the Sentinel processes.
So for example if you have 5 Sentinel processes, and the quorum for a given master set to the value of 2, this is what happens:

If two Sentinels agree at the same time about the master being unreachable, one of the two will try to start a failover.
If there are at least a total of three Sentinels reachable, the failover will be authorized and will actually start.
In practical terms this means during failures Sentinel never starts a failover if the majority of Sentinel processes are unable to talk (aka no failover in the minority partition).

Source

　　官网文档说明

　　中文官网说明：http://www.redis.cn/topics/sentinel.html

七、复制的缺点

　　复制延时

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