Foreword:
Redis persistence ensures that data will not be lost even if the redis service is restarted, because the data persisted on the hard disk will be restored to the memory after the redis service restarts. However, when the hard disk of the redis server is damaged, data may be lost. If This single point of failure can be avoided through the master-slave replication mechanism of redis.
Although Redis is very fast in reading and writing, it also produces a situation where the reading pressure is particularly high. In order to share the reading pressure, Redis supports master-slave replication. The master-slave structure of Redis can adopt a single-master-multiple-slave or cascade structure: Redis master-slave replication can be divided into full synchronization and incremental synchronization according to whether it is full. The following figure shows the cascade structure:
Features of Redis master-slave replication:
1. The same master can have multiple slaves.
2. The slaves under the master can also accept connection and synchronization requests from other slaves in the same architecture to realize cascading replication of data, that is, master->slave->slave mode;
3. The master synchronizes data to the slave in a non-blocking manner, This will mean that the master will continue to process the client's read and write requests;
4. The synchronization data on the slave side can also be modified to a non-blocking method. When the slave is performing a new synchronization, it can still use the old data information to provide query
5 , The master-slave replication of redis is scalable, that is, multiple slaves provide read-only query and data redundancy, and the master side specifically provides write operations to achieve read-write separation;
6. Disable the master data persistence mechanism by configuring the Its data persistence operation is handed over to the slave to complete, to avoid having an independent process in the master to complete this operation.
Full synchronization:
Redis full replication generally occurs in the Slave initialization phase. At this time, the Slave needs to copy all the data on the Master. Specific steps are as follows:
1) The slave server connects to the master server and sends the SYNC command;
2) After the master server receives the SYNC name, it starts to execute the BGSAVE command to generate the RDB file and uses the buffer to record all the write commands executed thereafter;
3) After the master server BGSAVE is executed, it sends snapshot files to all slave servers, and continues to record the executed write commands during the sending period;
4) After receiving the snapshot file from the server, discard all old data and load the received snapshot;
5) After the master server snapshot is sent, it starts to send the write command in the buffer to the slave server;
6) The slave server completes the loading of the snapshot, starts to receive command requests, and executes the write command from the master server buffer;
after completing the above steps, all operations for data initialization of the slave server are completed, and the slave server can receive it at this time. Read requests from users.
Note:
If the connection between the master and the slave is disconnected, the slave can automatically reconnect to the master. Depending on the version, the synchronization method after disconnection is also different:
Before 2.8: After a successful reconnection, a full synchronization operation will be automatically performed.
After 2.8: After the reconnection is successful, part of the synchronization operation is performed.
Incremental synchronization:
Redis incremental replication refers to the process of synchronizing write operations from the master server to the slave server when the slave starts to work normally after initialization.
The process of incremental replication is mainly that every time the master server executes a write command, it sends the same write command to the slave server, and the slave server receives and executes the received write command.
When the master persistence function is turned off, it will bring the security of replication:
when we deploy redis master-slave replication, it is generally strongly recommended to turn on the master persistence switch. Even if the persistence switch is not turned on in order to avoid the delay effect caused by persistence, the master should be configured not to start automatically. Because it is very dangerous to restart the master after an abnormal refresh, it will cause the data in the slave to be emptied.
Suppose we have a redis node A, set as master, and turn off the persistence function, and the other two nodes B and C are its slaves and replicate data from A.
If node A crashes and all data is lost, it will reboot the system to restart the process. But since persistence is turned off, even if it restarts, its dataset is empty.
And B and C will still copy data from A through the replication mechanism, so B and C will copy from A to an empty data set, and replace their own non-empty data set with this empty data set. So it is equivalent to losing all data.
Even with some tools, such as sentinel, to monitor the master-slaves cluster, the above situation can occur, because the master may crash and recover quickly. The speed is so fast that the sentinel cannot detect a failure has occurred.
The process of master-slave replication after redis2.8:
before redis2.8, every synchronization from redis will copy all the data from the master redis, if the slave redis is newly created, then copy all the data from the master redis. This is no The problem is, however, if the slave redis stops running, only a small part of the data may be out of sync with the master redis when it is restarted. At this time, starting redis will still copy all the data from the master redis, and this performance will definitely not copy only that small part. Out of sync data is high.
Partial replication:
After the slave connects to the host, it will actively initiate the PSYNC (partial synchronization) command, and the slave will provide the master's runid (machine ID, a randomly generated string) and offset (data offset, if the offset master-slave is inconsistent, it means that The data is not synchronized), the host verifies whether the runid and offset are valid. The runid is equivalent to the host authentication code, which is used to verify the host connected to the slave last time. If the runid verification fails, it will perform full synchronization. If the verification passes, it means that it has been synchronized. However, some data are synchronized according to the offset.
How partial replication works:
The primary server side maintains an in-memory buffer for the replication stream. Both the master and slave servers maintain a replication offset and master run id. When the connection is disconnected, the slave server will reconnect to the master server and then request to continue replication, if the two master run ids of the master and slave servers are the same , and the specified offset is still valid in the memory buffer, the copy will continue from the point where it was interrupted. If one of these conditions is not met, a full resync occurs. Since the master running id is not stored on disk, only a full sync can be performed if the slave is restarted.
Diskless replication:
Usually a synchronization requires creating an RDB file on disk and then reloading the file to synchronize data with the slave. Since disk reads and writes are very slow, this is a very stressful operation for the redis master. In 2.8.18, try to use diskless replication. In this setup, the process sends the RDB directly to the slaves without using disk for intermediate storage.
Master-slave switching:
What if the host hangs up?
We configure two sentinel processes:
vim sentinel.conf
port 26379
sentinel monitor mymaster 127.0.0.1 6000 2
sentinel auth-pass mymaster 123456vim sentinel.conf
port 26479
sentinel monitor mymaster 127.0.0.1 6000 2
sentinel auth-pass mymaster 123456Start the sentinel service:
redis-server sentinel.conf --sentinelView log:
[7014] 11 Jan 19:42:30.918 # +monitor master mymaster 127.0.0.1 6000 quorum 2
[7014] 11 Jan 19:42:30.923 * +slave slave 127.0.0.1:6002 127.0.0.1 6002 @ mymaster 127.0.0.1 6000
[7014] 11 Jan 19:42:30.925 * +slave slave 127.0.0.1:6001 127.0.0.1 6002 @ mymaster 127.0.0.1 6000Observed from the corresponding log, one master service, two slave services,
let 's kill the master process now
[root@localhost slave1]# ps -ef|grep redis
root 6960 1 0 19:29 ? 00:00:02 redis-server *:6000
root 6968 1 0 19:30 ? 00:00:01 redis-server *:6001
root 6975 1 0 19:30 ? 00:00:01 redis-server *:6002
root 7014 6570 0 19:42 pts/0 00:00:01 redis-server *:26479
root 7017 6789 0 19:42 pts/5 00:00:01 redis-server *:26379
root 7021 6729 0 19:46 pts/3 00:00:00 grep redis
[root@localhost slave1]# kill -9 6960We observe the log:
[7014] 11 Jan 19:43:41.463 # +sdown master mymaster 127.0.0.1 6000
[7014] 11 Jan 19:46:42.379 # +switch-master mymaster 127.0.0.1 6000 127.0.0.1 6001The master is switched, and when the service on port 6000 is restarted, it will become the slave of the service on port 6001.
Because sentinel changes the configuration of the corresponding sentinel.conf and redis.conf files when switching the master.
During this period, we also need to pay attention to a problem: the sentinel service itself is not omnipotent, and it will also go down, so we have to deploy the sentinel cluster and start a few more sentinels like me.
sentinel monitor mymaster 127.0.0.1 6000 2 这个后面的数字2,是指当有两个及以上的sentinel服务检测到master宕机，才会去执行主从切换的功能。