redis的主从复制master/slaver

Posted 2020-12-19 傲娇的大王

什么是Redis的复制

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

复制原理

1. Slave启动成功连接到master后会发送一个sync命令；

2. Master接到命令，启动后的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master

   将传送整个数据文件到slave，以完成一次完全同步；

3. 全量复制：而slave服务在数据库文件数据后，将其存盘并加载到内存中；

4. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步；

5. 但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。

能干嘛？

​ 读写分离

​ 容灾恢复

主从复制准备工作

配从(库)不配主(库)

从库配置命令

#配置从库
slaveof 主库ip 主库端口
#查看主从信息
info replication

每次与master断开后，都需要重新连接，除非你配置进redis.conf文件

复制多个配置文件，修改不同的配置文件细节操作：

• 拷贝多个redis.conf文件，按\'redis[port].conf\'重命名
• 开启daemonize yes
• pid：指定配置文件名字redis[port].conf
• 指定端口：
• dbfilename：指定dump.rdb名字，dump[port].rdb

常用的主从方式：一主二仆、薪火相传、反客为主

一主二仆

含义：就是一个Master两个Slave

配置redis.conf开放三个端口6379，6380，6381

linux命令：

6380： slaveof 127.0.0.1 6379

6381:  slaveof 127.0.0.1 6379

 initial

 一个master两个slaver

首次执行slave1、slave2的主从复制，任意切入点获取，均是全量复制

 日志查看，日志位于/usr/local/bin下，三台redis，三个日志文件

日志文件名即在redis.conf当中配置的文件名：

logfile：指定日志文件名字[port].log

主机日志

 

从机日志

 通过info replication查看主从信息

 主从问题演示

• 从机是否可以写？set可否？
  • 答：从机不可写，不可set，主机可写
• 主机shutdown后情况如何？从机是上位还是原地待命
  • 答：从机还是原地待命（咸鱼翻身，还是咸鱼）

• 第一次slave1 和slave2切入点，是全量复制（比如从k4进来，那之前的k1k2k3也成功复制），之后是增量复制  。

         

• 主机可以写，但是从机不可以写，从机只能读

  

• 主机shutdowm后从机待机状态，等主机回来后，主机新增记录从机可以顺利复制

• 从机shutdowm后，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件

• 从机复制到的数据，会被本机持久化。就算shutdown断开连接依然会有数据。

• 重新连接或者变更master，会清除之前的数据，重新建立拷贝最新的数据

薪火相传

Linux命令：

6380： slaveof 127.0.0.1 6379

6381:  slaveof 127.0.0.1 6380 

含义:就是上一个Slave可以是下一个slave的Master。

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

注意：虽然有slave是相对master，但是依然是slave。

反客为主

比如6379挂掉：

shutdown

exit

在6380下执行Linux命令，使当前数据库停止与其他数据库的同步，转成主数据库。

SLAVEOF no one

接下来，其他的slave当中如6381，要么静默等待老master也就是6379复活自动重新挂在6379下面。

要么跟着新老板6380.

slaveof 127.0.0.1 6380

哨兵模式(sentinel)

一组sentinel能同时监控多个master

是什么

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

怎么玩(使用步骤)

1. 调整结构，6379带着6380、6381
2. 新建sentinel.conf空文件，名字绝不能错
3. 配置哨兵,填写内容
   • sentinel monitor 被监控主数据库名字(自己起名字) 127.0.0.1 6379 1
   • 上面最后一个数字1，表示主机挂掉后salve投票，得票数多少后成为主机（PS. 跟官网的描述有出入，下面有官方文档说明）
4. 启动哨兵
   • redis-sentinel /sentinel.conf （上述目录依照各自的实际情况配置，可能目录不同）
5. 正常主从演示
6. 原有的master挂了
7. 投票新选
8. 重新主从继续开工，info replication查看

问题：如果之前挂了的master重启回来，会不会双master冲突？ 答： 不会，原master，变成slave

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

quorum 英 [ˈkwɔːrəm] 美 [ˈkwɔːrəm]
n. (会议的)法定人数

复制的缺点

复制延时

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