Redis单个分片高可用&哨兵集群

摘要:
前面的多个Redis节点都是存储分区信息的节点。如果一个节点发生故障,将丢失该分区的数据。这需要单个分区的高可用性,并通过配置多个从节点来备份主节点。此外,主节点和从节点之间没有侦听器。在主节点下降后,从节点将不知道它有机会上升。Redis提供的哨兵是一个监听器角色,可以实现主从故障切换。准备三个redis.conf文件,以便在启动时加载。将端口号修改为6382、6383和6384。参考其他配置https://www.cnblogs.com/youngchaolin/p/11983705.html 。

前面的多个redis节点,都是一个节点存储一个分片的信息,如果单个节点宕机,会导致这个分片的数据未命中,这就需要实现单个分片的高可用,通过配置多个从节点来backup主节点。另外主从节点之间是没有一个监听者的,主节点宕机后,从节点不会知道自己有上位的机会,redis提供的哨兵就是一个监听者的角色,它可以实现主从的故障转移。

单个分片高可用

实现单个分片高可用,需要实现主从复制,即配置一个主节点,多个从节点,主节点上的数据可以复制到从节点上。redis有一主多从,和多级主从的结构,主从结构不宜复杂,这样会让数据同步的路径更多,会有不稳定的风险。

一主多从,企业常用,一般配置1主6从。

Redis单个分片高可用&哨兵集群第1张 

多级主从结构示意。

Redis单个分片高可用&哨兵集群第2张

下面在单台centos服务器中,配置一主两从的结构,实现主从复制。

(1)准备3个redis.conf文件,启动时加载用,里面修改端口号为6382、6383和6384,其他配置参考https://www.cnblogs.com/youngchaolin/p/11983705.html

# 三个文件以端口号来区分,启动加载时不容易出错
-rw-r--r--. 1 root root 46750 Dec 8 05:05 redis6382.conf -rw-r--r--. 1 root root 46750 Dec 8 05:06 redis6383.conf -rw-r--r--. 1 root root 46750 Dec 8 05:06 redis6384.conf

(2)redis-server redisXXXX.conf来启动三个redis节点,使用info命令选一个来查看信息,发现都是默认自己就是master主节点,并且从节点数为0。

启动redis-server。

[root@node01 /home/software/redis-3.2.11]# redis-server redis6382.conf
[root@node01 /home/software/redis-3.2.11]# redis-server redis6383.conf
[root@node01 /home/software/redis-3.2.11]# redis-server redis6384.conf
[root@node01 /home/software/redis-3.2.11]# ps -ef|grep redis
root      8828     1  0 05:09 ?        00:00:00 redis-server *:6382
root      8832     1  0 05:09 ?        00:00:00 redis-server *:6383
root      8836     1  0 05:09 ?        00:00:00 redis-server *:6384
root      8869  5351  0 05:11 pts/1    00:00:00 grep redis
You have new mail in /var/spool/mail/root

info replication命令查看节点信息。

# 参考了文末博文
127.0
.0.1:6382> info replication # Replication role:master #角色主节点,slave就是从节点 connected_slaves:0 #连接的从节点数为0 master_repl_offset:0 # 主节点复制偏移量 repl_backlog_active:0 #复制积压缓冲区是否开启 repl_backlog_size:1048576 #复制积压缓冲区大小 repl_backlog_first_byte_offset:0 #复制积压缓冲区偏移量大小 repl_backlog_histlen:0 #等于master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小

(3)将6383和6384的从节点挂接到6382主节点,有两种方式来实现,分为临时和永久两种方式,重启服务后临时方式的主从关系将消失,永久方式的主从启动后就会存在。

a.临时挂接,需要登录到6383和6384的客户端,使用slaveof master的IP master的端口来实现,完成后登录6382来使用info replication继续查看信息。

