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

This article mainly introduces how to build Redis one master, two slaves and three sentinels based on Docker. It is very detailed and has a certain reference value. Interested friends must finish reading it!

Three CVMs have been prepared for this experiment. The system is Debian,ip:

35.236.172.131, 35.201.200.251,34.80.172.42 .

First install docker on the three hosts, then start a redis container on each host to run the redis-server service, with 35.236.172.131 as master and the other two machines as slave. Finally, start a redis container on each of the three hosts to run redis-sentinel. Why is it still redis container? Because sentinel is actually a redis-server, it is only executed in sentinel mode and can only handle some of the commands needed by sentinel.

Install docker

There are many ways to install docker, which is not covered here.

Https://docs.docker.com/install/linux/docker-ce/debian/

However, the following command modifies the mirror source to Aliyun on the basis of the official website command, because domestic images tend to be faster.

Script installation of docker

Run the following command on the physical host or CVM to complete the docker installation. Of course, I am on the Debian system, and other systems 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 both the client and server models, so you need to run the server that runs docker first, which runs in the form of daemon. Docker CE is the community version of docker.

$sudo systemctl enable docker$ sudo systemctl start docker

Verify that docker is installed successfully

$docker run hello-world

If the running result is as follows, Hello from docking appears, indicating that docker has been installed successfully

$docker run hello-worldUnable to find image 'hello-world:latest' locallylatest: Pulling from library/hello-world1b930d010525: Pull complete Digest: sha256:6540fc08ee6e6b7b63468dc3317e3303aae178cb8a45ed3123180328bcc1d20fStatus: Downloaded newer image for hello-world:latest Hello from docking 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 created 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-slave

After the docker installation is successful, you can begin to deploy the redis service. First pull the redis image from the docker official public repository, then modify the configuration file of the redis service, and finally start the container and start the redis server. Run the redis server on multiple machines and establish a master-slave relationship.

The master-slave of redis is the basis for the high availability of redis clusters and redis sentinels. The master-slave structure of redis enables the slave to copy the data on the master. If the slave is disconnected from the master network, the slave will automatically reconnect to the master.

Get Redis image

The following command pulls the latest official version of the redis image

$docker pull redis

View Mirror

$docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEredis latest bb0ab8a99fe6 7 days ago 95MBhello-world latest fce289e99eb9 6 months ago 1.84kB

Get and modify the redis configuration file

Redis officially provides a sample configuration file, which is downloaded through the wget tool. The root user I used was downloaded 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 a service to experiment with, so I only modify a few items that are necessary. If it is to be applied online, all configurations must be modified as required.

The configuration files used by the master and slave roles of the redis server are also somewhat different, which are described below.

For master, the configuration file modifies the following

# comment this line, indicating that Redis can accept any ip connection # bind 127.0.0.1 # turn off the protected mode protected-mode no # and let the redis service backend run daemonize yes # to set the password (optional, if the password requirement is enabled here, this password will be added to the configuration of slave. Just practice the configuration, do not use password authentication) # requirepass masterpassword # configure the log path, to facilitate troubleshooting, specify the redis log file directory logfile "/ var/log/redis/redis.log"

For slave, the configuration file modifies the following:

# comment this line, indicating that Redis can accept connections to any ip # bind 127.0.0.1 # turn off protected mode protected-mode no # Let redis service backend run daemonize yes # set password (optional, if password requirement is enabled here, this password will be added to slave configuration) requirepass masterpassword # set the password of the main library for authentication If the master library opens the requirepass option, you must fill in the corresponding password masterauth # to set the IP and port number of the master. The default port number in the redis configuration file is the lower version of redis, which means slaveof, because slave is a sensitive word, so the concept of slave is not used in the later version of redis. Instead, replica# will take 35.236.172.131 as the master and the other two machines as the slave. The ip and port number are modified accordingly according to the machine and configuration. Replicaof 35.236.172.131 6379 # configure the log path. To facilitate troubleshooting, specify the log file directory logfile "/ var/log/redis/redis.log" of redis

Start the container

We specify container aliases as redis-1, redis-2, and redis-3 on the three machines, respectively, so that it is easy to distinguish and explain. Docker specifies the alias of the container through the-- name parameter. Redis-1 is the alias of the container on master, and redis-2 and redis-3 are aliases on the two slave.

