Home  >  Article  >  Database  >  Let’s talk about the sentry mode in Redis

Let’s talk about the sentry mode in Redis

青灯夜游
青灯夜游forward
2021-05-11 11:35:132088browse

This article takes you through the sentinel mode in Redis. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.

Let’s talk about the sentry mode in Redis

The master-slave switching technology method is:

  • When the main server goes down, you need to manually switch from the slave server (slaveof no one) to the master-slave server, which requires manual intervention.
  • This is time-consuming and laborious, but will also cause the service to be unavailable for a period of time. This is not a recommended approach.
  • More time, we give priority to the sentry mode, which is the mainstream mode of current enterprise applications. Redis Sentinel is a highly available implementation of Redis.
  • Sentinel is a tool for managing multiple Redis instances. It can monitor, notify Redis and automatically failover.

Basic concepts of Redis Sentinel

Schematic diagram of master-slave replication and Sentinel high availability architecture

Let’s talk about the sentry mode in Redis

Redis Sentinel Architecture

Let’s talk about the sentry mode in Redis

The main functions of Redis Sentinel The main functions of Sentinel include:

Master node survival detection, master-slave operation detection, automatic failover and master-slave switching.

  • The minimum tag configuration of Redis is one host and one slave;
  • The Sentinel system of Redis can be used to manage multiple Redis servers.
  • The system can perform the following four tasks:

1.Monitoring: Sentinel will constantly check whether the master server and slave servers are normal. Run;
2, Notification: When there is a problem with the monitored Redis server, Sentinel will send a notification to the administrator or other applications through the API script;
3, Automatic failover: When the master node fails to work properly, Sentinel will initiate an automatic failover operation. It upgrades one of the slave nodes in a master-slave relationship with the failed master node to the new master node, and points the other slave nodes to the new master node;
4, Configuration provider: In Redis Sentinel mode, when initializing the client application, it will connect to the Sentinel node collection to obtain the information of the master node;

How Redis Sentinel works

  • When a sentinel node connects to a Redis instance, it creates two connections: cmd and pub/sub. Sentinel sends commands to Redis via cmd connections and to other Sentinel instances on the Redis instance via pub/sub connections.
  • Commands for Sentinel to interact with Redis master nodes and slave nodes
  • Each Sentinel sends a PING command every second to its known master instances, slave instances, and other Sentinel instances.

Let’s talk about the sentry mode in Redis

  • #If an instance takes longer than the time specified by down since the last valid reply to the PING command (in milliseconds), then Sentinel The instance will be marked Subjectively Offline.

Let’s talk about the sentry mode in Redis

  • If the master server is marked as subjective logout, all Sentinel nodes of the master server will be monitored to confirm that the master server has indeed entered the subjective logout once per second. Logout status.

Let’s talk about the sentry mode in Redis

  • If the master is marked for subjective logout and there are enough sentries within the specified time frame (at least the number specified in the configuration file) If it is consistent with this judgment, the main server will be marked as objectively offline.

Let’s talk about the sentry mode in Redis

  • Typically, each Sentinel sends INFO commands to all its known masters and slaves every 10 seconds. When Sentinel marks a master server as offline, the frequency with which Sentinel sends INFO commands to all slave servers of the offline master server will change from once every 10 seconds to once every second.

Let’s talk about the sentry mode in Redis

  • Sentinel negotiates the status of the master node with other sentinels. If the master node is in the SDOWN state, voting will automatically select a new master node. Point the remaining slave nodes to the new master node for data replication .

Let’s talk about the sentry mode in Redis

  • If there are not enough sentries to allow the master to logout , the master's objective logout status will be removed. When the master returns a valid reply to Sentinel's PING command, the master's subjective offline status is removed.

Let’s talk about the sentry mode in Redis

  • note

A robust Redis Sentinel cluster should use at least three Sentinel instances, And make sure to place these instances on different machines, or even on different physical areas.
Sentinel cannot guarantee strong consistency. Sentinel is supported in common client application libraries.
Sentinel requires constant testing and observation to ensure high availability

Testing

  • Create configuration file

Let’s talk about the sentry mode in Redis

The simple configuration is as follows:

port 16379  # 哨兵端口号
daemonize yes
sentinel monitor master 127.0.0.1 6379 1    # 监视master
protected-mode no
logfile "/usr/local/bin/sentinel-1/sentinel-1.log"   # 日志文件
  • First start redis to set up the cluster, start redis-cli, and set 6379 as master

1Let’s talk about the sentry mode in Redis

  • Restart sentinel
sudo redis-sentinel sentinel-1/sentinel.conf

1Let’s talk about the sentry mode in Redis

  • Close 6379

13 .png

  • Check the roles of the other two redis-cli

1Let’s talk about the sentry mode in Redis

  • Restart 6379

1Let’s talk about the sentry mode in Redis

  • View sentinel log

1Let’s talk about the sentry mode in Redis

sentinel.conf description

# Example sentinel.conf

# *** IMPORTANT ***
# 绑定IP地址
# bind 127.0.0.1 192.168.1.1
# 保护模式(是否禁止外部链接,除绑定的ip地址外)
# protected-mode no

# port <sentinel-port>
# 此Sentinel实例运行的端口
port 26379

# 默认情况下,Redis Sentinel不作为守护程序运行。 如果需要,可以设置为 yes。
daemonize no

# 启用守护进程运行后,Redis将在/var/run/redis-sentinel.pid中写入一个pid文件
pidfile /var/run/redis-sentinel.pid

# 指定日志文件名。 如果值为空,将强制Sentinel日志标准输出。守护进程下,如果使用标准输出进行日志记录,则日志将发送到/dev/null
logfile ""

