Redis design and implementation-Sentinel
Sentinel is a Redis high availability solution. It is composed of one or more Sentinel instances and can be used to monitor all the slave servers under any number of Master servers and master servers, after the master server is monitored to go offline, the slave server under the master server is automatically upgraded to the new master server. The new master server replaces the offline master server to process command requests.
Sentinel is a special Redis server instance. Redis consists of one or more Sentinel instances to form the Sentinel system. Sentinel can be used to monitor any number of master and slave servers, after Sentinel is taken offline due to a fault, Sentinel will perform failover and select a new master server.
Start Sentinel instance
Run the following command to start the Sentinel instance:
Redis-sentinel/path/to/your/sentinel. conf
Or:
Redis-server/path/to/your/sentinel. conf -- sentinel
Sample sentinel. conf configuration file:
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 commands used by Sentinel are different from those used by common Redis servers. Sentinel does not use databases, so it cannot use database-related commands such as SET, and does not need to load RDB or AOF files during initialization.
Data Structure
Redis maintains Sentinel-related states through the sentinelState structure. One master dictionary maintains the monitored master server. The dictionary key is the name of the master server and the value is an sentinelRedisInstance structure.
Two connections are established between Sentinel and common servers. One is used to send Common commands, and the other is used to subscribe to the _ sentinel _: hello channel of the server. Sentinel will publish information to this channel, after a subscription connection is established, the SUBSCRIBE _ sentinel _: hello command is sent to the server and the channel information is subscribed to. When the master server is monitored by multiple Sentinel instances, sentinel can automatically discover other Sentinel monitoring the same master server through this channel and add it to the sentinels attribute of the sentinelRedisInstance structure, and create a command connection with the newly discovered sentinel (no subscription connection will be created ).
By default, Sentinel sends the INFO command to the master server through a command connection and obtains the current information of the master server by analyzing the response of the INFO command. When the master server receives the INFO command, it will reply to Sentinel the runid of the current master server, and the ip addresses and ports of all slave servers under the master server, and save the slave server information to the master server. the slaves attribute of the sentinelRedisInstance structure corresponds to the dictionary.
When Sentinel discovers a new slave server of the master server, it establishes a command connection and subscription connection with the slave server, and send the INFO command to get the slave server's runid, master server's ip port, master server connection status, master server priority, slave Server replication offset. Concurrently save the information to the sentinelRedisInstance structure.
Node communication
By default, Sentinel sends a command in the following format to all monitored master/slave servers through a command connection every two seconds:
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, send the Sentinel ip, Sentinel port, Sentinel run id, Sentinel current configuration epoch, master server ip, master server port, master server run id, and master server current configuration epoch to _ sentinel _: hello channel. Because all Sentinel instances subscribe to the _ sentinel _: hello channel, this publish message will be received by all Sentinel instances, all sentinels can be automatically discovered through this subscription message, and the newly discovered Sentinel can be added to the sentinelRedisInstance structure's sentinels attribute.
Sentinel sends PING commands to all instances that have created command connections to it (including master-slave servers and Sentinel servers) at a frequency of once per second. Based on the PING response, Sentinel determines whether the instance is online, reply + PONG,-LOADING, and-MASTERDOWN indicate online. Otherwise, the description is not online. Sentinel configures the "down-after-milliseconds" option, if no valid reply is returned for consecutive down-after-milliseconds within milliseconds, Sentinel marks the instance as subjective offline and sets flags in the sentinelRedisInstance structure to SRI_S_DOWN.
When Sentinel marks a master server as a subjective offline server, by sending SENTINEL is-master-down-by-addr <ip> <port> <curent_epoch> <runid>, ask other sentinel to check whether the master server is offline, after receiving enough offline judgments, the master server will be marked as an objective offline server and flags will be set to SRI_O_DOWN. After the master server is marked as an objective offline server, each Sentinel instance will negotiate and cite a leading Sentinel instance to failover the offline master server and recommend a new master server, and change the replication target of the slave server. If the old master server goes online again, change it to the slave server.
Sentinel, the leader, adopted the Raft algorithm.
