Shulou(Shulou.com)05/31 Report--

This article mainly shows you "What is master-slave replication in Redis". The content is simple and easy to understand and organized. I hope it can help you solve your doubts. Let Xiaobian lead you to study and learn "What is master-slave replication in Redis".

Redis supports master-slave replication, which can be enabled by executing slaveof (changed to replicaof after Redis5) or setting slaveof (changed to replicaof after Redis5) in the configuration file.

One principal and two clusters

One master with many followers

Master-Slave Basic Configuration Master Redis Configuration

The master Redis configuration basically does not need to be modified, and the key part is in the slave Redis configuration.

1. Copy a redis.conf file from Redis. 2. Modify the port number of # salve #port 6380 #Write the pid process number to the pidfile configuration file pidfile /var/run/redis_6380.pid logfile "6380.log" #Specify the data storage directory dir /usr/local/redis‐5.0.3/data/6380 #Note out bind#bind127.0.0.1 (bind is the IP of the NIC of your own machine. If there are multiple NIC, multiple IPs can be allocated, which means which NIC IPs of the machine are allowed for the client to access. In general, bind can not be configured in the intranet, and comments can be deleted.) 3. Configure master-slave replication #Copy data from the redis instance of the local master6379. Use slaveofreplicaof 192.168.0.60to configure read-only replica from the slave node before Redis 5.0. 4. Start the slave node redis‐server redis.conf5. Connect from node redis‐cli ‐p 63806, test writing data on instance 6379, 6380 Whether the instance can synchronize the newly modified data docker run --name redis-6381 -v /Users/yujiale/docker/redis/conf/redis6381.conf: The requested URL/etc/redis/redis. conf-v/Users/yujiale/docker/redis/conf/sentinel6381.conf was not found on this server./data --network localNetwork --ip 172.172.0.14-p 16381:6379 -d redis:6.2.6 redis-server /etc/redis/redis.conf --appendonly yes Role of master-slave configuration Read/write separation

One master and many slaves, master and slave synchronization

The master is responsible for writing, and the slave is responsible for reading.

Improve Redis performance and throughput

Master-slave data consistency problem

data disaster recovery

A slave is a backup to a host

Host downtime, slave readable but not writable

By default, slaves cannot be utilized by the host after the host is down

Sentinel can realize master-slave switching and achieve high availability

How Redis works Master-slave copy Full copy Master-slave copy

Only the first connection from Redis to the master Redis occurs as a full copy, and if it is a short point continuation it may be a full copy or a partial copy.

flowchart

1. Establish Socker long connection with master Redis

Slaver establishes socket connection with master

slaver associative file event handler

The processor receives RDB files (full copy), receives write commands propagated from the Master (incremental copy),

The master server accepts the slave server Socket connection and creates the corresponding client state. The slave server is the Client side of the master server.

Send ping command

1. Send "pong" , indicating normal

2, return error, indicating that the Master is not normal

3. timeout, indicating network timeout

1. Detect the read and write status of the socket

2. Check whether the Master can handle it normally

Slaver sends ping command to Master

Master's response:

permission verification

After the master-slave connection is normal, perform permission verification.

No password is set for master (requirepass=""), and no password is set for slave (masterauth="")

Master Settings Password (requirepass!= ""), from the value that requires setting password (masterauth= master's requirepass)

Or send password from slave to master via auth command

Master Redis receives PSYNC command

The bgsave command executed by the master Redis after receiving the PSYNC command generates the most recent rdb snapshot

Master Redis sends rdb snapshot to slave Redis

When the master Redis sends rdb snapshots to the slave Redis, the master will continue to receive requests from clients, and it will cache these requests that may modify the dataset in memory and store them in the relp buffer cache.

Synchronous snapshot phase: Master creates and sends snapshot RDB to Slave, Slave loads and parses snapshot. The Master also stores new write commands generated during this phase into the buffer.

4. Receive rdb snapshot from node

Empty old data after receiving rdb snapshot from node and load rdb file

5. Master Redis sends buffer cache files to slave Redis

Synchronous write buffer phase: Master synchronizes write commands stored in buffer to Slave.

6. Receive buffer cache file from node

Receive buffer cache file from node and load buffer cache file into memory

7. Master Redis continuously sends commands to slave nodes through Socker long connections

Receive the command sent by master Redis from Redis, execute the current command

overview

If you configure a slave for the master, it will send a PSYNC command to the master to copy data regardless of whether the slave is connecting to the Master for the first time. After master receives the PSYNC command, it will persist the data in the background. The latest rdb snapshot file will be generated through bgsave. During persistence, master will continue to receive requests from clients. It will cache these requests that may modify the dataset in memory. When persistence is complete, master sends the rdb file dataset to slave, which persists the received data to generate rdb and loads it into memory. The master then sends the previously cached command to the slave. When the connection between master and slave is broken for some reason, slave can automatically reconnect with Master. If master receives multiple slave concurrent connection requests, it will only persist once, instead of one connection once, and then send this persistent data to multiple slave concurrent connections.

partial copy of master-slave copy

The general process is similar to that of full replication, so I won't explain it too much.

brief description of

When the master and slave are disconnected and reconnected, the entire data is usually copied. However, since redis2.8, redis has switched to the command PSYNC that can support partial data replication to synchronize data, slave and master can only perform partial data replication after the network connection is disconnected (breakpoint continuation). The master creates a cache queue in its memory for copying data, caching the most recent data. The master and all its slaves maintain the copied data index offset and the master's process id, so when the network connection is lost, the slave requests the master to continue the incomplete copy, starting with the recorded data index. If the master process id changes, or if the slave data index offset is too old to be in the master cache queue, a full copy of the data will be made. Master-slave copy (partial copy, breakpoint continuation) flow chart:

incremental synchronization of master-slave replication

Redis incremental synchronization mainly refers to the process of synchronizing the write operations of the Master to the Slave when the Slave starts working normally after initialization.

Typically, every time a Master executes a write command, it sends the same write command to the Slave, which then receives and executes it.

Heartbeat detection of master-slave replication 1. Detecting master-slave connection status

Detecting the network connectivity status of the master and slave servers By sending the INFO replication command to the master server, you can list the slave servers and see how many seconds have passed since the last command was sent to the master. The value of lag should fluctuate between 0 and 1. If it exceeds 1, the connection between master and slave is faulty.

2. Assisted implementation of min-slaves

Redis can be configured to prevent the master server from executing write commands in unsafe conditions min-slaves-to-write 3 (min-replicas-to-write 3) min-slaves-max-lag 10 (min-replicas-max-lag 10) The above configuration indicates that the master server will refuse to execute write commands when the number of slaves is less than 3, or when the delay (lag) values of all three slaves are greater than or equal to 10 seconds. The delay value here is the lag value of the INFOReplication command above.

3. detect command loss

If the write command propagated by the master to the slave is lost halfway because of a network failure, then when the slave sends the REPLCONF ACK command to the master, the master will find that the slave's current replication offset is less than its own replication offset, and then the master will find the data missing from the slave in the replication backlog buffer according to the replication offset submitted by the slave and resend it to the slave. (reissue) incremental synchronization of networks: when the network is disconnected and connected again

How to determine whether a full copy or partial copy

After the client sends saveof, the master node judges whether it is the first replication, if yes, performs full replication, if not, determines whether it is consistent by runid offset, if yes, performs partial replication, otherwise, performs full replication.

The above is all the content of this article "What is master-slave replication in Redis". Thank you for reading it! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to 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.