Let's take running the redis-3 container as an example to illustrate the container startup process. But first start the main server, 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 6379name redis-3-d-p redis/ bin/bash# container starts successfully, it will print a long list of containers IDa3952342094dfd5a56838cb6becb5faa7a34f1dbafb7e8c506e9bd7bb1c2951b# and use the ps command to check the status of the container You can see that redis-3 has started $docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESa3952342094d redis "docker-entrypoint.s..." 8 minutes ago Up 8 minutes 0.0.0.06379/tcp redis-3 6379-> 6379/tcp redis-3

The container has been started above, and then go into the container to start the redis server.

# enter the container redis-3$ docker exec-it redis-3 bash # in interactive mode to 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 $redis-server / usr/local/etc/redis/redis.conf # launch a redis client in the container $redis-cli # execute the info command Check the server status 127.0.0.1 info...# 6379 > if it is master, the value of role here will be master, if it is slave, the value of role here will be slaverole:slave# to slave, and check the attribute value of master_link_status. The value of the attribute up on slave means that the master-slave replication is OK, otherwise there will be a problem. If the slave status is not up, first check whether the port of the host is restricted, and then check the redis log to troubleshoot 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 if it will be synchronized to the slave.

# enter container redis-1 in interactive mode $docker exec-it redis-1 bash

Run a redis-cli and write a value to test_key

$redis-cli127.0.0.1:6379 > set test_key hello-worldOK

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 it is the same as the value on the host, the master-slave synchronization is successful. After testing, the active synchronization is successful.

127.0.1 6379 > get test_key "hello-world"

Add Sentinel

The master-slave structure has been successfully built, and the availability of the system has become higher, but if the master fails, the slave needs to be manually switched to the host. This kind of switching work is not only a waste of human resources, but also a greater impact is that redis can not provide services during the master-slave handover period. Therefore, the Sentinel system has been developed, and the Sentinel can automatically fail over after the master failure, select one from the slave machine to upgrade to the host, and continue to monitor the original host, when the original host is restored, it will be used as the slave of the new master.

The sentinel first listens to the master, gets the slave information by sending the info command to the master, and then listens to the slave as well. In addition, Sentinels will subscribe to the _ _ sentinel__:hello channel like the master. When a new Sentinel joins, a message will be sent to this channel, including the IP and port of the Sentinel, so other Sentinels who have subscribed to the channel will receive this message and will know that a new Sentinel has joined.

These Sentinels will establish a connection with the new entrants and Sentinels, and the elector needs to vote through this connection. This relationship can be described by the following diagram

Get and modify the sentinel configuration file

Get the configuration file of sentinel through the wget command

Wget http://download.redis.io/redis-stable/sentinel.conf

Modify the following items in the configuration file

# Let the sentinel service backend run daemonize yes # modify the path of the log file logfile "/ var/log/redis/sentinel.log" # modify the monitoring of the main redis server # the last 2 means that after the two machines determine that the active and passive are offline, the failover (failover) 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 name sentinel 26379-v / root/sentinel.conf:/usr/local/etc/redis/sentinel.conf-d redis/ bin/bash

Operational Sentinel

# enter the container $docker exec-it sentinel bash # to create a log directory and file $mkdir / var/log/redis$ touch / var/log/redis/sentinel.log # start Sentinel redis-sentinel / usr/local/etc/redis/sentinel.conf # to view logs The Sentinel successfully monitored the one-master and two-slave machine 18 Jul X 11 Jul 2019 13 25 Jul 55.416 # + monitor master mymaster 35.236.172.131 6379 quorum 218 quorum 218 X 11 Jul 2019 13 13 25 V 55.418 * + slave slave 35.201.200.251quorum 6379 35.201.200.251 6379 @ mymaster 35.236.172.131 637918 slave slave 35.236.172.131 637918 quorum X 11 1315 55.421 * + slave slave 34.80.172.422mer 6379 34.80.172.42 6379 @ mymaster 35.236.172.131

Running sentinel,sentinel in the same container in the same way on the other two machines uses the same configuration file.

Verify failover (failover)

In order to verify the automatic master-slave handover under the Sentinel mechanism, we kill the redis process on the master.

Wait a few seconds later, there is another upgrade from the host, the experiment is the third machine, that is, redis-3 upgrade to master, use the info command query to see that the role of the redis-3 server has become master. This indicates that the automatic master-slave switch is successful.

127.0.0.1 purl 6379 > info...# Replicationrole:master...

Then restart the master server that was dropped by kill before, and check it with the info command after startup, you can find that it has become the slave server of redis-3.

The following log describes 35.236.172.131 as a master startup, performing a failover master sentinel election, performing a failover, and establishing a new master-slave relationship.

