Shulou(Shulou.com)06/02 Report--

This article focuses on "Redis master-slave replication-related configurations and solutions to common problems", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "Redis master-slave replication-related configurations and solutions to common problems"!

1. Master-slave replication related configuration

The configuration of master-slave replication is configured in slave nodes, so the following parameters are configured in slave nodes.

1 、 slaveof

The slave instance needs to be configured to point to the ip and port of master

2 、 masterauth

If the password is enabled for the master instance, the configuration item needs to enter the startup password of master. If the password is not enabled for master, the configuration needs to be commented out.

3 、 slave-server-stale-data

Specifies the action when the connection between slave and master is broken, which defaults to yes, indicating that slave will continue to answer requests from client, but the data may be out of date (unable to synchronize from master due to broken connection). If no is configured, all commands from the client request will be answered by "sync with master in prigress" except for the normal response to info and slaveof commands by slave until the connection between the slave and master is reestablished or the slave is promoted to master.

4 、 slave-read-only

Specifies whether slave is read-only and defaults to yes. If configured as no, this means that slave is writable, but the written content will be deleted after master-slave synchronization

5 、 repl-disable-tcp-nodelay

When pointing to slave to synchronize data, whether to disable the NO_DELAY option of scoket, and if configured to yes, disable NO_DELAY, then the tcp protocol stack will merge the unified transmission of packets, which can reduce the number of packets between master and slave nodes and save broadband, but will increase the time for data synchronization to slave. If the configuration is no, indicating that NO_DELAY is enabled, the tcp protocol stack will not delay the sending of packets, so the delay of data synchronization will be reduced, but larger broadband is required. In general, it should be configured as no to reduce the synchronization delay, but when the network load between master and slave nodes is already high, it can be configured as yes.

6 、 slave-priority

Specify the priority of slave. In a deployment environment with more than one salve, when master goes down, redis sentinel will upgrade the slave with the lowest priority value to master. It should be noted that if the configuration item is changed to 0, the corresponding slave will never be automatically promoted to master by redis sentinel.

two。 Master-slave replication Advanced FAQ 2.1 Separation of read and write

Read traffic is allocated to slave nodes, which is a very good feature. If a business only needs to read data, then we only need to connect a slave slave to read data.

Although reading and writing have the advantage of being able to assign this part to each slave slave, if it is not enough, just add the slave machine directly, but the following problems will occur

1. Replication data delay

There may be problems such as slave delay and inconsistent reading and writing on duty. Of course, you can also use the monitoring offset offset. If the offset is out of range, switch to master, and logically switch. The specific delay can be checked by info replication's offset indicator.

For scenarios where a large number of delays cannot be tolerated, an external monitoring program (consul) can be written to listen to the replication offset of the master node, trigger an alarm when the delay is large, or notify the client to avoid reading slave nodes with excessive delay.

At the same time, the slave-serve-stale-data parameter of the slave node is also related to this, which controls the performance of the slave node in this case: if it is yes (the default), the slave node can still respond to client commands; if it is no, the slave node can only respond to a few commands such as info, slaveof, and so on. The setting of this parameter is related to the data consistency requirements of the application; if the data consistency requirements are high, it should be set to no.

2. Write is only allowed when there are n slave node links

After the redis2.8, you can set up the slave node to write requests when there are N slave nodes linked, and then because redis uses asynchronous replication, there is no way to guarantee the given write request actually received by the slave node, so there is a possibility of data loss during the window period.

Let's explain how this feature works.

The slave node ping the master node every second, informing it that all replication streams are working

The master node remembers the latest ping received by each slave node

The user can configure the master node with a delay between the lowest value equal to the number of slave nodes and no more than the maximum value.

If there are at least N slave nodes, and if the delay is less than M seconds, the write will be accepted.

You may think that with the best efforts to ensure the data security mechanism, although the data consistency cannot be guaranteed, at least the data is lost within a few seconds of the time window. Generally speaking, the loss of range data is much better than that of no scope data loss.

If the condition is not met, the primary node will return an error and the write request will not be accepted

