Redis 主从复制和哨兵模式

一、概念

        主从复制,是指将一台 Redis 服务器的数据,复制到其他的 Redis 服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower)。数据的复制是单向的,只能由主节点到从节点。Master 以写为主,Slave 以读为主。

        默认情况下,每台 Redis 服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。

1.1 主要作用

        1、数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。

        2、故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。

        3、负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写 Redis 数据时应用连接主节点,读 Redis 数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高 Redis 服务器的并发量。

        4、高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是 Redis 高可用的基础。

1.2 单台瓶颈

        一般来说,要将 Redis 运用于工程项目中,只使用一台 Redis 是万万不能的,原因如下:

        1、从结构上,单个 Redis 服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大。

        2、从容量上,单个 Redis 服务器内存容量有限,就算一台 Redis 服务器内存容量为 256G,也不能将所有内存用作 Redis 存储内存,一般来说,单台 Redis 最大使用内存不应该超过 20G

        电商网站上的商品,一般都是一次上传,无数次浏览的,说专业点也就是"多读少写"。对于这种场景,我们可以使如下这种架构:

        主从复制,读写分离80% 的情况下都是在进行读操作,减缓服务器的压力,在架构中经常使用。(最低需要一主二从)

二、环境配置

2.1 查看信息

        通过输入 info replication  命令可以查看当前 redis 库的信息,如下所示


127.0.0.1:6379> info replication                           # 查看当前库的信息
# Replication
role:master                                                # 当前角色 master
connected_slaves:0                                         # 没有从机
master_failover_state:no-failover
master_replid:54a28e688e4551d9699b335c17a0deb9c8d06467
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

2.2 复制文件

        复制 redis 的配置文件,复制三份,如下所示

[root@localhost myredis]# ls
redis.conf
[root@localhost myredis]# cp redis.conf redis79.conf
[root@localhost myredis]# cp redis.conf redis80.conf
[root@localhost myredis]# cp redis.conf redis81.conf
[root@localhost myredis]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf

2.3 修改文件

        需要修改上面复制的三个配置文件信息,需要修改的内容如下所示:

# 三份文件的端口号分别为 6379、6380、6381
port 6379# pid 名字
pidfile "/var/run/redis_6379.pid"# log 文件名字
logfile "6379.log"# dump.pid 的名字
dbfilename "dump6379.rdb"

2.4 启动测试

        上面都配置完毕后,3 个服务通过 3 个不同的配置文件开启,我们的准备环境就 OK 了!

# 第一台服务器启动
[root@localhost bin]# redis-server myredis/redis79.conf 
[root@localhost bin]# ls
6379.log  appendonlydir  dump.rdb  myredis  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server
[root@localhost bin]# redis-cli -p 6379
127.0.0.1:6379> # 第二台服务器启动
[root@localhost bin]# redis-server myredis/redis80.conf 
[root@localhost bin]# ls
6379.log  6380.log  appendonlydir  dump.rdb  myredis  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server
[root@localhost bin]# redis-cli -p 6380
127.0.0.1:6380> # 第三台服务器启动
[root@localhost bin]# redis-server myredis/redis81.conf 
[root@localhost bin]# ls
6379.log  6380.log  6381.log  appendonlydir  dump.rdb  myredis  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server
[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> 

        查看 redis 的进程,查看是否完全启动成功。 如下所示:

[root@localhost bin]# ps -ef | grep redis
root      62142      1  0 00:33 ?        00:00:13 redis-server 127.0.0.1:6379
root      63363      1  0 01:54 ?        00:00:00 redis-server 127.0.0.1:6380
root      63376      1  0 01:54 ?        00:00:00 redis-server 127.0.0.1:6381
root      63382  56368  0 01:54 pts/2    00:00:00 redis-cli -p 6379
root      63391  57550  0 01:55 pts/3    00:00:00 redis-cli -p 6380
root      63392  63102  0 01:55 pts/1    00:00:00 redis-cli -p 6381
root      63394  63141  0 01:55 pts/4    00:00:00 grep --color=auto redis

三、一主二从

3.1 节点信息查看

        三台 redis 服务器,默认都是 Master 节点,如下图所示

# 第一台服务器查看节点信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:54a28e688e4551d9699b335c17a0deb9c8d06467
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0# 第二台服务器查看节点信息
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:5fa97c2e9e96b6ba5bc275a7a1c8c9126112ff03
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0# 第三台服务器查看节点信息
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:2187b763138a4c5e77b58c77d4702f4f6132eaa2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3.2 配置从机

        使用 slaveof 命令使 master 节点变为从节点。

# 使用 slaveof 命令使主节点变为从节点
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
(1.35s)# 再次查看当前的节点信息,发现变为了从节点
127.0.0.1:6380> info replication
# Replication
role:slave               # 当前的角色
master_host:127.0.0.1    # 可以看到主机信息
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_read_repl_offset:0
slave_repl_offset:0
master_link_down_since_seconds:-1
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:5fa97c2e9e96b6ba5bc275a7a1c8c9126112ff03
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0# 使用 slaveof 命令使主节点变为从节点
127.0.0.1:6381> slaveof 127.0.0.1 6379
OK
# 再次查看当前的节点信息,发现变为了从节点
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:168
slave_repl_offset:168
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:6ccdf51ea4dec3fbabc8fd94fdfdb4cf00856171
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:168
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:169
repl_backlog_histlen:0# 在主机上重新查看节点的信息,发现多了两个从机的信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=238,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=238,lag=0
master_failover_state:no-failover
master_replid:6ccdf51ea4dec3fbabc8fd94fdfdb4cf00856171
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:238
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:238

3.3 真实的主从配置

        真实的主从配置应该是在配置文件中配置的,只有在配置文件中配置才是永久的,我们上面使用命令的配置是暂时的,一旦某一个节点关机,那么也就失去了主从的配置。

3.4 主从节点测试

3.4.1 主从节点特点

        主节点可以写从节点不可以写只能读。主节点中的所有信息和数据,都会自动被从节点保存。

# 主节点可以进行写操作
127.0.0.1:6379> set k1 v1
OK# 从节点1可以查看所有的信息
# 但是无法进行写的操作
127.0.0.1:6380> clear
127.0.0.1:6380> keys *
1) "k1"
127.0.0.1:6380> get k1
"v1"
127.0.0.1:6380> set k2 v2
(error) READONLY You can t write against a read only replica.# 从节点2可以查看所有的信息
127.0.0.1:6381> get k1
"v1"