Root@4355ca3260c5:/var/log/redis# cat sentinel.log 17 oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo17:X X 11 Jul 2019 13 oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo17:X 11 Jul 2019 13V 25V 55.395 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=17, just started17:X 11 Jul 2019 13V 55.395 # Configuration loaded18:X 11 Jul 2019 1315 25V 55.398 * Running mode=sentinel Port=26379.18:X 11 Jul 2019 13 quorum 25 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 cannot be enforced because X 11 Jul 2019 13V 25V 55.416 # Sentinel ID is 7d9a7877d4cffb6fec5877f605b975e00e7953c118:X 11 Jul 2019 13V 25V 55.416 # + monitor master mymaster 35.236.172.131 6379 quorum 218 WARNING 11 Jul 2019 13V 25V 255.418 * + slave slave 35.201.200.251v 6379 35.201.200 .251 6379 @ mymaster 35.236.172.131 637918 Jul 11 Jul 2019 13V 25V 55.421 * + slave slave 34.80.172.42V 6379 34.80.172.42 6379 @ mymaster 35.236.172.131 637918 slave slave 35.236.172.131 637918 slave slave 2019 140418 23.390 * + sentinel sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 637918 mymaster X 11 sentinel-invalid-addr sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 637918 ip 172.17.0.3 26379 @ mymaster 35.236.172.131 637918 port 26379 for 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e318:X 11 Jul 2019 14 mymaster 34.338 * + sentinel-invalid-addr sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 637918 for 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e318:X 11 Jul 2019 14 Jul 11 Jul 12.151 # + sdown master mymaster 35.236.172.131 637918 odown master mymaster 35.236.172.131 637918 odown master mymaster 1112.214 # + odown master mymaster 35.236.172.131 # quorum 4Grad 218 Jul 11 14V 1112.214 # + new-epoch 118V X 11 Jul 2019 14V 1112.214 # + try-failover master mymaster 35.236.172.131 637918 odown master mymaster 1112.235 # + vote-for-leader 7d9a7877d4cffb6fec5877f605b975e00e7953c1 118RX 11 Jul 2019 14Suzhou 11: 12.235 # 7d9a7877d4cffb6fec5877f605b975e00e7953c1 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 118 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 11 Jul 2019 14 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 1112. 235 # 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 118 Jul 2019 14V 1112.235 # 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 voted for 7d9a7877d4cffb6fec5877f605b975e00e7953c1 118V 11 Jul 2019 14V 1112.294 # + elected-leader master mymaster 35.236.172.131 637918V 11 Jul 2019 14V 1112.294 # + failover-state-select-slave master mymaster 35.236.172.131 637918V 1112.294 # + failover-state-select-slave master mymaster 35.236.172.131 637918 failover-abort-- No-good-slave master mymaster 35.236.172.131 637918 no-good-slave master mymaster 35.236.172.131 637918 Next failover delay: I will not start a failover before Thu Jul 11 14:17:12 201918 Next failover delay: 201918 Next failover delay 11 Jul 2019 14V 11 13.050 # + config-update-from sentinel 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 172.17.0.3 26379 @ mymaster 35.236.172.131 637918 Next failover delay 11 Jul 2019 14V 1113.050 # + switch-master mymaster 35.236.172.131 6379 34.80.172.42 637918: X 11 Jul 2019 14 mymaster 1113. 050 * + slave slave 35.201.200.251 6379 @ mymaster 34.80.172.42 637918 X 11 Jul 2019 14 mymaster 11.050 * + slave slave 35.236.172.131mymaster 6379 35.236.172.131 6379 @ mymaster 34.80.172.42 637918 mymaster 11 Jul 2019 43.077 # + sdown slave 35.236.172.131 6379 @ mymaster 34.80 .172.42 637918 Jul 11 Jul 2019 14 mymaster 11 43.077 # + Jul 35.201.200.251Visl 6379 35.201.200.251 6379 @ mymaster 34.80.172.42 637918 mymaster 12 Jul 01.51 sdown slave 35.236.172.131 6379 @ mymaster 34.80.172.42 637918 sdown slave 34.80.172.42 637918 sdown slave 541 * + convert-to-slave slave 35.236.172.131 6379 @ mymaster .236.172.131 6379 @ mymaster 34.80.172.42 6379

Redis achieves high availability through master-slave replication, but manual master-slave switching is needed in case of failure, which is inefficient. The sentry mechanism realizes the automatic switching between redis master and slave, improves the availability of redis cluster, and improves the failover efficiency of redis cluster.

The above is all the contents of the article "how to build Redis based on Docker one master, two slaves and three sentinels". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.