Implementation of Redis one master, two slaves and three sentinels based on Docker
|
I am currently learning about Redis and containers, so I want to use Docker to build a Redis master-slave system to deepen my understanding. To read this article, you may need a certain foundation in Docker, as well as some understanding of the redis master-slave and sentinel mechanisms. Three cloud hosts were prepared for this experiment. The system was Debian and the IP addresses were: 35.236.172.131 , 35.201.200.251, 34.80.172.42. First, install docker on these three hosts respectively, then start a redis container on each host and run the redis-server service, with 35.236.172.131 as the master and the other two machines as slaves. Finally, start a redis container on each of the three hosts and run redis-sentinel. Why is it still a redis container? Because sentinel is actually a redis-server, but it is executed in sentinel mode and can only process some commands required by sentinel. Install Docker There are many ways to install docker, which will not be introduced here. This time, we use the script to install Docker. The Debian system script installation is as follows. For other systems, you can refer to the installation method on the Docker official website: https://docs.docker.com/install/linux/docker-ce/debian/ However, the following command modifies the image source to Alibaba Cloud based on the official website command, because domestic images are often faster. Script installation docker Run the following command on the physical host or cloud virtual host to complete the docker installation. Of course, I am on the Debian system. For other systems, please refer to the methods on the official website. $ curl -fsSL https://get.docker.com -o get-docker.sh $ sudo sh get-docker.sh --mirror Aliyun Start Docker CE Docker runs in a client and server model, so you need to run the Docker server first. The server runs as a daemon. Docker CE is the community version of Docker. $ sudo systemctl enable docker $ sudo systemctl start docker Verify that Docker is installed successfully The following command pulls an image named hello-world from the official Docker repository and starts a container using this image. $ docker run hello-world If the running result is as follows, Hello from Docker! appears, indicating that Docker has been installed successfully. $ docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 1b930d010525: Pull complete Digest: sha256:6540fc08ee6e6b7b63468dc3317e3303aae178cb8a45ed3123180328bcc1d20f Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon creates a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ Start the container to build the master and slave After docker is installed successfully, you can start deploying the redis service. First, pull the redis image from the official Docker public repository, then modify the configuration file of the redis service, and finally start the container and start the redis server. Run redis servers on multiple machines and establish a master-slave relationship. The master-slave structure of redis is the basis for realizing the high availability of redis cluster and redis sentinel. The master-slave structure of redis enables the slave to replicate the data on the master. If the network between the slave and the master is disconnected, the slave will automatically reconnect to the master.
Get the Redis image The following command will pull the latest official version of the redis image $ docker pull redis View Mirror $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE redis latest bb0ab8a99fe6 7 days ago 95MB hello-world latest fce289e99eb9 6 months ago 1.84kB Get and modify the redis configuration file Redis officially provides a sample configuration file, which can be downloaded using the wget tool. I used the root user and downloaded it directly to the /root directory. $ wget http://download.redis.io/redis-stable/redis.conf After opening the downloaded file, you can see that there are many configurations. I just set up the service for testing so I only modified the necessary items. If you want to apply it online, all configurations must be modified as required. The configuration files used by the master and slave roles of the redis server are slightly different, which are explained below. For the master, the configuration file modifies the following items # Comment this line to indicate that Redis can accept connections from any IP address # bind 127.0.0.1 # Disable protection mode protected-mode no # Let the redis service run in the background daemonize yes # Set a password (optional. If the password requirement is enabled here, the password must be added to the slave configuration. This is just a practice configuration, so password authentication is not used) # requirepass masterpassword # Configure the log path. To facilitate troubleshooting, specify the redis log file directory logfile "/var/log/redis/redis.log" For slave, modify the following items in the configuration file: # Comment this line to indicate that Redis can accept connections from any IP address # bind 127.0.0.1 # Disable protection mode protected-mode no # Let the redis service run in the background daemonize yes # Set a password (optional. If the password requirement is enabled here, the password must be added to the slave configuration) requirepass masterpassword # Set the master database password for authentication. If the requirepass option is enabled for the master database, you must enter the corresponding password masterauth <master-password> # Set the master's IP and port number. The default port number in the redis configuration file is 6379 # In earlier versions of Redis, this will be slaveof, which means the same thing. Because slave is a sensitive word, the concept of slave is no longer used in later versions of Redis. Instead, it is replaced by replica # Set 35.236.172.131 as the master and the other two machines as slaves. The IP and port number should be modified according to the machine and configuration. replicaof 35.236.172.131 6379 # Configure the log path. To facilitate troubleshooting, specify the redis log file directory logfile "/var/log/redis/redis.log" Start the container Create the configuration files on the host and slave machines respectively according to the above method, and start the container after checking that they are correct. We specify the container aliases as redis-1, redis-2, and redis-3 on the three machines respectively, which makes it easier to distinguish and explain. Docker uses the --name parameter to specify the container alias. redis-1 is the alias of the container on the master, and redis-2 and redis-3 are the aliases on the two slaves. The following uses the redis-3 container as an example to illustrate the container startup process. The operations of containers redis-1 and redis-2 on the other two machines are the same, but please note that the configuration files of the master and slave are different. But first you need to start the main server, which is the redis-1 container. Then start redis-2 and redis-3. # First run the container in background mode $ docker run -it --name redis-3 -v /root/redis.conf:/usr/local/etc/redis/redis.conf -d -p 6379:6379 redis /bin/bash # After the container is successfully started, a long string of container IDs will be printed a3952342094dfd5a56838cb6becb5faa7a34f1dbafb7e8c506e9bd7bb1c2951b # Check the status of the container through the ps command, and you can see that redis-3 has been started. $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a3952342094d redis "docker-entrypoint.s..." 8 minutes ago Up 8 minutes 0.0.0.0:6379->6379/tcp redis-3 The container has been started above. Next, enter the container and start the redis server. # Enter container redis-3 in interactive mode $ docker exec -it redis-3 bash # Create a log file directory $ mkdir /var/log/redis/ $ touch /var/log/redis/redis.log # Start the redis server. If there is no output, it means success. $ redis-server /usr/local/etc/redis/redis.conf # Start a redis client in the container $ redis-cli # Execute the info command to view the server status 127.0.0.1:6379> info ... # If it is a master, the value of role here will be master, if it is a slave, the value of role here will be slave role:slave # For slave, also check the master_link_status attribute value. If the value of this attribute on the slave is up, it means that the master-slave replication is OK, otherwise there is a problem. If the slave status is not up, first check whether the host port is restricted, and then check the redis log to find the cause master_link_status: up ... # Finally exit the container $ exit Verify master-slave replication After the master-slave is successfully built, you can verify whether the master-slave synchronization is successful by writing a key-value value on the master to see whether it will be synchronized to the slave. # Enter the container redis-1 in interactive mode $ docker exec -it redis-1 bash Run a redis-cli and write a value to test_key $ redis-cli 127.0.0.1:6379> set test_key hello-world OK Enter the container on any slave machine and run a redis-cli to query the value of this key. If this value can be queried and is the same as the value on the host, it means that the master-slave synchronization is successful. After testing, active synchronization was successful. 127.0.0.1:6379> get test_key "hello-world" Add Sentinel The master-slave structure is successfully built, and the system availability becomes higher, but if the master fails, it is necessary to manually switch the slave to the master. This switching work not only wastes human resources, but also has the greater impact that redis cannot provide external services during the master-slave switching period. Therefore, the Sentinel system was developed. After a master failure, the Sentinel can automatically perform failover, select one of the slaves to upgrade to the master, and continue to monitor the original master. When the original master recovers, it will be used as the slave of the new master. The sentinel first monitors the master, obtains the slave's information by sending the info command to the master, and then monitors the slave as well. In addition, the sentinels will subscribe to These sentinels will establish connections with the newly joined sentinels, and the leader election needs to vote through this connection. This relationship can be described by the following diagram:
Get and modify the sentinel configuration file Get the sentinel configuration file through the wget command wget http://download.redis.io/redis-stable/sentinel.conf Modify the following configuration files # Let the sentinel service run in the background daemonize yes # Modify the log file path logfile "/var/log/redis/sentinel.log" # Modify the monitored main redis server# The last 2 means that after the two machines determine that the active and passive servers are offline, failover will be performed. sentinel monitor mymaster 35.236.172.131 6379 2 Start the container Similar to starting the redis container, start a container aliased as sentinel $ docker run -it --name sentinel -p 26379:26379 -v /root/sentinel.conf:/usr/local/etc/redis/sentinel.conf -d redis /bin/bash Run Sentinel # Enter the container$ docker exec -it sentinel bash # Create log directory and files $ mkdir /var/log/redis $ touch /var/log/redis/sentinel.log # Start sentinel redis-sentinel /usr/local/etc/redis/sentinel.conf # Check the logs, the sentinel successfully monitored one master and two slaves 18:X 11 Jul 2019 13:25:55.416 # +monitor master mymaster 35.236.172.131 6379 quorum 2 18:X 11 Jul 2019 13:25:55.418 * +slave slave 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 13:25:55.421 * +slave slave 34.80.172.42:6379 34.80.172.42 6379 @ mymaster 35.236.172.131 6379 Run Sentinel in a container in the same way on the other two machines. Sentinel uses the same configuration file. Verify failover In order to verify the automatic master-slave switching under the sentinel mechanism, we kill the redis process on the master. After a few seconds, another slave is upgraded to the master. In the experiment, it is the third machine, redis-3, which is upgraded to the master. You can use the info command to query and see that the role of the redis-3 server has become the master. This indicates that the automatic master-slave switch is successful. 127.0.0.1:6379>info ... # Replication role:master ... Then restart the master server that was killed before. After restarting, use the info command to check and you can find that it has become a slave server of redis-3. The following log describes how 35.236.172.131 starts as the master, elects a master sentinel for failover, performs failover, and establishes a new master-slave relationship. root@4355ca3260c5:/var/log/redis# cat sentinel.log 17:X 11 Jul 2019 13:25:55.395 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 17:X 11 Jul 2019 13:25:55.395 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=17, just started 17:X 11 Jul 2019 13:25:55.395 # Configuration loaded 18:X 11 Jul 2019 13:25:55.398 * Running mode=sentinel, port=26379. 18:X 11 Jul 2019 13:25:55.398 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 18:X 11 Jul 2019 13:25:55.416 # Sentinel ID is 7d9a7877d4cffb6fec5877f605b975e00e7953c1 18:X 11 Jul 2019 13:25:55.416 # +monitor master mymaster 35.236.172.131 6379 quorum 2 18:X 11 Jul 2019 13:25:55.418 * +slave slave 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 13:25:55.421 * +slave slave 34.80.172.42:6379 34.80.172.42 6379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 13:26:25.460 # +sdown slave 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:04:23.390 * +sentinel sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:04:25.418 * +sentinel-invalid-addr sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:04:25.418 * +sentinel sentinel 7d9a7877d4cffb6fec5877f605b975e00e7953c1 172.17.0.3 26379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:04:25.456 * +sentinel-address-switch master mymaster 35.236.172.131 6379 ip 172.17.0.3 port 26379 for 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 18:X 11 Jul 2019 14:08:34.338 * +sentinel-invalid-addr sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:08:34.338 * +sentinel sentinel 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 172.17.0.3 26379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:08:36.236 * +sentinel-address-switch master mymaster 35.236.172.131 6379 ip 172.17.0.3 port 26379 for 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 18:X 11 Jul 2019 14:11:12.151 # +sdown master mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:11:12.214 # +odown master mymaster 35.236.172.131 6379 #quorum 4/2 18:X 11 Jul 2019 14:11:12.214 # +new-epoch 1 18:X 11 Jul 2019 14:11:12.214 # +try-failover master mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:11:12.235 # +vote-for-leader 7d9a7877d4cffb6fec5877f605b975e00e7953c1 1 18:X 11 Jul 2019 14:11:12.235 # 7d9a7877d4cffb6fec5877f605b975e00e7953c1 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 1 18:X 11 Jul 2019 14:11:12.235 # 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 1 18:X 11 Jul 2019 14:11:12.235 # 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 1 18:X 11 Jul 2019 14:11:12.294 # +elected-leader master mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:11:12.294 # +failover-state-select-slave master mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:11:12.394 # -failover-abort-no-good-slave master mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:11:12.453 # Next failover delay: I will not start a failover before Thu Jul 11 14:17:12 2019 18:X 11 Jul 2019 14:11:13.050 # +config-update-from sentinel 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 172.17.0.3 26379 @ mymaster 35.236.172.131 6379 18:X 11 Jul 2019 14:11:13.050 # +switch-master mymaster 35.236.172.131 6379 34.80.172.42 6379 18:X 11 Jul 2019 14:11:13.050 * +slave slave 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 34.80.172.42 6379 18:X 11 Jul 2019 14:11:13.050 * +slave slave 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379 18:X 11 Jul 2019 14:11:43.077 # +sdown slave 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379 18:X 11 Jul 2019 14:11:43.077 # +sdown slave 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 34.80.172.42 6379 18:X 12 Jul 2019 01:54:05.142 # -sdown slave 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379 18:X 12 Jul 2019 01:54:15.087 * +convert-to-slave slave 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379 Summarize Redis achieves high availability through master-slave replication, but when a failure occurs, manual master-slave switching is required, which is inefficient. The sentinel mechanism realizes the automatic switching of redis master and slave, improves the availability of the redis cluster, and improves the failover efficiency of the redis cluster. The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM. You may also be interested in:
|
<<: Vue implements left and right sliding effect example code
>>: Detailed explanation of how to use grep to obtain MySQL error log information
Recommend
How to implement interception of URI in nginx location
illustrate: Root and alias in location The root d...
CentOS7 64-bit installation mysql graphic tutorial
Prerequisites for installing MySQL: Install CentO...
CSS3 realizes draggable Rubik's Cube 3D effect
Mainly used knowledge points: •css3 3d transforma...
Detailed explanation of the use of base tag in HTML
In requireJS, there is a property called baseURL....
Detailed explanation of the principles and usage of MySQL data types and field attributes
This article describes the MySQL data types and f...
Summary of Nginx location and proxy_pass path configuration issues
Table of contents 1. Basic configuration of Nginx...
Super detailed MySQL8.0.22 installation and configuration tutorial
Hello everyone, today we are going to learn about...
JavaScript+HTML to implement student information management system
Table of contents 1. Introduction 2. Rendering 3....
react-beautiful-dnd implements component drag and drop function
Table of contents 1. Installation 2.APi 3. react-...
JavaScript to implement input box content prompt and hidden function
Sometimes the input box is small, and you want to...
Detailed explanation of CSS3 rotating cube problem
3D coordinate concept When an element rotates, it...
How the Linux kernel breaks into the process address space and modifies the process memory
Isolation of process address spaces is a notable ...
Detailed explanation of MySQL limit usage and performance analysis of paging query statements
Limit usage When we use query statements, we ofte...
CentOS 7 switching boot kernel and switching boot mode explanation
centos7 switch boot kernel Note: If necessary, it...
Detailed explanation of Docker container cross-host multi-network segment communication solution
1. MacVlan There are many solutions to achieve cr...