# sentinel announce-ip <ip>
# sentinel announce-port <port>
#
# 上述两个配置指令在环境中非常有用,因为NAT可以通过非本地地址从外部访问Sentinel。
#
# 当提供announce-ip时,Sentinel将在通信中声明指定的IP地址,而不是像通常那样自动检测本地地址。
#
# 类似地,当提供announce-port 有效且非零时,Sentinel将宣布指定的TCP端口。
#
# 这两个选项不需要一起使用,如果只提供announce-ip,Sentinel将宣告指定的IP和“port”选项指定的服务器端口。
# 如果仅提供announce-port,Sentinel将通告自动检测到的本地IP和指定端口。
#
# Example:
#
# sentinel announce-ip 1.2.3.4

# dir <working-directory>
# 每个长时间运行的进程都应该有一个明确定义的工作目录。对于Redis Sentinel来说,/tmp就是自己的工作目录。
dir /tmp

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
#
# 告诉Sentinel监听指定主节点,并且只有在至少<quorum>哨兵达成一致的情况下才会判断它 O_DOWN 状态。
#
#
# 副本是自动发现的,因此您无需指定副本。
# Sentinel本身将重写此配置文件,使用其他配置选项添加副本。另请注意,当副本升级为主副本时,将重写配置文件。
#
# 注意:主节点(master)名称不能包含特殊字符或空格。
# 有效字符可以是 A-z 0-9 和这三个字符 ".-_".
sentinel monitor mymaster 127.0.0.1 6379 2

# 如果redis配置了密码,那这里必须配置认证,否则不能自动切换
# Example:
#
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# sentinel down-after-milliseconds <master-name> <milliseconds>
#
# 主节点或副本在指定时间内没有回复PING,便认为该节点为主观下线 S_DOWN 状态。
#
# 默认是30秒
sentinel down-after-milliseconds mymaster 30000

# sentinel parallel-syncs <master-name> <numreplicas>
#
# 在故障转移期间,多少个副本节点进行数据同步
sentinel parallel-syncs mymaster 1

# sentinel failover-timeout <master-name> <milliseconds>
#
# 指定故障转移超时(以毫秒为单位)。 它以多种方式使用:
#
# - 在先前的故障转移之后重新启动故障转移所需的时间已由给定的Sentinel针对同一主服务器尝试,是故障转移超时的两倍。
#
# - 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#
# - 取消已在进行但未生成任何配置更改的故障转移所需的时间
#
# - 当进行failover时,配置所有slaves指向新的master所需的最大时间。
#   即使过了这个超时,slaves依然会被正确配置为指向master。
#
# 默认3分钟
sentinel failover-timeout mymaster 180000

# 脚本执行
#
# sentinel notification-script和sentinel reconfig-script用于配置调用的脚本,以通知系统管理员或在故障转移后重新配置客户端。
# 脚本使用以下规则执行以进行错误处理:
#
# 如果脚本以“1”退出,则稍后重试执行(最多重试次数为当前设置的10次)。
#
# 如果脚本以“2”(或更高的值)退出,则不会重试执行。
#
# 如果脚本因为收到信号而终止,则行为与退出代码1相同。
#
# 脚本的最长运行时间为60秒。 达到此限制后,脚本将以SIGKILL终止,并重试执行。

# 通知脚本
#
# sentinel notification-script <master-name> <script-path>
#
# 为警告级别生成的任何Sentinel事件调用指定的通知脚本(例如-sdown,-odown等)。
# 此脚本应通过电子邮件,SMS或任何其他消息传递系统通知系统管理员 监控的Redis系统出了问题。
#
# 使用两个参数调用脚本:第一个是事件类型,第二个是事件描述。
#
# 该脚本必须存在且可执行,以便在提供此选项时启动sentinel。
#
# 举例:
#
# sentinel notification-script mymaster /var/redis/notify.sh

# 客户重新配置脚本
#
# sentinel client-reconfig-script <master-name> <script-path>
#
# 当主服务器因故障转移而变更时,可以调用脚本执行特定于应用程序的任务,以通知客户端,配置已更改且主服务器地址已经变更。
#
# 以下参数将传递给脚本:
#
# <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 用于传递主服务器的旧地址和所选副本的新地址。
#
# 举例:
#
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

# 安全
# 避免脚本重置,默认值yes
# 默认情况下,SENTINEL SET将无法在运行时更改notification-script和client-reconfig-script。
# 这避免了一个简单的安全问题,客户端可以将脚本设置为任何内容并触发故障转移以便执行程序。
sentinel deny-scripts-reconfig yes

# REDIS命令重命名
#
#
# 在这种情况下,可以告诉Sentinel使用不同的命令名称而不是正常的命令名称。
# 例如,如果主“mymaster”和相关副本的“CONFIG”全部重命名为“GUESSME”,我可以使用:
#
# SENTINEL rename-command mymaster CONFIG GUESSME
#
# 设置此类配置后,每次Sentinel使用CONFIG时,它将使用GUESSME。 请注意,实际上不需要尊重命令案例,因此在上面的示例中写“config guessme”是相同的。
#
# SENTINEL SET也可用于在运行时执行此配置。
#
# 为了将命令设置回其原始名称(撤消重命名),可以将命令重命名为它自身:
#
# SENTINEL rename-command mymaster CONFIG CONFIG

For more programming-related knowledge, please visit: Programming Teaching! !

The above is the detailed content of Let’s talk about the sentry mode in Redis. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:juejin.cn. If there is any infringement, please contact admin@php.cn delete