A method for implementing Redis master-slave by a single sentinel

Abstract

The application discloses a method for realizing Redis master-slave by single sentinel, which comprises the following steps: step 1, installing keepalived on a first server and a second server; step 2, modifying keepalived.conf, a configuration file of keepalived, of the first server and the second server; step 3, installing Redis on the first server and the second server; step 4, modifying redis.conf, a configuration file of Redis, of the first server and the second server; step 5, modifying sentinel.conf, a configuration file of a sentinel, of the first server and the second server; step 6, keeping the sentinel process of the first server under the monitoring of keepalived; and step 7, writing a script. The application has the following superior effects: when the sentinel of the first server is unavailable, the sentinel of the second server takes over the work of the first server, only one sentinel monitors the redis at all times, and the resource consumption of the sentinel for leader election is saved; and only two virtual machines are needed to complete the deployment, so that the cost is greatly saved.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of databases, and particularly relates to a method for realizing Redis master-slave by using a single sentinel. BACKGROUND

[0002] Redis is a completely open source, BSD-licensed, high-performance key-value database. Compared with other key-value cache products, Redis has the following three characteristics: (1) Redis supports data persistence, saves data in the memory on the disk, and restarts to load and use again. (2) Redis not only supports simple key-value type data, but also provides storage of list, set, zset, hash and other data structures. (3) Redis supports data backup, that is, master-slave mode data backup.

[0003] Redis Sentinel, that is, Redis sentinel, is introduced in Redis 2.8 version. The core function of the sentinel is automatic failover of the master node. The function of the sentinel is monitoring: the sentinel continuously checks whether the master node and the slave node are operating normally. Automatic failover: when the master node cannot work normally, the sentinel starts the automatic failover operation, it upgrades one of the slave nodes of the failed master node to a new master node, and lets other slave nodes change to copy the new master node. Configuration provider: the client obtains the address of the current Redis service master node by connecting the sentinel when initializing. Notification: the sentinel sends the failover result to the client.

[0004] Keepalived is a software similar to layer 3, 4 & 5 switching mechanism, which is automatically completed without manual intervention. Its function is to detect the state of the server, when a web server is down or has a fault, keepalived will detect it and remove the server with fault from the system, and use other servers to replace the work of the server, when the server works normally, keepalived automatically adds the server to the server group, all these works are automatically completed without manual intervention, the only thing that needs manual intervention is to repair the fault server.

[0005] The current case of using Redis sentinels to manage Redis servers is to use an odd number of sentinels greater than 3, such as 3 sentinels or 5 sentinels. All the sentinels elect a sentinel leader, and the leader handles the failover. The process of electing a leader is as follows: each online sentinel node becomes a leader when it confirms that the previous leader is offline, and sends an is-master-down-by-addr command to other sentinels to solicit a judgment and require itself to be set as a leader; when other sentinels receive the command, they agree or refuse it to become a leader; until a sentinel finds that the number of votes it elects is greater than or equal to the number of sentinels / 2+1, it becomes a leader. From the election process, it can be seen that there is a major defect when an odd number greater than or equal to 3 sentinels are used, that is, if more than half of the sentinels fail at the same time, a leader cannot be elected, and at this time the sentinel function is virtual, and the Redis server cannot be managed by failover and master-slave switching. SUMMARY

[0006] The purpose of the present application is to provide a single-sentinel Redis master-slave method that can overcome the above technical problems.

[0007] The method of the present application comprises the following steps:

[0008] Step 1, Redis master-slave configuration includes: master virtual machine first server and standby virtual machine second server (hereinafter referred to as first server and second server), wherein the first server includes redis first server, keepalived first process and redis first sentinel; the second server includes redis second server, keepalived second process and redis second sentinel, and the first server and the second server are installed with keepalived;

[0009] Step 2, modify the keepalived.conf of the first server and the second server, that is, the configuration file of keepalived, configure mcast_src_ip, that is, the local address, and configure VIP, that is, the virtual address;

[0010] Step 3, install Redis on the first server and the second server;

[0011] Step 4, modify the redis.conf of the first server and the second server, that is, the configuration file of Redis:

[0012] Step 4.1, modify the redis.conf file of the first server and the second server, and comment out bind 127.0.0.1;

[0013] Step 4.2 Add bind ip1, which is the address of the first server, in the redis.conf of the first server;

