哨兵模式搭建redis主从复制集群

最新推荐文章于 2023-12-07 10:43:34 发布

四月丶丶

最新推荐文章于 2023-12-07 10:43:34 发布

阅读量515

点赞数

分类专栏： redis 文章标签： redis

本文链接：https://blog.csdn.net/rzpy_qifengxiaoyue/article/details/109211964

版权

redis 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

文章目录

1. 哨兵模式简介

哨兵(sentinel)是Redis的高可用性(High Availability)的解决方案: 由一个或多个sentinel实例组成sentinel集群，可以监视一个或多个主服务器和多个从服务器。当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。

2. 集群部署方案

在这里插入图片描述

3. 集群搭建配置

本次示例在一台机器上采用伪分布式的方式部署

3.1 安装redis-5.0.5

参考地址：https://blog.csdn.net/rzpy_qifengxiaoyue/article/details/107585283

3.2 主从配置

[root@rpp ~]# cd /usr/local/
[root@rpp local]# mkdir -p redis-ms/redis-master
[root@rpp local]# mkdir -p redis-ms/redis-slaver1
[root@rpp local]# mkdir -p redis-ms/redis-slaver2
[root@rpp local]# mkdir -p redis-ms/redis-sentinel1
[root@rpp local]# mkdir -p redis-ms/redis-sentinel2
[root@rpp local]# mkdir -p redis-ms/redis-sentinel3

Redis-Master :127.0.0.1 6380

#进入redis安装目录
[root@rpp ~]# cd /usr/local/redis
make install PREFIX=/usr/local/redis-ms/redis-master
cp /usr/local/redis/redis.conf /usr/local/redis-ms/redis-master
#修改redis.conf
port 6380
# 将`daemonize`由`no`改为`yes` 
daemonize yes
# 默认绑定的是回环地址，默认不能被其他机器访问 
# bind 127.0.0.1
# 是否开启保护模式，由yes该为no 
protected-mode no

Redis-Slaver1:127.0.0.1 6381

