Shulou(Shulou.com)06/01 Report--

Preface

As an in-memory database, Redis needs to have the characteristics of high availability, otherwise if the server goes down, the data still in memory will be lost. The most commonly used high-availability method is to build a cluster. If the master machine is hung up, the service can be continued on top of the slave machine. However, the Redis cluster does not automatically switch between master and slave, that is to say, if the master node dies at 3: 00 in the morning, then the operation and maintenance students should get up immediately and change the slave node to the master node, which is very tedious and inefficient. To this end, Redis officially provides a solution: Redis Sentinel

Brief introduction

A Redis Sentinel cluster usually consists of 3 to 5 nodes, and the cluster can function normally if individual nodes fail. It is responsible for monitoring the health of Redis clusters. If the primary node dies, the Sentinel cluster votes to select a new primary node. When the original master node is restored, it will be rejoined to the Redis cluster as the slave node of the new master node.

Basic principles

The Sentinel cluster discovers the master through the specified configuration file, monitors it, and sends info instructions to obtain the slave node information of the master. The nodes in the Sentinel cluster announce their existence to other Sentinel by sending hello information (including the ip, port and id of the Sentinel itself) to the master and slave nodes they monitor.

The Sentinel cluster receives hello information from other Sentinel through subscription connections.

The Sentinel cluster uses the ping command to check the status of the monitored instance. If it is not returned within the specified time, the instance is considered offline.

After Sentinel triggers the failover master-slave switch, it does not happen immediately, only after (quorum) Sentinel authorization, the master node is marked as ODOWN state. It was only then that we really started voting for the new master.

Sentinel's principle for selecting a new master is: first determine the priority and select the one with lower priority; if the priority is the same, check the replication subscript and select the one with more replication data; if the replication subscript is also the same, select the process with smaller ID.

After Sentinel is authorized, it will get the latest configuration version number (config-epoch) of the delayed master. When the failover execution is finished, this version number will be used for the latest configuration, notifying other Sentinel via broadcast, and other Sentinel will update the configuration of the corresponding master.

Basic use

Let's take Python as an example to briefly explain how to use Sentinel on the client side.

From redis.sentinel import Sentinelif _ _ name__ = ='_ main__': sentinel = Sentinel (['localhost', 26379], socket_timeout=0.1) print (sentinel.discover_master (' mymaster')) print (sentinel.discover_slaves ('mymaster')) master = sentinel.master_for (' mymaster', socket_timeout=0.1) slave = sentinel.slave_for ('mymaster', socket_timeout=0.1) master.set (' follow', 'Jackeyzhe2018') follow = slave.get (' follow') print (follow)

The master_for and slave_for methods take a connection from the connection pool for use, and if there are multiple slave addresses, polling is used.

When a master-slave switch occurs in redis, how does the client know that the address has changed? Let's look for the answer from the source code of redis-py.

As you can see, when redis creates a new connection, it calls the get_master_address method to get the address of the primary node. In the get_master_address method, the client first queries the address of the primary node and then compares it with the address in memory. If it is inconsistent, it is disconnected and reconnected with the new address.

If the master node is not hung up, and Sentinel takes the initiative to switch between master and slave, redis-py also handles this situation. Is to catch a ReadOnlyError exception, and then disconnect, subsequent instructions need to be reconnected. Of course, if there is no modification instruction, then the connection will not be switched, but the data will not be destroyed, so the impact is not significant.

Hands-on construction

We already have a general understanding of how Sentinel works and how to use it. In order to deepen our understanding, let's build a set of Sentinel clusters ourselves.

First of all, build the redis cluster environment we need.

After installing redis, make 3 copies of the configuration file redis.conf in the redis directory. They are named redis6379.conf,redis6380.conf,redis6381.conf respectively.

Modify the following items in the redis6381.conf file

Bind 127.0.0.1port 6381logfile "6381.log" dbfilename "dump-6381.rdb"

Modify in redis6379.conf

Bind 127.0.0.1port 6379logfile "6379.log" dbfilename "dump-6379.rdb" slaveof 127.0.0.1 6381

The modification of redis6380.conf refers to redis6379.conf. After the modification is completed, start three instances respectively. We have set up the redis master-slave environment we want.

When we connect the master node, we can see its master-slave configuration information.

Next, let's configure the Sentinel cluster. Here we also configure three instances. Three sentinel.conf files were copied and named sentinel-26379.conf,sentinel-26380.conf and sentinel-26381.conf respectively.

Edit the following in the sentinel-26379.conf file

Port 26379 daemonize yes logfile "26379.log" dir / home/xxx/redis/data sentinel monitor mymaster 127.0.0.1 6381 2sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000

The content of sentinel-26380.conf and sentinel-26381.conf is similar to the above. Once configured, we use the command redis-sentinel to start three sentinel instances.

At this point, we use the redis-cli command to connect to the instance of 26379 to view the information of sentinel.

Found that it has already started to monitor our 3 redis nodes. At this point, our entire cluster is deployed, so let's test it next.

When kill drops the master node and looks at the log of sentinel, you will find that sentinel has selected the new master according to the steps we mentioned earlier.

At this point, let's take a look at sentinel information.

At this point, 6380 has become the new master.

Congratulations, you don't have to get up in the early morning to switch between Redis master and slave instances.

Summary:

The above is the whole content of this article, I hope that the content of this article has a certain reference and learning value for your study or work, if you have any questions, you can leave a message and exchange, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.