Redis的复制(MasterSlave)

一、 主从简介

配置多台 Redis 服务器，以主机和备机的身份分开。主机数据更新后，根据配置和策略，自动同步到备机的master/salver 机制，Master以写为主，Slave以读为主，二者之间自动同步数据。

• 目的：

读写分离提高 Redis 性能； 避免单点故障，容灾快速恢复。

• 原理：

每次从机联通后，都会给主机发送 sync 指令(sync命令用于强制吧文件系统buff的内容，写入系统磁盘)，主机立刻进行存盘操作，发送 RDB 文件，给从机 从机收到 RDB 文件后，进行全盘加载。之后每次主机的写操作，都会立刻发送给从机，从机执行相同的命令。

• 官网：

二、操作过程

1、配从(库)不配主(库)

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

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

info replication : 查看服务的节点信息

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

除非是不同的主机配置不同的 Redis 服务，否则在一台机器上面跑多个 Redis 服务，需要配置多个 Redis 配置文件。

（1）准备多个 Redis 配置文件，每个配置文件，需要配置以下属性

• daemonize yes: 服务在后台运行
• port：端口号
• pidfile:pid 保存文件
• logfile：日志文件(如果没有指定的话，就不需要)
• dump.rdb: RDB 备份文件的名称
• appendonly 关掉，或者是更改 appendonly 文件的名称。

（2）样本：

• include /root/redis_repilication/redis.conf
• port 6379
• pidfile /var/run/redis_6379.pid
• dbfilename dump_6379.rdb

（3） 根据多个配置文件，启动多个 Redis 服务

（4）案例：

• 拷贝多个redis.conf文件

  

• 开启daemonize yes；pid文件名字；指定端口

  

• log文件名字

  

• dump.rdb名字

  

4、常用3招

(1) 一主二仆,

• 临时建立

  原则：配从不配主。

  配置：在从服务器上执行 SLAVEOF ip:port 命令；

  查看：执行 info replication 命令；

• 永久建立

  在从机的配置文件中，编写 slaveof 属性配置！

(2)、薪火相传

• Init 开始时都是Master

  redis-server redis6379.conf 启动服务端

  myredis redis-cli -p 6379 启动客户端

• 一个Master两个Slave

  salvoes 127.0.0.1 6379 从机1

  salvoes 127.0.0.1 6379 从机2

  

• 日志查看

  主机日志

  

  备机日志

  

  info replication

  

• 主从问题演示

  1. 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制? 比如从k4进来，那之前的123是否也可以复制

     答：从头开始复制

  2. 从机是否可以写？set可否？

     答：从机不可以写。写入的时候会返回如下错误。

  1 2	127.0.0.1:6380> set k1 v1 (error) READONLY You can't write against a read only replica.

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

     答：原地待命

  2. 主机又回来了后，主机新增记录，从机还能否顺利复制？

     答：可以

  3. 其中一台从机 down 后重启，能否重认旧主？

     答：不一定，看配置文件中是否配置了 slaveof

  4. 如果两台从机都从主机同步数据，此时主机的 IO 压力会增大，如何解决？

     答：按照主—-从（主）—-从模式配置！

(3)、SLAVEOF no one 取消从机

​ 使当前数据库停止与其他数据库的同步，转成主数据库

三、复制原理

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

四、哨兵模式(sentinel)

1、简介

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

作用：

• Master 状态检测
• 如果 Master 异常，则会进行 Master-Slave 切换，将其中一个 Slave 作为 Master，将之前的 Master 作为Slave

下线：

• 主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个 redis 服务器做出的下线判断。
• 客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对 Master Server 做出SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的 Master Server 下线判断，然后开启 failover.

工作原理：

• 每个 Sentinel 以每秒钟一次的频率向它所知的Master、Slave以及其他 Sentinel实例发送一个 PING 命令 ；
• 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线；
• 如果一个 Master 被标记为主观下线，则正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认 Master 的确进入了主观下线状态；
• 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认 Master 的确进入了主 观下线状态， 则 Master 会被标记为客观下线 ；
• 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 INFO 命令
• 当 Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 ；
• 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除;若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除；

2、配置步骤：哨兵模式需要配置哨兵的配置文件

• 调整结构，6379带着80、81

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

• 配置哨兵,填写内容

  sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

  

  上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

• 启动哨兵

  

  redis-sentinel /myredis/sentinel.conf

  上述目录依照各自的实际情况配置，可能目录不同

• 原有的master挂了

  

• 投票新选

  

  

• 重新主从继续开工,info replication查查看

  

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

  答：不会冲突，master重启回来后变成了从机。

  

五、一组sentinel能同时监控多个Master

六、复制的缺点： 复制延时

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

---

• ← Previous Post
• Next Post →

---