There are two parameters for host configuration:

Minimum number of connections from the host

Min-slaves-to-write

Maximum delay time

Min-slaves-max-lag

For example, if we provide the following settings to the primary server:

Min-slaves-to-write 3min-slaves-max-lag 10

Then when the number of slave servers is less than 3, or the lag values of all three slave servers are greater than or equal to 10 seconds, the master server will refuse to execute the write command.

3. How to choose, whether to separate reading and writing

There is no most suitable solution, only the most suitable scenario. Read-write separation requires that the business can tolerate a certain degree of data inconsistency, which is suitable for business scenarios with more read and write less. What is the purpose of read-write separation? it is mainly because it is necessary to establish an one-master-multi-slave architecture that can scale slave node horizontally to support greater read throughput.

2.2 Slave node failure

For the problem of slave node failure, you need to maintain a list of available slave nodes on the client side. When the slave node fails, immediately switch to another slave node or master node, and then redis Cluster can solve this problem.

2.2.1 inconsistent configuration

The difference between the host and the slave often leads to inconsistent configuration and problems between the host and the slave.

Data loss: sometimes there are configuration inconsistencies between the host and the slave, such as maxmemory inconsistency. if the host configuration maxmemory is 8g and the slave slave is set to 4G, it can be used at this time without error. But if you want to make it highly available and turn the slave node into the master node, you will find that the data has been lost and cannot be retrieved.

2.2.2 avoiding full replication

Full replication means that when the slave is disconnected and restarted, the runid changes, resulting in the need to copy all the data in the master host. This process of copying all the data is very resource-intensive.

Full copy is inevitable, for example, the first full copy is inevitable, this is we need to select a small master node and the maxmemory value is not too large, so it is faster. At the same time, choose to do full replication at the low peak.

2.2.3 reasons for full replication

1. The runid running by the master and slave nodes does not match. If the primary node is restarted, the runid will change. If the monitoring from the node to the runid is not the same, it will assume that your node is not secure. When a failover occurs, if the master node fails, the slave will become the master node. We'll talk about Sentinels and clusters later.

2. There is insufficient space in the replication buffer, such as the default 1m, which can be partially copied. However, if the buffer is not large enough, the network interruption is needed first, and partial replication cannot be satisfied. Secondly, we need to increase the replication buffer configuration (relbacklogsize) to enhance the buffering of the network.

2.2.4 resolving full replication

In some scenarios, you may want to restart the master node, for example, the memory fragmentation rate of the master node is too high, or you may want to adjust some parameters that can only be adjusted at startup. If you restart the master node using the usual means, the runid will be changed, which may lead to unnecessary full replication.

In order to solve this problem, Redis provides a way to restart debug reload: after restart, the runid and offset of the primary node are not affected, avoiding full replication.

For example, when there are many slave slaves under a host, the host master is down. After the master host is rebooted, all slave slaves have to make a full copy because the runid has changed. This will cause single-node and single-machine replication storms, which can be very expensive.

Resolve:

The tree structure can be used to reduce the consumption of master nodes by multiple slave nodes.

It is very useful for the slave node to use a tree tree, and the network overhead is given to the slave node in the middle layer without consuming the master node at the top level. However, this tree structure also brings the complexity of operation and maintenance, which makes it more difficult to handle failover manually and automatically.

2.2.5 stand-alone storm

Because of Redis's single-threaded architecture, multiple Redis instances are usually deployed on a single machine. When multiple master nodes (master) are deployed simultaneously on a single machine (machine), if each master host has only one slave slave, then when the machine goes down, a large number of full replications will occur. This is a very dangerous situation, and the bandwidth will be taken up immediately, resulting in unavailability.

Resolve:

You should spread the master nodes across multiple machines as much as possible to avoid deploying too many master nodes on a single machine.

Provide a failover mechanism when the machine where the master node is located fails to avoid intensive full replication after the machine is restored.

At this point, I believe you have a deeper understanding of "Redis master-slave replication-related configurations and solutions to common problems". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.