[0014] Step 4.3 Add bind ip2, which is the address of the second server, in the redis.conf of the second server;

[0015] Step 4.4 Modify the redis.conf file of the first server and the second server, and configure protected-mode as no;

[0016] Step 4.5 Modify the redis.conf file of the first server and the second server, and configure the path of the log file;

[0017] Step 4.6 Modify the redis.conf file of the second server, and configure it as a backup of the first server by modifying the statement repl icaof ip1, which is the IP address of the first server, to port number 6379;

[0018] Step 5, Modify the sentinel.conf file of the first server and the second server:

[0019] Step 5.1 Configure bind VIP, which is the virtual address VIP in step 2, in the first server;

[0020] Step 5.2 Configure bind 1.1.1.1, which is an address not actually used, in the second server;

[0021] Step 5.3 Configure sentinel monitormyMaster ip1 6379 1, which is the address of the Redis server monitored by the sentinel, in the sentinel.conf of the first server and the second server, port number is 6379, and the last number 1 means that when there is 1 sentinel that considers the master to be invalid, it is determined that the master is invalid;

[0022] Step 6, The keepalived of the first server monitors the sentinel process of the server, and when it detects that the sentinel process is unavailable, it will transfer the VIP from the first server to the second server;

[0023] Step 7, a script is written, when it is detected that the sentinel of the first server is unavailable, then the sentinel.conf file of the first server is copied to the same folder of the second server, and then the sentinel service is restarted; after the restart, the second server becomes the master server, the sentinel switching is completed, and then the Redis master and standby switching is automatically completed by the sentinel.

[0024] The method has the following remarkable advantages:

[0025] 1. When three or more sentinels are used in Redis, if more than half of the sentinels are abnormal, the Redis cannot complete the master-standby switching and detection, but the method can avoid the abnormality.

[0026] 2. When the sentinel of the first server is unavailable, the sentinel of the second server takes over the work, and only one sentinel monitors the Redis at all times, thereby saving the resource consumption of the sentinel leader election.

[0027] 3. The method only needs two virtual machines to complete the deployment, thereby greatly saving the cost. DETAILED DESCRIPTION

[0028] The application will be further described in detail in combination with the specific embodiments.

[0029] The method comprises the following steps:

[0030] Step 1, the Redis master-standby configuration comprises a master virtual machine first server and a standby virtual machine second server (hereinafter referred to as the first server and the second server), wherein the first server comprises a redis first server, a keepalived first process and a redis first sentinel; the second server comprises a redis second server, a keepalived second process and a redis second sentinel, and the first server and the second server are installed with keepalived.

[0031] Step 2, the keepalived.conf of the first server and the second server, i.e. the configuration file of keepalived, is modified, the mcast_src_ip, i.e. the local address, is configured, and the VIP, i.e. the virtual address, is configured.

[0032] Step 3, the first server and the second server are installed with Redis.

[0033] Step 4, the redis.conf of the first server and the second server, i.e. the configuration file of Redis, is modified.

[0034] Step 4.1 Modify the redis.conf file of the first server and the second server, and comment out bind 127.0.0.1;

[0035] Step 4.2 Add bind ip1, the address of the first server, to the redis.conf of the first server;

[0036] Step 4.3 Add bind ip2, the address of the second server, to the redis.conf of the second server;

[0037] Step 4.4 Modify the redis.conf file of the first server and the second server, and set protected-mode, the protection mode, to no;

[0038] Step 4.5 Modify the redis.conf file of the first server and the second server, and configure the path of the log file;

[0039] Step 4.6 Modify the redis.conf file of the second server, and configure it as a backup of the first server by modifying the statement replicaof ip1, the IP address of the first server, 6379 port number;

[0040] Step 5, Modify the sentinel.conf, the configuration file of the sentinel, of the first server and the second server:

[0041] Step 5.1 Configure bind VIP, bind the virtual address VIP in step 2, of the first server;

[0042] Step 5.2 Configure bind 1.1.1.1, bind an address that is not actually used, of the second server;

[0043] Step 5.3 Configure sentinel monitormyMaster ip1 6379 1, the address of the Redis server monitored by the sentinel is ip1, the port number is 6379, and the last number 1 means that when there is 1 sentinel that considers the master to be invalid, it is determined that the master is invalid, in the sentinel.conf of the first server and the second server;

