Redis-sentinel build redis Master/Slave failover

Redis-Sentinel is the monitoring and management, notification, and instance failure backup service of redis instances. It is a management tool for redis clusters. In a general distributed central node database, redis-Sentinel is used for the work of the central node. It monitors the working conditions of other nodes and carries out fault recovery to improve the high availability of the cluster.

Redis-Sentinel was completed by redis author antirez in June this year. Because redis instances are used in various large companies, every company needs a redis cluster management tool, forced to write their own management tools to manage redis clusters, antirez took into consideration the urgent needs of the community and spent a few weeks writing redis-Sentinel.

Three major functions of redis-sentinel: monitoring, notification, and automatic fault recovery. First, redis-sentinel needs to establish a monitoring master list, and then obtain the Sentinels and slaves of each master in the master list for future fault recovery. Due to the needs of the project, we will take the time to perform a simple test today.

Configuration instance:

192.168.1.122 master

192.168.1.118 slave

192.168.1.119 slave

The redis installation directory is in the/usr/local/redis directory.

Master/usr/local/redis. conf configuration

Daemonize Yes

Two Slave/usr/local/redis. conf configurations

Daemonize Yes

Slaveof 192.168.1.122 6379

 

Master/usr/local/redis/sentinel. conf and two slave/usr/local/redis/sentinel. conf configurations:

Sentinel monitor mymaster 192.168.1.122 6379 2

Sentinel down-after-milliseconds MySQL master 60000

Sentinel Failover-Timeout MySQL master 180000

Sentinel parallel-syncs mymaster 1

 

The master node starts the redis service.

Redis-server/usr/local/redis. conf

Slave starts the redis Service

Redis-server/usr/local/redis. conf

Master and slave start sentinel instances

Redis-server/usr/local/redis/sentinel. conf -- sentinel &

 

Disable the redis Service of the master node to test failover. If the sharding function is configured for redis, a certain bug occurs in this method.

By default, Sentinel uses TCP port 26379 (6379 for common redis servers ).

Sentinel accepts command requests in redis protocol format, so you can use redis-cli or any other redis client to communicate with Sentinel.

There are two ways to communicate with Sentinel:

· The first method is to directly send commands to query the current status of the monitored redis server, as well as information about other Sentinel that Sentinel knows, and so on.

· Another method is to use the publishing and subscription functions to receive notifications sent by sentinel: When performing failover, or when a monitored server is determined to be subjective offline or objective offline, Sentinel will send the corresponding information.

Sentinel command

The commands received by sentinel are listed below:

· Ping: Pong is returned.

· Sentinel masters: lists all monitored master servers and their current status.

· Sentinel slaves <Master name>: Lists All slave servers of a given master server and the current status of these slave servers.

· Sentinel get-master-ADDR-by-name <Master name>: returns the IP address and port number of the master server given the name. If the master server is performing a Failover or the Failover has been completed, the command returns the IP address and port number of the new master server.

· Sentinel reset <pattern>: resets all master servers whose names match the specified pattern. The pattern parameter is a glob-style pattern. The reset operation clearly shows the current status of the master server, including ongoing failover, and removes all slave servers and Sentinel that have been found and associated with the master server.

· Sentinel failover <Master name>: when the master server fails, force start an automatic failover (however, the Sentinel that initiates the Failover will send a new configuration to other Sentinel, And the other Sentinel will update the configuration accordingly ).

Publishing and subscription information

The client can regard Sentinel as a redis server that only provides the subscription function: you cannot use the publish command to send messages to this server, but you can use the SUBSCRIBE command or the psubscribe command, subscribe to a given channel to obtain corresponding Event Notifications.

A channel can receive events with the same name as this channel. For example, a channel named + sdown can receive events in the subjective sdown status of all instances.

You can run the psubscribe * command to receive all event information.

The following lists the channels and information formats that the client can obtain through subscription: the first English word is the channel/event name, and the rest is the data format.

Note: When the format contains the instance details, it indicates that the information returned by the channel contains the following content used to identify the target instance:

<Instance-type> <Name> <ip> <port >@< master-Name> <master-ip> <master-port>

 

The content after the @ character is used to specify the master server. The content is optional and is only used when the instance specified by the content before the @ character is not the master server.

· + Reset-master <instance details>: the master server has been reset.

· + Slave <instance details>: A new slave server has been recognized and associated by sentinel.

· + Failover-state-reconf-slaves <instance details>: the Failover Status switches to reconf-slaves.

· + Failover-detected <instance details>: Another sentinel starts a failover operation, or one slave server is switched to the master server.

· + Slave-reconf-sent <instance details>: the leader's Sentinel sends the slaveof command to the instance and sets a new master server for the instance.

· + Slave-reconf-inprog <instance details>: The instance is setting itself as the slave server of the specified master server, but the synchronization process is still incomplete.

· + Slave-reconf-done <instance details>: The slave server has successfully synchronized the new master server.

·-Dup-sentinel <instance details>: one or more sentinel instances monitored for a given master server have been removed because of repeated occurrences. When the Sentinel instance restarts, this will happen.

· + Sentinel <instance details>: A new Sentinel that monitors a given master server has been identified and added.

· + Sdown <instance details>: the specified instance is currently in the subjective Offline state.

·-Sdown <instance details>: the specified instance is no longer in the subjective deprecation status.

· + Odown <instance details>: the specified instance is offline.

·-Odown <instance details>: the specified instance is no longer in the offline status.

· + New-epoch <instance details>: The current epoch has been updated.

· + Try-failover <instance details>: A New Fault migration operation is in progress and is waiting to be selected by most sentinel (waiting to be elected by the majority ).

· + Elected-leader <instance details>: To win the election for the specified epoch, you can perform fault migration.

· + Failover-state-select-slave <instance details>: The failover operation is now in the select-slave state-Sentinel is looking for slave servers that can be upgraded to the master server.

· No-good-slave <instance details>: The Sentinel operation fails to find the slave server suitable for upgrading. After a while, Sentinel will try again to find a suitable slave server for upgrading, or directly give up the failover operation.

· Selected-slave <instance details>: sentinel successfully finds the slave server suitable for upgrading.

· Failover-state-send-slaveof-Noone <instance details>: Sentinel is upgrading the specified slave server to the master server. Wait until the upgrade is completed.

· Failover-end-for-Timeout <instance details>: failover is terminated due to timeout, however, all slave servers will start to copy the new master server (slaves will eventually be configured to replicate with the new Master anyway ).

· Failover-end <instance details>: failover is successfully completed. All slave servers start to copy the new master server.

· + Switch-master <Master name> <oldip> <Oldport> <newip> <Newport>: the IP address and address of the master server have been changed. This is the information that most external users are concerned about.

· + Tilt: Enter the tilt mode.

-Tilt: exit the tilt mode.

This article is from the "diannaowa" blog, please be sure to keep this source http://diannaowa.blog.51cto.com/3219919/1557617

Redis-sentinel build redis Master/Slave failover