Redis6主从复制及哨兵机制的实现

2022-11-13 13:11:43 复制 哨兵 主从

Redis 主从复制

什么是主从复制

如果单机情况下，机器重启，内存数据丢失，如何保证数据的高可用呢？持久化方案
如果机器硬盘坏掉，如何保证数据的高可用呢？主从复制
Redis的主从机制：主负责读写，从一般只读不能写（客户端）。

持久化保证了即使 Redis 服务重启也不会丢失数据，因为 Redis 服务重启后会将硬盘上持久化的数据恢复到内存中，但是当 Redis 服务器的硬盘损坏了可能会导致数据丢失，不过通过 Redis 的主从复制
机制就可以避免这种单点故障，如下图：

说明：

主 Redis 中的数据有两个副本（ replication ）即从 redis1 和从 redis2 ，即使一台 Redis 服务器宕机其它两台 Redis 服务也可以继续提供服务。
主 Redis 中的数据和从 Redis 上的数据保持实时同步，当主 Redis 写入数据时通过主从复制机制会复制到两个从 Redis 服务上。
只有一个主 Redis ，可以有多个从 Redis 。
主从复制不会阻塞 master ，在同步数据时， master 可以继续处理 client 请求。
一个 Redis 可以即是主又是从，如下图：

主从配置

主Redis配置

无需特殊配置

从Redis配置

修改从服务器上的 redis.conf 文件：

# slaveof <masterip> <masterport> 
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。 
slaveof 192.168.10.135 6379 
replicaof 192.168.19.135 6379

实现原理

  • Redis 的主从同步，分为全量同步和增量同步。
  • 只有从机第一次连接上主机是全量同步。
  • 断线重连有可能触发全量同步也有可能是增量同步（ master 判断 runid 是否一致）。
  • 除此之外的情况都是增量同步。

全量同步

Redis 的全量同步过程主要分三个阶段：

  • 同步快照阶段： Master 创建并发送快照给 Slave ， Slave 载入并解析快照。 Master 同时将此阶段所产生的新的写命令存储到缓冲区。
  • 同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。
  • 同步增量阶段： Master 向 Slave 同步写操作命令。

增量同步

  • Redis 增量同步主要指 Slave 完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。
  • 通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。

Redis 哨兵机制

Redis 主从复制的缺点：没有办法对 master 进行动态选举，需要使用 Sentinel 机制完成动态选举。

简介

  • Sentinel (哨兵)进程是用于监控 Redis 集群中 Master 主服务器工作的状态
  • 在 Master 主服务器发生故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用（ HA ）
  • 其已经被集成在 redis2.6+ 的版本中， Redis 的哨兵模式到了 2.8 版本之后就稳定了下来。

哨兵进程的作用

  • 监控( Monitoring ): 哨兵( sentinel ) 会不断地检查你的 Master 和 Slave 是否运作正常。
  • 提醒( Notification )： 当被监控的某个 Redis 节点出现问题时, 哨兵( sentinel ) 可以通过api 向管理员或者其他应用程序发送通知。
  • 自动故障迁移( Automatic failover )：当一个 Master 不能正常工作时，哨兵( sentinel )会开始一次自动故障迁移操作

故障判定原理分析

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

自动故障迁移

  • 它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复制新的 Master ；
  • 当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master 。
  • Master 和 Slave 服务器切换后， Master 的 redis.conf 、 Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变，即， Master 主服务器的 redis.conf配置文件中会多一行 slaveof 的配置， sentinel.conf 的监控目标会随之调换。

案例演示

修改从机的 sentinel.conf ：

# 哨兵sentinel监控的redis主节点的 ip port 
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".- _"组成。 
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节 点失联了 
# sentinel monitor <master-name> <master ip> <master port> <quorum> 
sentinel monitor mymaster 192.168.10.133 6379 1

其他配置项说明sentinel.conf

# 哨兵sentinel实例运行的端口 默认26379 
port 26379 
# 哨兵sentinel的工作目录 
dir /tmp 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组 成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点 失联了 
# sentinel monitor <master-name> <ip> <redis-port> <quorum> 
sentinel monitor mymaster 127.0.0.1 6379 2 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都 要提供密码 
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 
# sentinel auth-pass <master-name> <passWord> 
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 
# sentinel down-after-milliseconds <master-name> <milliseconds> 
sentinel down-after-milliseconds mymaster 30000 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步
# 这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。 
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。 
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的 master那里同步数据时。 
#3.当想要取消一个正在进行的failover所需要的时间。 
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超 时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了 
# 默认三分钟 
# sentinel failover-timeout <master-name> <milliseconds> 
sentinel failover-timeout mymaster 180000


# SCRIPTS EXECUTION 
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮 件通知相关人员。 
#对于脚本的运行结果有以下规则： 
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。 
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执 行。

#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等 等），将会去调用这个脚本，
#这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正 常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。 
#如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且 是可执行的，否则sentinel无法正常启动成功。

#通知脚本 
# sentinel notification-script <master-name> <script-path> 
sentinel notification-script mymaster /var/redis/notify.sh

# 客户端重新配置主节点参数脚本 
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master 地址已经发生改变的信息。 
# 以下参数将会在调用脚本时传给脚本: 
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> 
# 目前<state>总是“failover”, 
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的 slave)通信的 
# 这个脚本应该是通用的，能被多次调用，不是针对性的。 
# sentinel client-reconfig-script <master-name> <script-path> 
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

通过 redis-sentinel 启动哨兵服务

./redis-sentinel sentinel.conf

到此这篇关于Redis6 主从复制及哨兵机制的实现的文章就介绍到这了,更多相关Redis6 主从复制及哨兵机制内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！

相关文章