Redis master-slave replication

Redis Master slave copy

After the host data is updated, according to the configuration and Policy , Automatic synchronization to the standby machine master/slaver Mechanism ,Master Write first ,Slave Mainly reading

One master, many followers There is only one write server

effect ：

• Read / write separation

• Rapid recovery of disaster recovery

  A slave server G 了 , You should continue to use another slave server

If you worry about the Lord G 了 You can use clusters

practice ：

info replication View current status

Execute on the slave slaveof <ip> <port> Become the slave server of an instance

slaveof 127.0.0.1 6379

If master and slave All have passwords , And the password is the same （ must ）, Then the verification is successful .

Final effect ：

• Write... On the host , Data can be read from the slave computer , Write data on the slave and report an error
• The mainframe is down , Just restart it , Everything is as it was
• Reset is required to restart the slave ：slaveof 127.0.0.1 6379（ You can add configuration to a file . permanent .）

problem 1： A slave server Hung up for a while , And then live again . During this period, the master has written data , After restarting from the server , There are also data written during hanging , It will be copied automatically

The principle of master-slave replication

detailed ：

1. The first synchronization process between master and slave servers can be divided into three stages ：

• The first stage is to build links 、 Negotiate synchronization ;
• The second stage is that the master server synchronizes the data to the slave server ;
• The third stage is that the master server sends a new write command to the slave server .

psync The command has two parameters , These are the of the main server runID And replication progress offset.

runID, Every  Redis  The server will automatically produce a random  ID  To uniquely identify yourself . When the slave and master synchronize for the first time , Because I don't know the main server's  run ID, So set it to  “?”.
offset, Represents the progress of replication , The first synchronization , Its value is  -1.

Received... From server RDB After the document , The current data will be cleared first , Then load RDB file .

But during this period, the write command is not recorded to the newly generated RDB In file , At this time, the data between master and slave servers is inconsistent .

So in order to ensure the data consistency of the master and slave servers , The main server will be in RDB Write command received after file generation , Write to replication buffer In the buffer .

The third stage ： The master sends a new write command to the slave

Generated on the main server RDB After the file is sent , And then replication buffer The write command recorded in the buffer is sent to the slave server , Then perform these operations again from the server .

thus , The first synchronization between the master and slave servers is complete .

2. After the first synchronization, the master and slave servers , There will be one between the two sides TCP Connect

Command propagation based on long connections , In this way, the data consistency of the master and slave servers after the first synchronization is guaranteed .

problem ：

After the first synchronization, the master and slave servers , Command propagation is based on long connections .

But , The Internet is not always playing according to the routine , Delay means delay , Say disconnect and disconnect .

If the network connection between master and slave servers is broken , Then there is no command propagation , At this time, the data from the server can not be consistent with the master server , The client may start from 「 From the server 」 Read old data .

stay Redis 2.8 Before , If the master and slave servers break down and recover during command synchronization , The slave server will have a full replication with the master server again , Obviously, it's too expensive , There has to be a wave of improvement .

from Redis 2.8 Start , After the network is disconnected and restored , The slave server will adopt Incremental replication Keep syncing in the same way , That is to say, only the write operation command received by the master server during network disconnection will be sent , Synchronize to the slave server .

There are three main steps ：

 After recovering the network from the server , Will send  psync  Command to the primary server , At this time  psync  In the order  offset  The parameter is not  -1;
 After the master server receives the command , And then use  CONTINUE  The response command tells the slave server to synchronize the data by incremental replication ;
 Then the master service will disconnect the master and slave servers during , The executed write command is sent to the slave server , Then execute these commands from the server .

There are three modes of master-slave replication ： Copy in full 、 Command propagation based on long connections 、 Incremental replication .

It's passed down from generation to generation

You can know that the master and slave servers are in the process of the first data synchronization , The main server does two time-consuming operations ： Generate RDB File and transfer RDB file .

We are 「 From the server 」 On the implementation replicaof < Target server's IP> 6379, Make it a slave of the target server . Another slave server is attached to the slave server

The disadvantage is that it hangs from the server The other one has never been able to synchronize （ My from from from Not mine hhhhhh）

Sentinel mode - Going to

Manual ：

When one master After downtime , hinder slave Can be promoted to master, Behind it slave You don't have to make any changes . use slaveof no one From slave to host .

Sentinel mode ： Be able to monitor the failure of the host in the background , If it fails, it will automatically convert from the library to the main library according to the number of votes

To configure

example ： On the basis of one master and two slaves operation

New under the directory sentinel.conf file , The name must not be wrong .

Content ：

sentinel monitor mymaster 127.0.0.1 6379 1

among mymaster Server name for the monitored object , 1 For at least how many sentinels agree to move the number .

The third parameter ： Sentry name , You can modify .（ If the modified , Then everything involved later has to be synchronized ）
Fourth parameter ：master host ip Address
Fifth parameter ：redis Port number
Sixth parameter ： The number of sentinels . such as 2 Express , When at least 2 A sentry found master Of redis Hang up , Then I will master Mark as down node .
At this time, failover will take place , Change one of them from node to master

redis-sentinel /myredis/sentinel.conf Start sentinel mode

After the host hangs up Sentinel output ： Below the red line

+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381

I chose 6381 This one serves as the host , The original 6379 After restart, it becomes a slave （ If 3679 No password configured Configure a consistent password ）

Which is elected as the host from the opportunity ？

According to priority ：slave-priority

Offset refers to the most complete data of the original host

Every redis After the instance is started, it will generate one randomly 40 Bit runid

The priority is redis.conf The default ：slave-priority 100,（ Some versions are replica-priority） The lower the value, the higher the priority

Reference resources

Reference resources