The following notes and experiments are from the video teaching of The Chinese Stone fir bigman, I followed the experiment, and sorted out the notes in the class.

Redis master-slave architecture

Using Redis in a project is necessarily because we want to achieve high concurrency. Redis is a very important part of supporting high concurrency in a large cache architecture, but redis alone is not enough.

The bottleneck that Redis cannot support high concurrency is that it is impossible to say that the QPS of redis cannot exceed 100,000 + unless you have a very good machine performance, good maintenance, and your overall operation is not too complex.

Therefore, read/write separation is generally used to support high concurrency, with few write requests and a large number of requests being read. Therefore, the master-slave architecture of Redis is a better choice. The master-slave architecture -> read/write separation -> horizontal expansion supports high read concurrency, with the master node used for writing and the slave node used for reading.

PS: In version 5.0.4 I used, the term “slave” has been replaced by replica. The authorities have changed it anyway, so I have changed it all.

• Changing Redis master-slave replication terms with something else

The core mechanism of Redis Replication

• Redis copies data from the master node to the replica node asynchronously. However, starting from Redis 2.8, the Replica node periodically confirms the amount of data it copies each time
• A master node can be configured with multiple Replica nodes
• Replica nodes can also connect to other replica nodes
• The replica node does not block the normal operation of the master node
• Replica node does not block its own search operations when copying. It uses old data sets to provide services. However, when the replication is complete, the old data set needs to be deleted and the new data set needs to be loaded. At this time, the external service will be suspended
• Replica node is used for horizontal expansion to separate read and write. The expanded replica node improves read throughput

The core principles of Redis master-slave replication

When a Replica node is started, it sends a PSYNC command to the master node.

If the Replica node connects to the Master node for the first time using PSYNC, a full resynchronization is triggered. At this point, the master starts a background thread to generate a snapshot file of the RDB and cache all the new write commands received from the client. After the RDB file is generated, the master sends the RDB to the replica. The Replica first writes the RDB to the local disk and then loads it to the replica from the local disk. The master then sends the write commands cached in the memory to the replica. Replica also synchronizes this data. If the replica node is disconnected from the master node due to a network fault, it automatically reconnects. After the connection, the master node copies only the missing data to the replica.

What is the PSYNC command

• Introduction and explanation of PSYNC

In short, PSYNC determines whether the secondary server needs full or incremental replication. After all, full replication is required every time the primary node is reconnected due to a slight network fluctuation, which is very inefficient

PSYNC formats:

PSYNC runid offset

runid

Each Redis server will have an ID that identifies it. The ID sent in PSYNC is the ID of the previously connected Master. If this ID is not saved, the PSYNC command will use the “PSYNC? -1 “is sent to the Master, indicating that full replication is required.

Offset (replication offset)

Both the Master and replica maintain an offset respectively. After the Master sends N bytes of commands, the replica adds N to the Master’s offset. After the replica receives N bytes of commands, the replica also adds N to the replica’s offset. If Master and Replica are in the same state, their offsets should be the same.

Full copy process

• After receiving the full copy command, the master node runs the BGSave command to generate a local RDB snapshot file. And use a buffer (called the copy buffer) to record all write commands executed from now on. The redis configuration file has a parameter: client-output-buffer-limit Replica 256MB 64MB 60

If the memory buffer consumes more than 64MB for more than 60 seconds during the replication, or exceeds 256MB at a time, the replication fails. The last two parameters are used together, if: the consumption exceeds 64MB for 59 seconds, but at 60 seconds it does not exceed 64MB, then the connection is kept and replication continues.

• The master node sends the RDB snapshot file to the Replica node. If the RDB replication time exceeds 60 seconds (Parameter of redis configuration file: Rep-timeout), then the Replica node will consider the replication failure and adjust this parameter appropriately (for a machine with gigabit network adapter, it usually transmits 100MB and 6G files per second, which may exceed 60s).

• When the master node generates an RDB, it caches all new write commands in the memory. After the Replica node saves the RDB, the master node copies the new write commands to the Replica node. The node first cleans up its old data and then loads the received RDB file

• The master node sends all the write commands in the replication buffer to the slave node, which executes these write commands. If AOF is enabled on the slave node, bgreWriteAOF is triggered to ensure that the AOF file is updated to the latest state on the master node

Partial replication process (incremental replication)

• If the master-Replica network connection breaks during the full replication, incremental replication is triggered when the replica reconnects to the master.

• The master directly obtains the missing data from his own backlog and sends it to the replica node. The default backlog is 1MB.

• The master obtains data from the backlog based on the offset in the Psync sent by the Replica.

For example, if the master node’s offset is 1000 and the slave node’s offset is 500, then partial replication needs to pass data with offset 501-1000 to the slave node

Complete replication process