[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6383
# 临时挂接使用127.0.0.1 127.0.0.1:6383> slaveof 127.0.0.1 6382 OK 127.0.0.1:6383> quit [root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384
# 挂接 127.0.0.1:6384> slaveof 127.0.0.1 6382 OK 127.0.0.1:6384> quit [root@node01 /home/software/redis-3.2.11]# redis-cli -p 6382
# 查看信息,发现发生了变化 127.0.0.1:6382> info replication # Replication role:master # 角色依然为主 connected_slaves:2 # 有两个从节点,下面就是从节点信息 slave0:ip=127.0.0.1,port=6383,state=online,offset=43,lag=0 slave1:ip=127.0.0.1,port=6384,state=online,offset=43,lag=0 master_repl_offset:43 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:42

查看从节点信息,其中slave_repl_offset偏移量在主节点宕机后,会作为一个判断的依据,偏移量越大代表从节点上的数据越新,越有可能成为新的主节点。

[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6383
127.0.0.1:6383> info replication
# Replication
role:slave # 从节点
master_host:127.0.0.1 # master ip
master_port:6382 # master 端口
master_link_status:up # 与master的同步状态,up代表连接,down代表断开
master_last_io_seconds_ago:9 # 主节点多少秒没发送数据到从节点
master_sync_in_progress:0 # 主节点是否和从节点在同步
slave_repl_offset:323 # 从节点复制偏移量
slave_priority:100 # 从节点的优先级,默认100,可以修改
slave_read_only:1 # 从节点是否只读,1代表只读,代表只能查看不能删除修改数据
connected_slaves:0 # 连接的从节点个数
master_repl_offset:0 # 主节点复制偏移量
repl_backlog_active:0 # 同上
repl_backlog_size:1048576 # 同上
repl_backlog_first_byte_offset:0 # 同上
repl_backlog_histlen:0 # 同上

b.永久挂接,需要修改从节点redis.conf配置文件,启动服务后,使用上面命令查看,启动redis服务后就是主从关系,重启后依然是主从关系。

# 添加永久配置,这里使用实际的ip,当前centos6.5的ip为192.168.200.140
# slaveof <masterip> <masterport> slaveof 192.168.200.140 6382

(4)主节点写入数据,查看从节点,发现成功的同步了主节点的数据。

# 主节点添加一个hash类型数据
127.0
.0.1:6382> hmset messi score 11 assist 10 shoot 5 OK 127.0.0.1:6382> hmget messi score assist shoot 1) "11" 2) "10" 3) "5" 127.0.0.1:6382> quit You have new mail in /var/spool/mail/root
# 6383从节点有复制到数据 [root@node01
/home/software/redis-3.2.11]# redis-cli -p 6383 127.0.0.1:6383> keys * 1) "messi" 127.0.0.1:6383> hmget messi score assist shoot 1) "11" 2) "10" 3) "5" 127.0.0.1:6383> quit
# 6384从节点也有复制到数据 [root@node01
/home/software/redis-3.2.11]# redis-cli -p 6384 127.0.0.1:6384> keys * 1) "messi"

另外从节点默认配置是只读的,想删除上面的数据会报错提示只读,只能从主节点来删除数据。

127.0.0.1:6384> flushdb
(error) READONLY You can't write against a read only slave.

从redis2.6开始,配置文件里从节点默认是只读。

Redis单个分片高可用&amp;哨兵集群第3张

哨兵集群故障转移

在上面配置了主从关系后,如果将6382主节点宕机掉,查看从节点信息,发现依然显示是从节点。这样只实现了主从复制,不能实现主从故障转移和替换,即不能实现主节点挂掉,从节点顶上去提供服务的功能,如果使用SharedJedisPool来连接,还需要修改连接的ip和端口,这样会很麻烦。

127.0.0.1:6383> info replication
# Replication
role:slave # 依然是从节点
master_host:127.0.0.1
master_port:6382
master_link_status:down # 主节点宕机了,从节点依然是从节点
...省略

这样就需要一个监听者来管理这些节点,redis提供了这样的角色,就是哨兵sentinal,启动哨兵进程后,就可以实现监听管理,以下是它的原理图。

(1)master和slave之间实现主从复制。

(2)哨兵启动后,会连接master,通过10秒一次的频率,会通过向master发送INFO命令来获取master和slave的信息,保存到内存后持久化到sentinal配置文件中。

(3)哨兵(这里只有一个)监听所有的master和slave,会通过每秒一次的PING命令,确认master和slave是否还正常"活着"。

Redis单个分片高可用&amp;哨兵集群第4张     

(4)当一个哨兵检测到master宕机后,会被认为是sdown,即subjective down(主观宕机),当哨兵集群中的大多数(过半)认为master down,才会认为是odown,即objective down(客观宕机,真的宕机),这个时候就需要投票选举新的master了。