cp -r /usr/local/redis-ms/redis-master/* /usr/local/redis-ms/redis-slaver1 
#修改配置文件
vim /usr/local/redis-ms/redis-slaver1/redis.conf
port 6381
replicaof 127.0.0.1 6380

Redis-Slaver2:127.0.0.1 6382

cp -r /usr/local/redis-ms/redis-master/* /usr/local/redis-ms/redis-slaver2 
#修改配置文件
vim /usr/local/redis-ms/redis-slaver2/redis.conf
port 6382
replicaof 127.0.0.1 6380

3.3 哨兵配置

Redis-Sentinel1:127.0.0.1 26379

cp -r /usr/local/redis-ms/redis-master/* /usr/local/redis-ms/redis-sentinel1 
#拷贝sentinel.conf 配置文件并修改
cp /usr/local/redis/sentinel.conf /usr/local/redis-ms/redis-sentinel1
# 哨兵sentinel实例运行的端口 默认26379 
port 26379
# 将`daemonize`由`no`改为`yes` 
daemonize yes

# 哨兵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秒，改成3秒 
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 3000
# 这个配置项指定了在发生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

Redis-Sentinel2:127.0.0.1 26380

cp -r /usr/local/redis-ms/redis-sentinel1/* /usr/local/redis-ms/redis-sentinel2 
#修改sentinel.conf
vim /usr/local/redis-ms/redis-sentinel2/sentinel.conf
port 26380

Redis-Sentinel3:127.0.0.1 26381

cp -r /usr/local/redis-ms/redis-sentinel1/* /usr/local/redis-ms/redis-sentinel3 
#修改sentinel.conf
vim /usr/local/redis-ms/redis-sentinel3/sentinel.conf
port 26381

3.4 依次启动服务

redis-master、redis-slaver1、redis-slaver2、redis-sentinel1、redis-sentinel2、redis-sentinel3

#启动redis-master和redis-slaver
在redis-master目录下 ./bin/redis-server redis.conf
在redis-slaver1目录下 ./bin/redis-server redis.conf
在redis-slaver2目录下 ./bin/redis-server redis.conf
#启动redis-sentinel 
在redis-sentinel1目录下 ./bin/redis-sentinel sentinel.conf
在redis-sentinel2目录下 ./bin/redis-sentinel sentinel.conf
在redis-sentinel3目录下./bin/redis-sentinel sentinel.conf

查看启动状态

[root@rpp redis-sentinel3]# ps -ef |grep redis                
root     29529     1  0 23:39 ?        00:00:00 ./bin/redis-server 0.0.0.0:6380
root     29559     1  0 23:39 ?        00:00:00 ./bin/redis-server 0.0.0.0:6381
root     29575     1  0 23:39 ?        00:00:00 ./bin/redis-server 0.0.0.0:6382
root     29644     1  0 23:40 ?        00:00:00 ./bin/redis-sentinel *:26379 [sentinel]
root     29674     1  0 23:40 ?        00:00:00 ./bin/redis-sentinel *:26380 [sentinel]
root     29720     1  0 23:40 ?        00:00:00 ./bin/redis-sentinel *:26381 [sentinel]
root     29743 26484  0 23:41 pts/3    00:00:00 grep --color=auto redis

3.5 查看集群信息

在主节点客户端执行info命令查看集群信息，如下

127.0.0.1:6380> info
# Server
redis_version:5.0.5
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:d828c6186d2762b0
redis_mode:standalone
os:Linux 3.10.0-957.21.3.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:29529
run_id:9be5ec63623c7f5a106c8a3e93fc20c52d43eaab
tcp_port:6380
uptime_in_seconds:777
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:9460014
executable:/usr/local/redis-ms/redis-master/./bin/redis-server
config_file:/usr/local/redis-ms/redis-master/redis.conf

# Clients
connected_clients:7
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# Memory
used_memory:2113576
used_memory_human:2.02M
used_memory_rss:2994176
used_memory_rss_human:2.86M
used_memory_peak:2194216
used_memory_peak_human:2.09M
used_memory_peak_perc:96.32%
used_memory_overhead:2059522
used_memory_startup:792504
used_memory_dataset:54054
used_memory_dataset_perc:4.09%
allocator_allocated:2133856
allocator_active:2441216
allocator_resident:7122944
total_system_memory:3777241088
total_system_memory_human:3.52G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.14
allocator_frag_bytes:307360
allocator_rss_ratio:2.92
allocator_rss_bytes:4681728
rss_overhead_ratio:0.42
rss_overhead_bytes:-4128768
mem_fragmentation_ratio:1.45
mem_fragmentation_bytes:922848
mem_not_counted_for_evict:0
mem_replication_backlog:1048576
mem_clients_slaves:33844
mem_clients_normal:183998
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:1
rdb_bgsave_in_progress:0
rdb_last_save_time:1603294781
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:1
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:417792
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0

# Stats
total_connections_received:9
total_commands_processed:4746
instantaneous_ops_per_sec:7
total_net_input_bytes:224073
total_net_output_bytes:1439214
instantaneous_input_kbps:0.37
instantaneous_output_kbps:3.37
rejected_connections:0
sync_full:1
sync_partial_ok:1
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:2
keyspace_misses:1
pubsub_channels:1
pubsub_patterns:0
latest_fork_usec:156
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=136498,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=136498,lag=1
master_replid:8dc1f397d723387b6328ba37c6abded94370d635
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:136498
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:136498

# CPU
used_cpu_sys:0.260864
used_cpu_user:0.315793
used_cpu_sys_children:0.001172
used_cpu_user_children:0.000000

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=11,expires=0,avg_ttl=0
127.0.0.1:6380>

127.0.0.1:26379> info
# Server
redis_version:5.0.5
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:d828c6186d2762b0
redis_mode:sentinel
os:Linux 3.10.0-957.21.3.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:29644
run_id:f23e1f9b157ef080bf8855d9deefb4a1b070bfa8
tcp_port:26379
uptime_in_seconds:1318
uptime_in_days:0
hz:11
configured_hz:10
lru_clock:9460618
executable:/usr/local/redis-ms/redis-sentinel1/./bin/redis-sentinel
config_file:/usr/local/redis-ms/redis-sentinel1/sentinel.conf

# Clients
connected_clients:3
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# CPU
used_cpu_sys:0.555261
used_cpu_user:0.682642
used_cpu_sys_children:0.000000
used_cpu_user_children:0.000000

# Stats
total_connections_received:3
total_commands_processed:3741
instantaneous_ops_per_sec:2
total_net_input_bytes:202550
total_net_output_bytes:22460
instantaneous_input_kbps:0.11
instantaneous_output_kbps:0.01
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6380,slaves=2,sentinels=3

4. 测试

4.1 主从复制

主从依次查询key ,master 6380 slaver1 6381

127.0.0.1:6380> get name1
(nil)

127.0.0.1:6381> get name1
(nil)

主服务器写入数据，从服务器查看

127.0.0.1:6380> set name1 a
OK
127.0.0.1:6380> get name1
"a"

127.0.0.1:6381> get name1
"a"

测试结果主从复制成功

4.2 故障切换

把主服务master关闭

[root@rpp redis]# ps -ef|grep redis
root     29529     1  0 Oct21 ?        00:00:01 ./bin/redis-server 0.0.0.0:6380
root     29559     1  0 Oct21 ?        00:00:00 ./bin/redis-server 0.0.0.0:6381
root     29575     1  0 Oct21 ?        00:00:00 ./bin/redis-server 0.0.0.0:6382
root     29644     1  0 Oct21 ?        00:00:01 ./bin/redis-sentinel *:26379 [sentinel]
root     29674     1  0 Oct21 ?        00:00:01 ./bin/redis-sentinel *:26380 [sentinel]
root     29720     1  0 Oct21 ?        00:00:01 ./bin/redis-sentinel *:26381 [sentinel]
root     30213 25644  0 Oct21 pts/1    00:00:00 ./redis-cli -p 6380
root     31892 26484  0 00:03 pts/3    00:00:00 ./redis-cli -p 26380
root     31968 31535  0 00:04 pts/4    00:00:00 grep --color=auto redis
[root@rpp redis]# kill -9 29529
[root@rpp redis]# ps -ef|grep redis
root     29559     1  0 Oct21 ?        00:00:00 ./bin/redis-server 0.0.0.0:6381
root     29575     1  0 Oct21 ?        00:00:00 ./bin/redis-server 0.0.0.0:6382
root     29644     1  0 Oct21 ?        00:00:01 ./bin/redis-sentinel *:26379 [sentinel]
root     29674     1  0 Oct21 ?        00:00:01 ./bin/redis-sentinel *:26380 [sentinel]
root     29720     1  0 Oct21 ?        00:00:01 ./bin/redis-sentinel *:26381 [sentinel]
root     30213 25644  0 Oct21 pts/1    00:00:00 ./redis-cli -p 6380
root     31892 26484  0 00:03 pts/3    00:00:00 ./redis-cli -p 26380
root     32059 31535  0 00:05 pts/4    00:00:00 grep --color=auto redis

登录客户端6381查看信息

127.0.0.1:6381> info
# Replication
role:slave
master_host:127.0.0.1
master_port:6382
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:303828
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:5234efe2b80aa660993474dc26d7505b4689d458
master_replid2:8dc1f397d723387b6328ba37c6abded94370d635
master_repl_offset:303828
second_repl_offset:290940
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:303828

# CPU
used_cpu_sys:0.467161
used_cpu_user:0.559959
used_cpu_sys_children:0.001200
used_cpu_user_children:0.000000

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=11,expires=0,avg_ttl=0
127.0.0.1:6381>

从 master_host:127.0.0.1 master_port:6382 可以看出主服务自动切换到6382

5. 执行流程

5.1 启动并初始化Sentinel

Sentinel是一个特殊的Redis服务器，不会进行持久化，Sentinel实例启动后每个Sentinel会创建2个连向主服务器的网络连接

命令连接:用于向主服务器发送命令，并接收响应;
订阅连接:用于订阅主服务器的—sentinel—:hello频道。

在这里插入图片描述
Sentinel默认每10s一次，向被监控的主服务器发送info命令，获取主服务器和其下属从服务器的信息。

当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器建立命令连接和订阅连接。在命令连接建立之后，Sentinel还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息。
在这里插入图片描述

5.2 向主服务器和从服务器发送消息(以订阅的方式)

默认情况下，Sentinel每2s一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息，消息中会携带Sentinel自身的信息和主服务器的信息。

PUBLISH _sentinel_:hello "< s_ip > < s_port >< s_runid >< s_epoch > < m_name > <m_ip >< m_port ><m_epoch>"

5.3 接收来自主服务器和从服务器的频道信息

当Sentinel与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令:

subscribe —sentinel—:hello

Sentinel彼此之间只创建命令连接，而不创建订阅连接，因为Sentinel通过订阅主服务器或从服务器，因为订阅的是同一个频道，一个Sentinel发送消息后，其他的Sentinel就可以接受到消息，这样就可以感知到新的Sentinel的加入，而一旦新Sentinel加入后，相互感知的Sentinel通过命令连接来通信就可以了。

5.4 检测主观下线状态

Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命令
实例在down-after-milliseconds毫秒内返回无效回复(除了+PONG、-LOADING、-MASTERDOWN外) 实例在down-after-milliseconds毫秒内无回复(超时)
Sentinel就会认为该实例主观下线(SDown)

5.5 检查客观下线状态

当一个Sentinel将一个主服务器判断为主观下线后，Sentinel会向同时监控这个主服务器的所有其他Sentinel发送查询命令，如下

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>

其他Sentinel回复

<down_state>< leader_runid >< leader_epoch >

Sentinel通过判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。

5.6 哨兵leader选举

当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法(raft)，选出一个Leader Sentinel去执行failover(故障转移)操作。

Raft

Raft协议是用来解决分布式系统一致性问题的协议。
Raft协议描述的节点共有三种状态:Leader, Follower, Candidate。
term:Raft协议将时间切分为一个个的Term(任期)，可以认为是一种“逻辑时间”。

选举流程:

Raft采用心跳机制触发Leader选举，系统启动后，全部节点初始化为Follower，term为0。
节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份，节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。一旦转化为Candidate，该节点立即开始下面几件事情:

增加自己的term。
启动一个新的定时器。
给自己投一票。
向所有其他节点发送RequestVote，并等待其他节点的回复。

如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送 AppendEntries，告知自己成为了Leader。

每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己， Follower会投给第一个收到RequestVote的节点。

Raft协议的定时器采取随机超时时间，这是选举Leader的关键。
在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

Sentinel的leader选举流程

某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
如果该Sentinel还没投过票，那么它就成为Candidate。
Sentinel需要完成几件事情:

更新故障转移状态为start
当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch。
给自己投一票(leader、leader_epoch)

当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者;(通过判断epoch)
Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。

5.7 故障转移

当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作，主要有三个步骤:

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