What is master-slave replication
Master-slave replication is when we create a data archive, a copy of the data is stored on different machines.
Why use master-slave replication
In the redis Persistence mechanism, we have mentioned that to prevent data loss, Redis provides RDB and AOF to persist data in memory to disk. However, when a server failure occurs, such as a service disk failure, the data cannot be recovered. So what to do?
In order to avoid single point of failure, we need to deploy multiple copies of data on multiple different servers. Even if one server fails, the other servers can still provide services. This requires that when the data on one server is updated, the updated data is automatically synchronized to the other servers. This is called master-slave replication.
When the primary node is under heavy pressure, we can read the replicated node data in the way of read/write separation to improve our service performance
To summarize, master slave replication is used for the following reasons
- Data backup and Dr
- Service data read and write separation
Redis master/slave replication implementation
Redis is easy to implement. Just add the startup script or configure the Slaveof command in the configuration file
1. Start the command
When starting the Redis service, add the redis-server –slaveof IP (primary redisIP) port.
This configuration is changed to Replicaof after version 5.0, The author of Redis has started an issue on GitHub about “replacing Redis’ master/slave terms with other terms” because some people find the Redis terms “master/slave” offensive. ANTIREZ, author of Redis, has been asked to change the term, and even DHH, author of Ruby on Rails, has spoken out.
2. The configuration file is added
Environment two machines: 148.70.47.76(master),111.229.169.46 (slave)
1. 148.70.47.76 Start Redis directly
2. Modify 111.229.169.46redis configuration, add Slaveof 148.70.47.76 6379 configuration or use Replicaof configuration
More than 5.0
3. Start redis 111.229.169.46
Redis status = 148.70.47.76 redis status = 148.70.47.76 Redis status = 148.70.47.76 Redis status = 148.70.47.76 Redis status = 148.70.47.76 Redis status = 148.70.47.76 Redis status = 148.70.47.76 Redis status = 148.70.47.76
Check the status of 111.229.169.46 redis. It is found that role is the slave slave node and there is a master node whose IP address is 148.70.47.76.
3, Tips:
- Configure master/slave For security you can modify the masterauth property of the configuration file to add the synchronization password
- The slave node is recommended to use the read-only mode slave-read-only=yes. If the slave node modifies data, the master and slave data are inconsistent.
- Transmission delay: The primary and secondary servers are generally deployed on different machines. Therefore, network delay occurs during replication. Redis provides the repl-disable-tcp-nodelay parameter to determine whether to disable TCP_NODELAY. When the parameter is off: The system releases the information to the slave node regardless of the size and occupies the bandwidth, which is applicable to the scenario where the primary and secondary networks are in good condition. When this parameter is enabled, the primary node merges all data into TCP packets to save bandwidth. The default value is 40 milliseconds. The synchronization delay is 40 milliseconds depending on the kernel
Principle of master-slave replication
1. Main process
The main process of Redis is as follows:
Redis data synchronization is divided into full synchronization and incremental synchronization
2. Full synchronization
Full Redis replication usually occurs during the Slave initialization phase, when the Slave needs to make a copy of all data on the Master. The master server will start a background process to generate an RDB file from the data in Redis. Meanwhile, the server will cache all the write commands received from the client (including add, delete and modify). When the background save process is finished, the RDB file will be passed to the slave server. The slave server will save the RDB file on disk and load the data into memory by reading the file. After this, the master server will send the commands cached during this period to the slave server through redis transport protocol. The slave server then applies these commands in turn to its own local data set to achieve data consistency.
– The secondary server connects to the primary server and sends the SYNC command. – After receiving the SYNC name, the primary server starts executing the BGSAVE command to generate the RDB file and uses the buffer to record all write commands executed thereafter; – After the BGSAVE is executed, the primary server sends snapshot files to all secondary servers, and continues to record the write commands executed during sending. – After receiving the snapshot file from the server, discard all old data and load the received snapshot. – The primary server starts to send write commands in the buffer to the secondary server after the snapshot is sent. – After loading the snapshot from the server, start receiving command requests, and execute write commands from the master server buffer;
3. Incremental synchronization
Redis incremental replication refers to the process of synchronizing write operations on the master server to the Slave server when the Slave starts to work properly after the Slave is initialized. The process of incremental replication is that the master server sends the same write command to the slave server for each write command executed, and the slave server receives and executes the received write command.
4. Redis master/slave synchronization policy
When the master and slave are first connected, full synchronization is performed. After full synchronization is complete, incremental synchronization is performed. Of course, slave can initiate full synchronization at any time if needed. The Redis policy is to try incremental synchronization first anyway, and to require full synchronization from the slave machine if this fails.
Five, master and slave replication several architectural forms
One master and one subordinate
This command is used for failover of the primary node to the secondary node. If the write command of the primary node has high concurrency and requires persistence, you can enable AOF only on the secondary node (not required on the primary node) to improve the performance of the primary node. When the primary node is faulty, you can restore the primary node by backing up the secondary node.
One master has many followers
In a scenario with a large number of reads, multiple secondary nodes share the reads. However, the more nodes there are, the more times the primary node synchronizes the reads to multiple nodes, which affects the bandwidth and worsens the stability of the primary node
3. Tree-like master and slave
The disadvantage of having one master and multiple slaves (the master node pushes more times and has great pressure) can be solved by some solutions. The master node only pushes data once to the slave node 1, and then pushes data from the slave node 2 to the slave node 11 to reduce the pressure of the master node pushing
