Master-slave replication can avoid single points of failure. After master-slave replication is configured, when the master redis writes data, it will be replicated to two slave redis services through the master-slave replication mechanism, ensuring real-time data synchronization.
Server planning
Configure Redis master-slave replication through the following three servers:
| CPU name |
THE |
IP |
use |
Remarks |
| CentOS 7_107 |
CentOS7 |
192.168.1.107 |
Master/ write |
Redis5 |
| CentOS 7_108 |
CentOS7 |
192.168.1.108 |
Slave/ read |
Redis5 |
| CentOS 7_109 |
CentOS7 |
192.168.1.109 |
Slave/ read |
Redis5 |
1. Redis master-slave replication configuration steps
After installing Redis on the three servers,
107 master does not need any configuration, configure the following contents on 108 and 109 slaves respectively
Modify the redis.conf file on the slave server
# replicaof <masterip> <masterport>
replicaof 192.168.1.107 6379
Note: The master-slave configuration properties of Redis have changed since 5.0, and slaveof was configured before 5.0
Become replicaof after 5.0
The above configuration shows that the current [master server] corresponding to the [slave server] has an IP of 192.168.1.107 and a port of 6379.
Start all three redis services and connect to redis on host 107
Execute the following command to add a piece of data
set aa 123
Execute the get aa command after connecting to redis at 108 and 109 respectively
You can see that the result is the value of aa written on the host
Shows our Redis master-slave replication implementation.
127.0.0.1:6379> get aa
"123"
127.0.0.1:6379>
An error will be reported when writing data on the slave 108, 109, prompting
(error) READONLY You can't write against a read only replica.
Indicates that the Redis of the slave is in read-only mode, and only the master can write data
2. Redis sentry mechanism
The Sentinel process is used to monitor the working status of the Master master server in the redis cluster. When the Master master server fails, it can switch between Master and Slave servers to ensure the high availability of the system.
Implementation steps:
- The first step: copy sentinel.conf
Copy the sentinel.conf file in the /usr/local/app/redis-5.0.5 directory to the /usr/local/redis//bin/ directory
cp sentinel.conf /usr/local/redis//bin/- Step 2: Modify sentinel.conf
vim sentinel.confmodify:
sentinel monitor mymaster 192.168.1.107 6379 2
Configuration description: monitor 107 hosts, where the master-name can be customized, and quorum is a number that indicates how many sentinels consider a master to be invalid before the master is truly invalid. The master-name can only contain English letters, numbers, and the three characters ".-_". It should be noted that the master-ip must write the real ip address
- Step 3: Start the sentinel, respectively in the bin directory of the redis of the 108 and 109 slaves
Execute command (front-end start)
./redis-sentinel sentinel.conf 
- Test whether the sentinel mechanism is normal
Stop the Redis process of host 107
In the output of the slave 108 and 109 sentry console, you can see that the 108 slave has become the master.
At this time, write a value after connecting to Redis on the 108 host
Check the value after 109 slaves connect to Redis
From the above results, we can see that 108 becomes the master and can write data, and the 109 slave can view the written value, indicating that the sentinel mechanism is successfully configured.
The conclusion is drawn from the above: when the 107 master is down, the 108 and 109 slaves monitor that the 107 master has lost contact, and the slave 108 will be selected as the master. At this time, 108 can write operations, and 109 is still a slave so it can only read data. .
Note: When the 107 master is reconnected, it will become a slave. As shown below:
Start sentinel at the back end
- Modify the following in the sentinel configuration file
daemonize yes
logfile "/var/log/sentinel_log.log"Start sentinel
redis-server sentinel.conf --sentinel