Features of redis master-slave copy
- The same master can have multiple slaves.
- The server Load balancer under the master node can also accept connections and synchronization requests from other Server Load balancer instances in the same architecture to achieve cascade replication of data, that is, master-> slave mode;
- The master node synchronizes data to the slave in a non-blocking manner, which means that the master will continue to process one or more slave read/write requests;
4. the slave data synchronization method can also be modified to a non-blocking method. When the slave executes a new synchronization, it can still use the old data information for query; otherwise, when slave loses contact with the master, slave will return an error to the client;
- Master-slave replication is scalable, that is, multiple slave specifically provides read-only query and data redundancy, and the master provides write operations;
- Disable the data persistence mechanism of the master node and hand over the data persistence operation to slaves. This avoids the need for an independent process in the master node to complete this operation.
Redis master-slave copy process
After the slave is connected to the master, slave sends a sync command to the Master. After the master receives the command, whether it is the first connection established during synchronization or the reconnection after the connection is closed, the master will enable the bgsave operation, start a background process, save a snapshot of the current master memory, and start to save all write commands after bgsave is called. After the master generates a snapshot, send the RDB file of the memory snapshot to slave. After the slave receives the RDB file sent by the master, it clears all old data, loads the received RDB file to the memory, and sends the RDB file to the slave, the server Load balancer starts sending the saved write operation logs to the Server Load balancer. The Server Load balancer performs these write operations. At this point, the master and slave data are consistent. After the write log is sent, the master node incrementally sends the write operations to slave to make the master and slave nodes consistent.
PS: when the master and slave are disconnected, slave can automatically establish a new connection. If the master receives synchronous connection commands from multiple slave instances at the same time, only one process is started to write the memory snapshot and then sent to all slave instances.
Master write, slave read Mechanism
Redis master-slave replication achieves data read/write separation through programs, so that the master is responsible for processing some requests, slave is responsible for processing read requests, and slave is responsible for processing more concurrent requests by extending the slave, reduces the load on the master.
PS: determine the user's read/write requests in the program, send the write request to the master, and send the Read Request to the slave for processing.
Redis master-slave copy configuration
Enable master-slave replication. In the simplest way, connect to the slave redis server and execute slaveof
Slaveof 192.168.100.126 6379 # configure host information
Masterauth # If the host has a password set, configure the password
Slave-serve-stale-data yes # configure whether to respond when the slave is synchronizing with the host. If the configuration is yes, the client may read the old data. If the configuration is no, when you request to read data, an error will be reported: sync with Master in progress.
Slave-read-only yes # Whether the slave is read-only. This configuration is writable and will not be synchronized to the host,
Repl-ping-slave-period 10 # interval between the Ping Command sent from the host and the host.
Repl-timeout 60 # host response timeout, which includes transmission timeout, Io timeout, and Ping timeout. Note that the timeout must be greater than the preceding interval. Otherwise, a timeout error will always be reported.
Repl-Disable-TCP-nodelay no # Whether to disable TCP nodelay. The official recommendations for this configuration are:
# By default we optimize for low latency, but in very high traffic conditions
# Or when the master and slaves are running hops away, turning this to "yes" May
# Be A Good Idea.
# By default, we aim to optimize low latency, but in high transmission conditions or the master and slave hosts are distributed out of many hops. We recommend disabling TCP-nodelay.
Slave-priority 100 # If the master node cannot work normally, one slave with the smallest priority value will be promoted to the master node among multiple slave instances. If the priority value is 0, the master node cannot be upgraded.
Redis learning-master-slave copy