(5)当某个master被判定为主观宕机后,接下来哨兵集群内部会进行选举,也是通过过半机制选举出一个领头哨兵,并由这个领头哨兵来进行主节点的故障转移。

(6)哨兵选举出来后,接下来会从从slave中选取出一个合格的节点来作为新的master,并且其他的slave改为和这个新的master进行复制,原master节点会被设置为新master的slave,当它恢复后会作为slave挂接到新的master上。

(7)领头哨兵选举新的master会经历重重筛选,它会先所有的slave的信息保存到一个列表中。

(8)剔除列表中下线或断线的的slave,保存剩下的salve都是"活的"。

(9)剔除列表中最近5s都没有回复领头哨兵INFO命令的slave,保存剩下的slave都是最近能正常通信的。

(10)剔除和原master断开连接超过down-after-milliseconds*10毫秒的slave,这个值默认是30s,这样剔除的作用的是保证剩下的slave都是最近和原master有连接的,相比很早断开连接的salve,这些slave上的数据会更具有时效性。

# 这个时间配置在sentinel.conf文件中
# sentinel down-after-milliseconds <master-name> <milliseconds> # # Number of milliseconds the master (or any attached slave or sentinel) should # be unreachable (as in, not acceptable reply to PING, continuously, for the # specified period) in order to consider it in S_DOWN state (Subjectively # Down). # # Default is 30 seconds.

(11)通过优先级的大小对剩下的slave进行排序,优先级最高的slave获取到继续选举的权利。

(12)如果剩下的slave优先级相同的有多个,会继续比较slave_repl_offset,即复制偏移量,会选出复制偏移量最大的slave,偏移量越大代表从原master复制到的数据更具时效性。

(13)如果剩下的slave优先级最高,复制偏移量最大的有多个,会继续比较运行ID,选出运行ID最小的slave作为新的master。

(14)当新的master选举出来后,领头哨兵会给它发送SLAVEOF no one命令,即不会让它成为任何一个节点的slave。并按照每秒1次的高频率来给它发送INFO命令,如果返回的role信息为master,则领头哨兵才会放心的认为已经选举出新的master了。

Redis单个分片高可用&amp;哨兵集群第5张

配置哨兵集群

下面在上面主从复制功能的基础上,添加哨兵集群、实现对一个分片的高可用 。

(1)准备sentinal.conf文件,修改端口号,保护模式设置为no,并设置监听的主节点。

# 先准备三份配置文件
[root@node01 /home/software/redis-3.2.11]# cp sentinel.conf sentinel26379.conf [root@node01 /home/software/redis-3.2.11]# cp sentinel.conf sentinel26380.conf [root@node01 /home/software/redis-3.2.11]# cp sentinel.conf sentinel26381.conf

以26379的哨兵为例,除了修改保护模式为no,端口号修改为对应端口号外,还需要配置监听主节点逻辑,其中监听主节点配置各个字段的解释:

sentinal monitor:代表这个参数的key;

mymaster:代表master的代号;

ip:master的ip;

redis-port:master的端口号,这里的初始主节点是6382;

quorum:主观投票下限次数,如果是3个哨兵集群,则是2,如果是5个哨兵集群,则是3,采取过半机制

# 保护模式设置为no
protected-mode no # 端口号,三个文件分别修改为26379、26380、26381 # port <sentinel-port> # The port that this sentinel instance will run on port 26379 # 配置监听主节点 # sentinel monitor <master-name> <ip> <redis-port> <quorum>
# ip写主机的实际ip,写127.0.0.1后面使用api会连不上 sentinel monitor mymaster 192.168.200.140 6382 2

(2)在master和slave都启动的情况下,启动一个哨兵,观察控制台情况。发现哨兵启动后,就通过master,获取到了两个salve的信息,这是因为调用了info命令。