3.4.2 主节点重连测试

        主机断开连接,从机依旧连接到主机,就是无法进行写操作了。这个时候如果主机回来了,从机依旧可以直接获取到主机写的信息。

# 首先关闭主机
127.0.0.1:6379> shutdown
not connected> exit
# 重新开启主机并 set 值
[root@localhost bin]# redis-server myredis/redis79.conf 
[root@localhost bin]# redis-cli -p 6379
127.0.0.1:6379> set k2 v2
OK# 可以在从机获取到主机 set 的值
127.0.0.1:6380> get k2
"v2"

3.4.2 从节点重连测试

        如果使用命令行来配置的主从,这个时候如果从机重启了,从机就会变回主机。只要通过命令的方式再变回为从机,从机立马就可以获取到主机的所有值

127.0.0.1:6381> info replication
# Replication
role:slave                          # 当前的角色是从机
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_read_repl_offset:528
slave_repl_offset:528
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:528
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:528# 进行重启操作
127.0.0.1:6381> shutdown
not connected> exit
[root@localhost bin]# redis-server myredis/redis81.conf 
[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:master                         # 当前的角色是主机            
connected_slaves:0
master_failover_state:no-failover
master_replid:2bd7531932a454bc6c492f04a1a96abd4a897855
master_replid2:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_repl_offset:542
second_repl_offset:543
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:543
repl_backlog_histlen:0

3.5 复制原理

        Slave 启动成功连接到 master 后会向 master 发送一个 sync 命令。

        master 接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master 将传送整个数据文件到 slave,并完成一次完全同步。

        全量复制:而 slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中。

        增量复制Master 继续将新的所有收集到的修改命令依次传给 slave,完成同步但是只要是重新连接 master,一次完全同步(全量复制)将被自动执行,我们的数据一定可以在从机中看到。

3.6 层层链路

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

# 配置客户端3变为客户端2的从机
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
# 查看当前的从机的信息
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_read_repl_offset:5386
slave_repl_offset:5386
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5386
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:5359
repl_backlog_histlen:28# 此时查看客户端1的节点信息
# 此时的客户端1只剩下6380一个节点
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=5526,lag=0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5526
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5526# 查看下最特殊的客户端2
# 我们发现他还是一个从节点,依旧无法进行写入操作
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_read_repl_offset:5610
slave_repl_offset:5610
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=5610,lag=0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5610
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5610# 客户端1进行写入
127.0.0.1:6379> set k6 v6
OK# 客户端2可以查询到
127.0.0.1:6380> get k6
"v6"# 客户端3也可以查询到
127.0.0.1:6381> get k6
"v6"

3.7 谋朝篡位

        一主二从的情况下,如果主机断了,从机可以使用命令 SLAVEOF NO ONE 将自己改为主机!这个时候其余的从机链接到这个节点。对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能,并从从属服务器转变回主服务器,原来同步所得的数据集不会被丢弃。

        即使主机再回来,也只是一个光杆司令了,从机为了正常使用跑到了新的主机上!

# 断开主节点
127.0.0.1:6379> shutdown
not connected> exit# 从节点执行命令,发现自己变为了主节点
127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=6045,lag=1
master_failover_state:no-failover
master_replid:6876480e76af2999855e6571bc7de430a0cc4f02
master_replid2:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_repl_offset:6045
second_repl_offset:6018
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:6045

四、哨兵模式

4.1 概念

        主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis 2.8 开始正式提供了 Sentinel(哨兵) 架构来解决这个问题。

        谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

        哨兵模式是一种特殊的模式,首先 Redis 提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。原理是哨兵通过发送命令,等待 Redis 服务器响应,从而监控运行的多个 Redis 实例。

这里的哨兵有两个作用:

        1、通过发送命令,让 Redis 服务器返回监控其运行状态,包括主服务器和从服务器。

        2、当哨兵监测到 master 宕机,会自动将 slave 切换成 master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

        然而一个哨兵进程对 Redis 服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

        假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行 failover 过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。 

4.2 测试

        我们目前的状态是一主二从,下面的测试是基于这个状态。

4.2.1 创建 sentinel 的配置文件

# 创建 sentinel.conf 文件
[root@localhost myredis]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf
[root@localhost myredis]# vim sentinel.conf
[root@localhost myredis]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf  sentinel.conf# sentinel.conf 内容如下所示
# sentinel monitor 被监控的名称 ip port 1
# 上面最后一个数字1,表示主机挂掉后 slave 投票看让谁接替成为主机,得票数多少后成为主机
sentinel monitor myredis 127.0.0.1 6379 1

4.2.2 启动 sentinel 进程

# 输入命令启动 sentinel
[root@localhost bin]# redis-sentinel myredis/sentinel.conf 
68012:X 30 Aug 2023 19:44:25.745 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
68012:X 30 Aug 2023 19:44:25.745 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
68012:X 30 Aug 2023 19:44:25.745 * Redis version=7.2.0, bits=64, commit=00000000, modified=0, pid=68012, just started
68012:X 30 Aug 2023 19:44:25.745 * Configuration loaded
68012:X 30 Aug 2023 19:44:25.745 * Increased maximum number of open files to 10032 (it was originally set to 1024).
68012:X 30 Aug 2023 19:44:25.745 * monotonic clock: POSIX clock_gettime_._                                                  _.-``__ ''-._                                             _.-``    `.  `_.  ''-._           Redis 7.2.0 (00000000/0) 64 bit.-`` .-```.  ```\/    _.,_ ''-._                                  (    '      ,       .-`  | `,    )     Running in sentinel mode|`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379|    `-._   `._    /     _.-'    |     PID: 68012`-._    `-._  `-./  _.-'    _.-'                                   |`-._`-._    `-.__.-'    _.-'_.-'|                                  |    `-._`-._        _.-'_.-'    |           https://redis.io       `-._    `-._`-.__.-'_.-'    _.-'                                   |`-._`-._    `-.__.-'    _.-'_.-'|                                  |    `-._`-._        _.-'_.-'    |                                  `-._    `-._`-.__.-'_.-'    _.-'                                   `-._    `-.__.-'    _.-'                                       `-._        _.-'                                           `-.__.-'                                               68012:X 30 Aug 2023 19:44:25.746 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
68012:X 30 Aug 2023 19:44:27.425 * Sentinel new configuration saved on disk
68012:X 30 Aug 2023 19:44:27.425 * Sentinel ID is 7d49ccc2c94c126d96432b3ee075b37bbc4e6ba4
68012:X 30 Aug 2023 19:44:27.443 # +monitor master myredis 127.0.0.1 6379 quorum 1
68012:X 30 Aug 2023 19:44:27.519 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
68012:X 30 Aug 2023 19:44:27.522 * Sentinel new configuration saved on disk
68012:X 30 Aug 2023 19:44:27.522 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
68012:X 30 Aug 2023 19:44:27.524 * Sentinel new configuration saved on disk

4.2.3 断开测试

        如果主节点断开了,这个时候就会从从机中随机选择一个服务器作为主节点(这里面有一个投票算法)

        如果主机此时回来了,只能归并到新的主机下,当作从机,这就是哨兵模式的规则。

# 关闭主节点
127.0.0.1:6379> shutdown
(0.98s)
not connected> exit# 查看从节点1的信息
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:25095
slave_repl_offset:25095
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:a7529ac9efada9ef3cabd4ce80c622b12fb39b69
master_replid2:7331d8dbfc77c3fe3f75d7b68df331925cbb5f49
master_repl_offset:25095
second_repl_offset:13761
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:6018
repl_backlog_histlen:19078# 查看从节点2的信息,发现他变为了主节点
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=26165,lag=1
master_failover_state:no-failover
master_replid:a7529ac9efada9ef3cabd4ce80c622b12fb39b69
master_replid2:7331d8dbfc77c3fe3f75d7b68df331925cbb5f49
master_repl_offset:26165
second_repl_offset:13761
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:6032
repl_backlog_histlen:20134

4.3 优点

        1、哨兵集群模式是基于主从模式的,所有主从的优点,哨兵模式同样具有。

        2、主从可以切换,故障可以转移,系统可用性更好。

        3、哨兵模式是主从模式的升级,系统更健壮,可用性更高。

4.4 缺点

        1、Redis 较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。

        2、实现哨兵模式的配置也不简单,甚至可以说有些繁琐

4.5 哨兵配置说明

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379# 哨兵sentinel的工作目录
dir /tmp# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# 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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/113731.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

学习JAVA打卡第四十五天

StringBuffer类 StringBuffer对象 String对象的字符序列是不可修改的&#xff0c;也就是说&#xff0c;String对象的字符序列的字符不能被修改、删除&#xff0c;即String对象的实体是不可以再发生变化&#xff0c;例如&#xff1a;对于 StringBuffer有三个构造方法&#xff…

JPA在不写sql的情况下实现模糊查询

本文已收录于专栏 《Java》 目录 背景介绍概念说明单字段模糊匹配&#xff1a;多字段模糊匹配&#xff1a; 实现过程代码实现1.写一个实体类去实现Specification接口&#xff0c;重写toPredicate方法2.定义一个接口去继承JpaRepository接口&#xff0c;并指定返回的类型和参数类…

家宽用户家庭网的主要质量问题是什么?原因有哪些

1 引言 截至2020年底&#xff0c;我国家庭宽带&#xff08;以下简称“家宽”&#xff09;普及率已达到96%。经过一年多的发展&#xff0c;当前&#xff0c;家庭宽带的市场空间已经饱和。运营商在家宽市场的竞争也随之从新增用户数的竞争转移到家宽品质的竞争。 早期运营商的家…

多张图片转为pdf怎么弄?

多张图片转为pdf怎么弄&#xff1f;在网络传输过程中&#xff0c;为了避免图片格式文件出现差错&#xff0c;并确保图片的清晰度和色彩不因不同设备而有所改变&#xff0c;常见的做法是将图片转换为PDF格式。然而&#xff0c;当涉及到多张图片时&#xff0c;逐一转换将会变得相…

IP基本原理(上)

文章目录 一、IP的定义二、IP的作用1.标识节点和链路2.寻址和转发3.适应各种数据链路 三、IP头部封装格式四、MTU五、IP地址1.定义2.格式2.1 点分十进制和二进制关系与转换2.2 由网络位主机位组成2.3 网络位长度决定网段 3.分类3.1 A类3.2 B类3.3 C类3.4 D类3.5 E类 4.特殊地址…

职场中的团队建设:超越任务,铸就默契

团队建设在职场中的重要性日益凸显。无论是初创公司还是大型企业&#xff0c;都需要一个高效、和谐且有创新能力的团队来推动业务发展。本文将深入探讨团队建设的活动和策略&#xff0c;帮助您构建一个卓越的团队。 1. 团队建设的重要性 提高团队凝聚力 团队凝聚力不仅仅是团…

手写数字识别之网络结构

目录 手写数字识别之网络结构 数据处理 经典的全连接神经网络 卷积神经网络 手写数字识别之网络结构 无论是牛顿第二定律任务&#xff0c;还是房价预测任务&#xff0c;输入特征和输出预测值之间的关系均可以使用“直线”刻画&#xff08;使用线性方程来表达&#xff09…

SSM - Springboot - MyBatis-Plus 全栈体系(三)

第二章 SpringFramework 一、技术体系架构 1. 总体技术体系 1.1 单一架构 一个项目&#xff0c;一个工程&#xff0c;导出为一个war包&#xff0c;在一个Tomcat上运行。也叫all in one。 单一架构&#xff0c;项目主要应用技术框架为&#xff1a;Spring , SpringMVC , Myba…

基于Jenkins构建生产CICD环境(第三篇)

目录 基于Jenkins自动打包并部署docker环境 1、安装docker-ce 2、阿里云镜像加速器 3、构建tomcat 基础镜像 4、构建一个Maven项目 基于Jenkins自动化部署PHP环境 基于rsync部署 基于Jenkins自动打包并部署docker环境 1、安装docker-ce 在192.168.2.123 机器上&#x…

Qt中XML文件创建及解析

一 环境部署 QT的配置文件中添加xml选项&#xff1a; 二 写入xml文件 头文件&#xff1a;#include <QXmlStreamWriter> bool MyXML::writeToXMLFile() {QString currentTime QDateTime::currentDateTime().toString("yyyyMMddhhmmss");QString fileName &…

【算法日志】动态规划刷题:股票买卖问题(day41)

代码随想录刷题60Day 目录 前言 买卖股票的最佳时机1 买卖股票的最佳时机2 买卖股票的最佳时机3 买卖股票的最佳时机4 前言 本日着重于多状态问题的处理&#xff0c;各状态之间会有一定联系&#xff0c;状态转移方程将不再局限一个。 买卖股票的最佳时机1 int maxProfit(…

详细对比超融合服务器硬件平滑升级方案:新建集群 VS 滚动升级

作者&#xff1a;深耕行业的金融团队 刘慧敏 在企业 IT 基础架构运维中&#xff0c;经常会遇到以下问题&#xff0c;从而需要对服务器硬件进行更换或升级&#xff1a; 服务器达到维护期限&#xff1a;通常在金融行业中&#xff0c;生产环境的服务器维护期限在 5 年左右&#…

三十七个常见Vue面试题,背就完事了二

八、vue.mixin的使用场景和原理? Vue的mixin的作用就是抽离公共的业务逻辑&#xff0c;原理类似对象的继承&#xff0c;当组件初始化的时候&#xff0c;会调用mergeOptions方法进行合并&#xff0c;采用策略模式针对不同的属性进行合并。 如果混入的数据和本身组件的数据有冲突…

《向量数据库》——为何向量数据库对大模型LLM很重要?

当您浏览Twitter、LinkedIn或新闻源上的时间轴时,可能会看到一些关于聊天机器人、LLM和GPT的内容。因为每周都有新的LLM发布,很多人都在谈论LLM。 我们目前置身于一场人工智能革命,许多新应用都依赖于向量嵌入。不妨让我们更多地了解向量数据库以及为什么它们对LLM很重要。…

图书管理系统Java书店进销存jsp源代码MySQL

本项目为前几天收费帮学妹做的一个项目&#xff0c;Java EE JSP项目&#xff0c;在工作环境中基本使用不到&#xff0c;但是很多学校把这个当作编程入门的项目来做&#xff0c;故分享出本项目供初学者参考。 一、项目描述 图书管理系统 系统有1权限&#xff1a;管理员 用所技…

产能紧张,联电、日月光急单要涨价 | 百能云芯

台积电在CoWoS先进封装领域的产能紧张&#xff0c;这导致英伟达在AI芯片方面的生产受到限制。有消息称&#xff0c;英伟达正考虑通过加价寻找除台积电以外的替代生产能力&#xff0c;以应对这一局面。这一消息引发了巨大的订单涌入效应。 联电公司作为提供CoWoS中间层材料的供应…

Android开发血动脉——Binder机制

Binder是Android中的一个类&#xff0c;它继承了IBinder接口。从IPC角度来说&#xff0c;Binder是Android中的一种跨进程通信方式&#xff0c;Binder还可以理解为一种虚拟的物理设备&#xff0c;它的设备驱动是/dev/binder&#xff0c;该通信方式在linux中没有。从Android Fram…

什么是OLAP

一、什么是OLAP OLAP&#xff08;On-line Analytical Processing&#xff0c;联机分析处理&#xff09;是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP&#xff08;On-line Transaction Processing&#xff0c;联机事务处理&…

3D风速仪 Gill Instruments Limited_R3-50 R3-100 and R3A -100 Manual

R3测量超声波脉冲从上部换能器到相反的下部换能器所花费的时间&#xff0c;并将其与脉冲从下部换能器到上部换能器的时间进行比较。 同样&#xff0c;在其他上下换能器之间比较时间。 如图1所示&#xff0c;每对换能器之间沿轴的空气速度可以从每条轴上的飞行次数计算出来。 …

深度学习(前馈神经网络)知识点总结

用于个人知识点回顾&#xff0c;非详细教程 1.梯度下降 前向传播 特征输入—>线性函数—>激活函数—>输出 反向传播 根据损失函数反向传播&#xff0c;计算梯度更新参数 2.激活函数(activate function) 什么是激活函数&#xff1f; 在神经网络前向传播中&#x…