When the replica node starts, the replica node stores the master node information, including the host and IP address of the master node. However, the replication process does not start.

The replica node has a scheduled task to check whether there is a new master node to be connected and replicated every second. If so, establish socket network connection with the master node. The Replica node then sends the ping command to the master node. If master has requirePass set, the Replica node must send Masterauth’s password for authentication. The master node performs full replication for the first time and sends all data to the replica node. Subsequently, the master node asynchronously copies the write command to the Replica node.

• Step 1: Two fields, masterHost and MasterPort, are maintained internally on the slave node server to store the IP address and port information of the master node.

• Step 2: Establish a socket connection. That is, replicationCron() is invoked once every second on a secondary node. If a primary node is available for connection, a socket connection is created based on the IP address and port of the primary node

• Step 3: Authentication. If the masterauth option is set in the slave node, the slave node needs to authenticate to the master node. If this option is not set, no authentication is required. Authentication from the slave node is done by sending the auth command to the master node. The parameter of the auth command is the value of masterauth in the configuration file. If the password status on the master node is the same as that on the slave node masterauth (consistent means both exist and the password is the same, or neither exists), the authentication succeeds and the replication continues. If no, disconnect the socket from the secondary node and reconnect the socket.

• Step 4: Data synchronization, that is, full or incremental replication. In the replication phase, write commands are stored in the memory of the primary node and then sent asynchronously to the replica node

If the connection between the Replica node and the master node is disconnected due to a network fault, the replica node automatically reconnects. If the master finds that multiple replica nodes are reconnected, only one RDB save operation is initiated to serve all replica nodes with one copy of data.

Breakpoint continuation for master/slave replication

Since Redis 2.8, breakpoint continuation of master/slave replication is supported. If the network connection is down during master/slave replication, the replication can continue where the last copy was made, rather than starting from scratch

The master node has a common backlog in the memory. Both the master and replica store a replica offset and a master ID. The offset is stored in the backlog. If the connection between the master and replica network breaks, the replica asks the master to continue copying from the previous replica offset

But if no offset is found, a resynchronization is performed.

Diskless replication

The master creates the RDB in the memory and sends it to the replica. Simply enable repl-diskless-sync yes in the configuration file.

repl-diskless-sync yes

Wait 5 seconds before starting replication, because more replicas need to reconnect
repl-diskless-sync-delay 5
Copy the code

Handling expired Keys

Replica does not expire the key, but only waits for the master to expire the key. If the master expires a key, or a key is discarded via the LRU, a del command is simulated and sent to replica.

heartbeat

Both the primary and secondary nodes send heartbeat information to each other.

By default, the master sends a heartbeat every 10 seconds, and the Replica node sends a heartbeat every 1 second.

The implications of master persistence for master-slave architecture security

If you are using a master/slave architecture, it is recommended that persistence be enabled for the Master Node! How to implement redis persistence

Moreover, it is not recommended to use replica node as the hot standby data of the master node. If you turn off the persistence of the master, the data may be empty during the master downtime and restart, and the Replica node data may also be lost after replication

In addition, the master of various backup schemes, also need to do. In the event that all local files are lost, a Replica node can automatically take over the master node by selecting an RDB from the backup to restore the master. This ensures that data is available when the replica node is started. However, it is also possible that the master node restarts automatically before Sentinal detects the master failure, or all replica node data above may be cleared.

Implementing the master-slave replication architecture of Redis (one master, one slave)

• Environment set up

In addition to the parameters configured when installing Redis, the slave node also needs to configure the following

Configure the primary node (eshop-cache01) configuration file

• Modify it in the configuration fileThe bind 127.0.0.1 为 The bind 192.168.0.30Its own IP address

If bind 0.0.0.0 is set to its own IP address, run redis-cli -h 192.168.0.30 to access the redis client

• Configuring an Authentication Passwordrequirepass redis-pass, is the login password to redis

Configure the secondary node (EShop-cache02) configuration file

• Change bind 127.0.0.1 to bind 192.168.0.31’s own IP address in the configuration file

• Configure Replicaof. Set replicaof to replicaof eshop-cache01 6379 eshop-cache01 I have configured the IP address mapped to the host in the /etc/hosts directory of the master node

Replicaof specifies the IP address and port number of the active node

• Enabling security authentication Masterauth Redis-pass Specifies the login password of the master node. You need to configure this password in the configuration file of the active node

• Replica mandatory read/write separation -read-only yes This is enabled by default

You can choose whether to enable AOF persistence

Test master/slave replication (read/write separation)

Start the redis instance of the master node and the slave node successively, enter the client of the master node, set K1 v1, and then check whether the data can be read from the slave node. If the data is read, it means success.

The info replication command can be used to check whether it is a primary or secondary node

Further reading

• Redis master-slave architecture

• Learn more about Redis (3) : Master slave replication