[root@node01 /home/software/redis-3.2.11]# redis-sentinel sentinel26379.conf
1680:X 09 Dec 13:10:11.322 * Increased maximum number of open files to 10032 (it was originally set to 1024).
                _._
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 3.2.11 (00000000/0) 64 bit
  .-`` .-```.  ```/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 1680
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |           http://redis.io
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'
              `-.__.-'

1680:X 09 Dec 13:10:11.324 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
# 生成的myid会持久化到配置文件中
1680:X 09 Dec 13:10:11.326 # Sentinel ID is 6d9373993f231a33686485a7e3baf205ff98d7b7
# 监听6382的节点
1680:X 09 Dec 13:10:11.326 # +monitor master mymaster 192.168.200.140 6382 quorum 2
# 通过6382 master主节点调用info命令获取到slave节点的信息 1680:X 09 Dec 13:10:11.326 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1680:X 09 Dec 13:10:11.329 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382

配置文件中新增myid

Redis单个分片高可用&amp;哨兵集群第6张

(3)开启另外两个哨兵,发现启动后,26379启动的控制台里会添加提示获取到其它两台的哨兵的信息,其它两台也是如此。

26379的关于哨兵的日志

# 发现了26380和26381
1931
:X 09 Dec 13:25:48.461 * +sentinel sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382 1931:X 09 Dec 13:25:55.809 * +sentinel sentinel 2b402bba6fde9ba010a8f7cd9b2106356aad17cc 192.168.200.140 26381 @ mymaster 192.168.200.140 6382

26380的部分日志

1934:X 09 Dec 13:25:46.323 # Sentinel ID is 931e5386f5d0e31a70cc14a5aa418d68fb46feb4
1934:X 09 Dec 13:25:46.323 # +monitor master mymaster 192.168.200.140 6382 quorum 2
1934:X 09 Dec 13:25:46.323 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382
1934:X 09 Dec 13:25:46.324 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382
# 发现26379和26381 1934:X 09 Dec 13:25:46.975 * +sentinel sentinel 6d9373993f231a33686485a7e3baf205ff98d7b7 192.168.200.140 26379 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:25:55.809 * +sentinel sentinel 2b402bba6fde9ba010a8f7cd9b2106356aad17cc 192.168.200.140 26381 @ mymaster 192.168.200.140 6382

26381的部分日志

1937:X 09 Dec 13:25:53.763 # Sentinel ID is 2b402bba6fde9ba010a8f7cd9b2106356aad17cc
1937:X 09 Dec 13:25:53.763 # +monitor master mymaster 192.168.200.140 6382 quorum 2
1937:X 09 Dec 13:25:53.765 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382
1937:X 09 Dec 13:25:53.767 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382
# 发现26379和26380 1937:X 09 Dec 13:25:54.715 * +sentinel sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382 1937:X 09 Dec 13:25:55.159 * +sentinel sentinel 6d9373993f231a33686485a7e3baf205ff98d7b7 192.168.200.140 26379 @ mymaster 192.168.200.140 6382

可以看到哨兵通过连接主节点6382,获取到了从节点的信息,并且还获取到其它哨兵的信息,获取到的信息会持久化到配置文件中,添加到文件尾部,以26379为例。

Redis单个分片高可用&amp;哨兵集群第7张

(4)将6382主节点宕机,观察每个哨兵控制台情况。

26379的部分日志

# 26379判断6382主观宕机
1931
:X 09 Dec 13:32:56.471 # +sdown master mymaster 192.168.200.140 6382
# new-epoch 1,1代表逻辑时钟值,类似zookeeper的epoch,是自增的整数,使用一个计数器来实现。 1931:X 09 Dec 13:32:56.595 # +new-epoch 1
# 选举领头哨兵,选举了尾部为feb4的哨兵,即26380端口号的哨兵 1931:X 09 Dec 13:32:56.596 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1 1931:X 09 Dec 13:32:56.934 # +config-update-from sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382
# 切换master,6382到6384,这个时候已经选举出新的master 1931:X 09 Dec 13:32:56.934 # +switch-master mymaster 192.168.200.140 6382 192.168.200.140 6384
# 6382和6383变成slave,6384变成master 1931:X 09 Dec 13:32:56.934 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6384 1931:X 09 Dec 13:32:56.934 * +slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
# 判断6382主观宕机 1931:X 09 Dec 13:33:26.983 # +sdown slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384

26380的部分日志

# 判断6382主观宕机
1934
:X 09 Dec 13:32:56.490 # +sdown master mymaster 192.168.200.140 6382
# 有过半的哨兵判断6382主观宕机,状态变成客观宕机odown 1934:X 09 Dec 13:32:56.591 # +odown master mymaster 192.168.200.140 6382 #quorum 2/2
# 进入新的纪元 1934:X 09 Dec 13:32:56.591 # +new-epoch 1
# 尝试故障转移 1934:X 09 Dec 13:32:56.591 # +try-failover master mymaster 192.168.200.140 6382
# 选举尾部为feb4的哨兵为领头哨兵,即选举自己 1934:X 09 Dec 13:32:56.593 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1
# 有过半选举26380的哨兵为领头哨兵,则领头哨兵开始进行master筛选。 1934:X 09 Dec 13:32:56.596 # 2b402bba6fde9ba010a8f7cd9b2106356aad17cc voted for 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1 1934:X 09 Dec 13:32:56.596 # 6d9373993f231a33686485a7e3baf205ff98d7b7 voted for 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1 1934:X 09 Dec 13:32:56.669 # +elected-leader master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.669 # +failover-state-select-slave master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.728 # +selected-slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.728 * +failover-state-send-slaveof-noone slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.787 * +failover-state-wait-promotion slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.885 # +promoted-slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.885 # +failover-state-reconf-slaves master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.934 * +slave-reconf-sent slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:57.739 # -odown master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:57.951 * +slave-reconf-inprog slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:57.951 * +slave-reconf-done slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:58.042 # +failover-end master mymaster 192.168.200.140 6382
# 将6382成功切换为6384 1934:X 09 Dec 13:32:58.042 # +switch-master mymaster 192.168.200.140 6382 192.168.200.140 6384
# 将slave挂接到新的master上,并且将原master 6382变成了从节点slave 1934:X 09 Dec 13:32:58.042 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6384 1934:X 09 Dec 13:32:58.042 * +slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
# 6382还没有恢复,认定为主观宕机
1934:X 09 Dec 13:33:28.092 # +sdown slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384

26381的部分日志

1937:X 09 Dec 13:32:56.563 # +sdown master mymaster 192.168.200.140 6382
1937:X 09 Dec 13:32:56.595 # +new-epoch 1
# 选举领头哨兵,本次选举三个哨兵都是选择26380 1937:X 09 Dec 13:32:56.596 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1
# 过半认为6382宕机,则判定原master6382客观宕机 1937:X 09 Dec 13:32:56.639 # +odown master mymaster 192.168.200.140 6382 #quorum 3/2 1937:X 09 Dec 13:32:56.639 # Next failover delay: I will not start a failover before Mon Dec 9 13:38:56 2019 1937:X 09 Dec 13:32:56.935 # +config-update-from sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382 1937:X 09 Dec 13:32:56.935 # +switch-master mymaster 192.168.200.140 6382 192.168.200.140 6384 1937:X 09 Dec 13:32:56.935 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6384 1937:X 09 Dec 13:32:56.935 * +slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384 1937:X 09 Dec 13:33:26.968 # +sdown slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384

发现master从6382换成了6384,目前有6383一个从节点。

[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384
127.0.0.1:6384> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.200.140,port=6383,state=online,offset=26451,lag=0
master_repl_offset:26741
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:26740

(5)将6382节点恢复,发现它会作为从节点挂接到新的主节点6384上。

1931:X 09 Dec 13:36:10.239 * +convert-to-slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384

继续登录6384,发现6382变成了salve。

[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384
127.0.0.1:6384> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.200.140,port=6383,state=online,offset=49089,lag=1
slave1:ip=192.168.200.140,port=6382,state=online,offset=49234,lag=0
master_repl_offset:49234
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:49233

哨兵API的操作

有了哨兵了,可以通过连接JedisSentinelPool,来连接哨兵集群,然后通过它来获取到Jedis实例对象,这个对象就是对外提供服务的master节点。

package com.boe;

import java.util.HashSet;
import java.util.Set;

import org.junit.Test;

import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;

public class SentinelTest {
    @Test
    public void sentinel(){
        //多个哨兵之间没有监控关系,顺序遍历,哪个能通就走哪个,不通,再检查下一个哨兵
        Set<String> sentinels = new HashSet<String>();
        sentinels.add(new HostAndPort("192.168.200.140",26379).toString());
        sentinels.add(new HostAndPort("192.168.200.140",26380).toString());
        sentinels.add(new HostAndPort("192.168.200.140",26381).toString());
        
        JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);
        //这一句很有用,能获取到是否有master节点宕机
        System.out.println("当前master:" + pool.getCurrentHostMaster());
        //通过哨兵获取 jedis 连接的就是master
        Jedis jedis = pool.getResource();
        //jedis.auth("123456");
        jedis.set("name", "messi");
        System.out.println(jedis.get("name"));
    }
}

现在master节点是6384,它不宕机的情况下,是可以对外提供服务的。

Redis单个分片高可用&amp;哨兵集群第8张

 查看redis,数据三个节点均有。

127.0.0.1:6384> get name
"messi"

现在把6384给它宕机,继续使用上述哨兵来连接 ,修改代码,将set的key-value做修改,然后尝试连接,发现master变成了6382。

Redis单个分片高可用&amp;哨兵集群第9张

哨兵日志

1931:X 09 Dec 13:40:21.218 # +sdown master mymaster 192.168.200.140 6384
# 6384宕机,又会新一轮的选举,纪元为2 1931:X 09 Dec 13:40:21.302 # +new-epoch 2 1931:X 09 Dec 13:40:21.320 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 2 1931:X 09 Dec 13:40:21.948 # +config-update-from sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6384
# 6382成为新的master,6384又变成了slave
1931:X 09 Dec 13:40:21.948 # +switch-master mymaster 192.168.200.140 6384 192.168.200.140 6382 1931:X 09 Dec 13:40:21.948 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1931:X 09 Dec 13:40:21.948 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1931:X 09 Dec 13:40:52.013 # +sdown slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382

以上是对分片高可用,以及哨兵集群及故障转移的整理,记录一下后续查看用,后面继续补充redis-cluster的相关内容。

参考博文

(1)https://blog.csdn.net/mysqldba23/article/details/68066322 info replication详解

(2)https://www.cnblogs.com/fu-yong/p/9252837.html 哨兵

(3)https://blog.csdn.net/u012240455/article/details/81843714 哨兵 

(4)《redis设计与实践》主节点故障转移

免责声明:文章转载自《Redis单个分片高可用&amp;amp;哨兵集群》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇docker通过dockerfile打java项目镜像podman wsl2在windows重启后出错下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

Git Push:error: Couldn't set refs/remotes/origin/master;error: update_ref failed for ref 'refs/remot

作者:荒原之梦 原文链接:http://zhaokaifeng.com/?p=543今天使用Git Push代码时产生错误: Rename from 'XXXX/.git/refs/remotes/origin/master.lock' to 'XXX/.git/refs/remotes/origin/master' failed. Should I...

Docker最全教程——从理论到实战(六)

Docker最全教程——从理论到实战(六) 托管到腾讯云容器服务托管到腾讯云容器服务,我们的公众号“magiccodes”已经发布了相关的录屏教程,大家可以结合本篇教程一起查阅。   自建还是托管? 在开始之前,我们先来讨论一个问题——是自建容器服务还是托管到云容器服务? 这里笔者建议大家托管到云容器服务。对于中小团队来说,很多情况下,团队中的运维人员是缺...

解决redis显示中文为乱码问题

如果你是用的windows cmd,还是乱码,要设置窗口的编码 输入:chcp 65001 就是换成UTF-8代码页,在命令行标题栏上点击右键,选择"属性"->"字体",将字体修改为True Type字体"Lucida Console",然后点击确定将属性应用到当前窗口 C:Redis>redis-cli.exe --raw -h 10.*.3...

Python使用Redis

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。Redis支持存储的value类型包括字符串(String), 哈希(Hash), 列表(list), 集合(set) 和 有序集合(sorted set)。 Redis官方文档:https://redis.io Red...

redis中的key的复制

redis中Set集合SortSet有序集合的复制 本文链接:https://blog.csdn.net/chwshuang/article/details/52850093 redis中Set集合SortSet有序集合的复制 redis集合类型中是没有复制命令的,我所说的复制,是通过redis 的其他指令来实现 需求:将key1的内容全部拷贝...

Docker中运行redis报错误: Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied

错误信息: 1:M 23 Dec 2021 19:53:02.058 * Background saving started by pid 1848 1848:C 23 Dec 2021 19:53:02.058 # Failed opening the RDB file backup.db (in server root dir /etc) for sa...