[0044] Step 6, The keepalived of the first server monitors the sentinel process of the server, and when it detects that the sentinel process is unavailable, it will transfer the VIP from the first server to the second server;

[0045] Step 7, write a script to detect that the sentinel of the first server is unavailable, then copy the sentinel.conf file of the first server to the same folder of the second server, and then restart the sentinel service; after restarting, the second server becomes the primary server, the sentinel switching is completed, and then the sentinel automatically completes the switching of the primary and standby Redis.

[0046] In a specific embodiment, two Redis servers are installed and configured; in the initial state, the first Redis server is the primary server and the second server is the standby server; including the following steps:

[0047] Step a, the client that needs to read and write data to Redis first sends a message get-master-addr-by-name to the sentinel on the primary server, that is, the sentinel holding the VIP, carrying the parameter mastername, that is, the Redis primary server name, to obtain the node information of the master, that is, the Redis primary server;

[0048] Step b, the client receives the address and port information of the Redis primary server returned by the sentinel;

[0049] Step c, the client establishes a long connection with the primary server (long connection refers to keeping the connection before the client goes offline regardless of whether the current data is read or written), and during the business process, when the client needs to write, read or delete data to the Redis server, the long connection is used for corresponding operation, and there is no need to establish a connection every time;

[0050] Step d, the client subscribes to the "+switch_master" channel, that is, the client sends a notification message to the client when the sentinel detects the switching of the Redis master and backup through the subscription request;

[0051] Step e, when the master and backup of the Redis server are switched, the sentinel will publish a message carrying the new Redis primary server address to the client through the above-mentioned subscription channel;

[0052] Step f, after the client receives the new Redis primary server address, it releases the old Redis connection and establishes a connection with the new Redis primary server; during the business process, when the client needs to write, read or delete data to the Redis server, the connection is used for corresponding operation.

[0053] The above merely illustrates the preferred embodiments of the present application, and is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for implementing Redis master-slave replication using keepalived and a single Redis sentinel, characterized in that, Includes the following steps: Step 1, the Redis master-slave configuration includes: the primary virtual machine first server and the standby virtual machine second server. The primary server includes the first Redis server, the first keepalived process, and the first Redis sentinel. The second server includes the second Redis server, the second keepalived process, and the second Redis sentinel. Keepalived is installed on both the primary and second servers. Step 2: Modify the keepalived.conf configuration file of the first and second servers, configure mcast_src_ip (local address) and VIP (virtual address); Step 3: Install Redis on the first and second servers; Step 4, modify the redis.conf file (the Redis configuration file) on both the first and second servers: Step 4.1 Modify the redis.conf file of the first and second servers, and comment out bind 127.0.0.1; Step 4.2 Add `bind ip1` (the address of the first server) to the `redis.conf` file of the first server; Step 4.3 Add `bind ip2` (the address of the second server) to the `redis.conf` file of the second server; Step 4.4 Modify the redis.conf file of the first and second servers, and set protected-mode to no; Step 4.5 Modify the redis.conf file of the first and second servers, and configure the logfile, i.e., the path to the log file; Step 4.6 Modify the redis.conf file of the second server by modifying the statement `replicaof ip1`, which is the IP address and port number of the first server, to configure it as a backup of the first server. Step 5, modify the sentinel.conf configuration file for both the first and second servers: Step 5.1 Configure the first server to bind the VIP, i.e., bind the virtual address VIP from Step 2; Step 5.2 Configure the second server to bind 1.1.1.1, which means binding to an address that is not actually used; Step 5.3 Configure sentinel monitormyMaster ip1 6379 1 in sentinel.conf of the first and second servers. That is, the address of the Redis server monitored by the sentinel is ip1, the port number is 6379, and the last number 1 means that when one sentinel thinks that the master has failed, it can be determined that the master has failed. Step 6: The keepalived system on the first server monitors the sentinel process on this server. When it detects that the sentinel process is unavailable, it transfers the VIP from the first server to the second server. Step 7: Write a script that, when it detects that the sentinel on the first server is unavailable, copies the sentinel.conf file from the first server to the folder with the same name on the second server, and then restarts the sentinel service. After restarting, the second server becomes the primary server, the sentinel switchover is complete, and then the sentinel automatically completes the primary and standby switchover of Redis.