Sentinel is a high-availability solution for Redis, which consists of one or more sentinel instances that form a sentinel system that can be used to monitor all slave servers under any of the primary and primary servers. When monitoring to the main server after the offline will automatically upgrade from the offline primary server from the server to the new primary server, the new primary server instead of the offline master server processing command requests.
Sentinel is a special Redis server instance where Redis consists of one or more sentinel instances that form the Sentinel system, Sentinel can be used to monitor any number of primary and slave servers, and when Sentinel is down due to failure, Sentinel will fail over and elect a new primary server.
Launch Sentinel Instance
You can start a Sentinel instance with the following command:
Redis-sentinel/path/to/your/sentinel.conf
Or:
Redis-server/path/to/your/sentinel.conf--sentinel
sentinel.conf Configuration File Example:
Sentinel Monitor Master1 127.0.0.1 6379 2
Sentinel Down-after-milliseconds Master1 30000
Sentinel Parallel-syncs Master1 1
Sentinel Failover-timeout Master1 900000
The Sentinel server uses a different command than a normal Redis server, and Sentinel does not use a database, so you cannot use the database-related commands such as set, and you do not have to load an RDB or aof file during initialization.
Data
In Redis, Sentinel-related states are maintained through the sentinelstate structure, where a master dictionary maintains the primary server being monitored, and the dictionary key is the primary server name, and value is a sentinelredisinstance structure.
Sentinel and the normal server will create two connections, one for sending ordinary commands, one for subscribing to the channel, for subscribing to the server's _sentinel_:hello channel, and Sentinel posting information to the channel, After a subscription connection is made, the Subscribe _sentinel_:hello command is sent to the server, which also subscribes to the channel's information, when the primary server is monitored by multiple sentinel Sentinel can automatically discover other sentinel monitors on the same home server through this channel and add it to the Sentinels attribute of the sentinelredisinstance structure. and establish a command connection with the newly discovered Sentinel (no subscription connection is created).
Sentinel sends the info command to the primary server via a command connection at the default of 10 seconds, and obtains the current information for the primary server by parsing the reply to the info command. When the primary server receives the info command, it replies to Sentinel for the current master server's Runid, And all the IP and ports from the server under the master server and save these from the server information to the dictionary corresponding to the slaves property of the sentinelredisinstance structure corresponding to the primary server.
When Sentinel discovers a new slave server from the primary server, it establishes a command connection and a subscription connection from the server, and sends an info command to get the Runid from the server from the server, the IP port of the primary server, the master-slave server connection status, the primary server priority, and the replication offset from the server. This information is saved to the sentinelredisinstance structure.
Node communication
By default, Sentinel sends a format command to all monitored master and slave servers at a frequency of two seconds via a command connection:
PUBLISH _sentinel_:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip >,<m_port>,<m_epoch> "
This command sends a message to the _sentinel_:hello channel that puts Sentinel IP, Sentinel Port, Sentinel run ID, Sentinel current configuration era, home server IP, primary server port, master server run ID, The current configuration era of the primary server is sent to the _sentinel_:hello channel because all Sentinel instances are subscribed to the _sentinel_:hello channel, so this release message is received by all Sentinel instances. Each sentinel can implement Autodiscover with this subscription message and add the newly discovered Sentinel to the Sentinels attribute of the sentinelredisinstance structure.
Sentinel sends a ping to all instances with which it has created a command connection (including the master-slave server, Sentinel Server) at the frequency of every second, according to the Ping's response to determine if the instance is online, reply to +pong,-loading,- Masterdown three kinds of a description online, otherwise the description is not online, Sentinel configured the Down-after-milliseconds option, when there is no reply to a valid reply in down-after-milliseconds milliseconds, Sentinel then identifies the instance as a subjective downline, placing the flags in the sentinelredisinstance structure into Sri_s_down.
When Sentinel identifies a primary server as a subjective downline, send Sentinel is-master-down-by-addr <ip> <port> <curent_epoch> <runid > Ask other Sentinel whether the main server is offline, and when it receives enough downline judgment, it will identify the primary server as an objective downline and place the flags into Sri_o_down. After the primary server is identified as an objective downline, each Sentinel instance will negotiate, nominate a lead sentinel, fail over the primary server on the downline, nominate a new primary server, and change the replication target from the server if the old primary server is back online and turn it into a slave server.
The raft algorithm was adopted by the lead Sentinel.
Redis Design and Implementation Learning Note-sentinel (Sentry, Sentinel)
