Redis Research (12)-master-slave replication, redis research master-slave Replication

Redis Research (12)-master-slave replication, redis research master-slave Replication

In the previous section, we wrote Redis data persistence.

Http://blog.csdn.net/wtyvhreal/article/details/42916503

Through the persistence function, Redis ensures that no (or a small amount of) data is lost even when the server is restarted. However, because the data is stored on a server, if the hard disk of the server fails, data will also be lost. To avoid spof, we hope to copy multiple copies of the database to deploy them on different servers. Even if one server fails, other servers can continue to provide services. This requires that when the database on one server is updated, the updated data can be automatically synchronized to other servers,Redis provides the replication function to automatically synchronize data.

1. Configuration

The synchronized database can be divided into two types: master database and slave database ). The primary database can perform read/write operations. When a write operation occurs, the data is automatically synchronized to the slave database. The slave database is generally read-only and receives data synchronized from the master database. A primary database can have multiple slave databases, while a single slave database can have only one master database.

It is very easy to use the replication function in Redis. You only need to add"Slaveof master database IP Master database PortThe master database does not require any configuration. In order to display the copy process more intuitively, the following is a simple demonstration. We need to start two Redis instances on one server and listen to different ports, one of which serves as the primary database and the other as the slave database. First, we do not add any parameters to start a Redis instance as the primary database:

redis-server

By default, the instance listens to port 6379. Then, add the slaveof parameter to start another Redis instance as the slave database and let it listen to port 6380:

redis-server --port 6380 --slaveof 127.0.0.1 6379

At this time, any data changes in the primary database will be automatically synchronized to the slave database. Open redis-cli instance A and connect to the primary database:

redis-cli

Then open redis-cli instance B and connect to the slave database:

redis-cli -p 6380

Use the SET command in instance A to set a key value:

redis A＞SET foo barOK

This value can be obtained in instance B:

redis B＞GET foo"bar "

However, the slave database is read-only by default. If you modify the data in the slave database directly, an error occurs:

redis B＞SET foo hi(error) 

You can set slave-read-only to no in the configuration file of the slave database to make the slave database writable,However, any changes to the slave database will not be synchronized to any other database, and the changes will be overwritten once the corresponding data is updated in the master database.
The same is true for configuring multiple slave databases. You can add the slaveof parameter to all slave database configuration files to point to the same master database.
In addition to setting the slaveof parameter through the configuration file or command line parameters, you can also use the SLAVEOF command to modify the parameter during running:

redis＞SLAVEOF  127.0.0.1 6379

If the database is already a slave database of another primary database, The SLAVEOF command will stop synchronization with the original database and then synchronize with the new database. You can also use slaveofno one to stop the current database from synchronizing data from other databases to the primary database.

2. Principles

After a slave database is started, it will send the SYNC command to the master database. After receiving the SYNC command, the master database will start to save snapshots in the background (that is, the RDB persistence process ), and cache commands indirectly received during the retention period. After the snapshot is complete, Redi s sends the snapshot file and all cached commands to the slave database. After receiving the data from the database, the snapshot file is loaded and the cache command is executed. After the master-slave database is disconnected and reconnected, the above operations are re-executed. resumable data transfer is not supported.
The actual process is a little complicated. Because the Redi s server uses TCP to communicate, we can use the telnet tool to disguise it as a specific synchronization process from the database. First, connect to the master database in the command line (the default port is 6379, and there is no slave database connection ):

telnet 127.0.0.1 6379Trying 127.0.0.1...Connected  to localhost.Escape  chaacter  is '^]' .

Then, as a slave database, we need to send the PING command to check whether the master database can be connected:

PING+PONG

The primary database will reply + PONG. If you have not received a reply from the primary database, an error is returned. If the primary database requires a password to connect, we have to send the AUTH command for verification. Then, send the REPLCONF command to the primary database to describe its own port number (you can choose one here ):

REPLCONF  listening-port 6381+OK

Now you can start the synchronization process: Send the SYNC command to the master database to start synchronization. At this time, the master database sends the command back to the snapshot file and cache. Currently, the primary database only has one foo key, so the received content is as follows (the snapshot file is in binary format, starting from the third line ):

SYNC29REDI S0006?foobar ?6_?"

The slave database writes the received content to a temporary file on the hard disk, after the data is written, the database replaces the RDB snapshot file with the temporary file (the location of the RDB snapshot file is the configuration location for persistence, determined by the dir and dbfilename parameters ), the subsequent operations are the same as the recovery process started during RDB persistence. It should be noted that the slave database does not block during synchronization, but can continue to process commands sent from the client. By default, the slave database responds to commands with the data before synchronization. You can set the slave-serve-stale-data parameter to no to make the slave database reply an error to all commands (except INFO and SLAVEOF) before the synchronization is completed: "SYNC with master in progress."
After that, any data changes in the primary database will be synchronized to the slave database. The synchronization content is the same as the Redis communication protocol. For example, if we execute SET foo hi in the primary database, we will receive the following via telnet:

*3$3set$3foo$2hi

During the replication process, snapshots play a major role in both the primary database and the slave database. snapshots are taken as long as the replication is executed, even if we disable RDB persistence (by deleting all save parameters ). Furthermore, Redis tries to read the RDB file specified by the dir and dbfilename parameters at startup to restore the database whether or not RDB persistence is enabled.

3. Graph Structure

The slave database can not only receive the synchronization data of the master database, but also act as the master database at the same time to form A graph-like structure. The data of database A will be synchronized to database B and database C, data in B is synchronized to D and E. Data written to B is not synchronized to A or C, but to D and E,

4. read/write splitting

Read/write splitting can be achieved through replication to improve server load capabilities. In common scenarios, the read frequency is greater than the write frequency. When a single-host Redis instance cannot cope with a large number of read requests (especially resource-consuming requests, such as the SORT command) multiple slave databases can be created through the replication function. The master database only performs write operations, while the slave database is responsible for read operations.

5. Slave database persistence

Another relatively time-consuming operation is persistence. To improve performance, you can use the replication function to create one or more slave databases and enable persistence in the slave database, disable persistence in the primary database.When the slave database crashes, the master database will automatically synchronize the data, so there is no need to worry about data loss. When the primary database crashes, you need to use the slaveof no one command from the database to upgrade the database to the primary database for further service, after the original master database is started, use the SLAVEOF command to set it to the slave database of the new master database to synchronize the data back.