Redis Research (12)-Data replication

In the previous section we wrote about the data persistence of Redis

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

With the persistence feature, Redis guarantees that there will be no loss (or small loss) of data even if the server is restarted. However, because the data is stored on a single server, if the server's hard disk fails, it can also cause data loss. To avoid a single point of failure, we want to replicate multiple copies of the database to be deployed on different servers, even if one server fails and other servers continue to serve. This requires that when the database on one server is updated to automatically synchronize the updated data to other servers,Redis provides the process of synchronizing the replication (replication) functionality automatically.

1. Configuration

The synchronized database is divided into two categories, one being the primary database (master) and one from the database (slave). The primary database can read and write, and the data is automatically synchronized to the slave database when a write operation occurs. And from the database is generally read-only, and accept the main database synchronized data. A primary database can have multiple slave databases, and one from a database can only have one primary database.

Using the copy feature in Redis is easy, simply by adding "slaveof primary database IP primary database port " from the configuration file of the database, without any configuration of the primary database. To be able to visualize the process of copying more visually, a simple demonstration is presented below. We're going to start two Redis instances on one server, listen to different ports, one 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

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

Redis-server--port 6380--slaveof 127.0.0.1 6379

Any changes in the data in the primary database are automatically synchronized to the slave database at this time. We open REDIS-CLI instance A and connect to the primary database:

Redis-cli

Then open REDIS-CLI instance B and connect to the From database:

Redis-cli-p 6380

Set the value of a key using the SET command in instance a:

Redis a>set Foo Barok

The value is now available in instance B:

Redis b>get foo "bar"

However, by default, the database is read-only, and if you modify data directly from the database, an error occurs:

You can write from the database by setting the slave-read-only in the configuration file from the database to No, but any changes from the database will not be synchronized to any other database, and changes from the database will be overwritten once the corresponding data is updated in the primary database.
The same approach to configuring multiple slave databases is to add the slaveof parameter to the same primary database in all the configuration files from the database.
In addition to setting the Slaveof parameter through a configuration file or command line parameter, you can also modify it at run time using the slaveof command:

Redis>slaveof  127.0.0.1 6379

If the database is already from a database of other primary databases, The slaveof command stops synchronizing with the original database and synchronizes with the new database. You can also use slaveofno one to make the current database stop receiving synchronization from other databases into the primary database .

2. Principle

When one starts from the database, the Sync command is sent to the primary database, and the master database receives the sync command to start saving the snapshot in the background (that is, the RDB persistence process) and caches the commands that are received indirectly during the retention period. When the snapshot is complete, Redi s sends the snapshot file and all cached commands to the slave database. When received from the database, the snapshot file is loaded and the cached command is executed. When the master-slave database is disconnected, the above operation is re-executed, and the breakpoint is not supported for continuous transmission.
The actual process is slightly more complicated, because the Redi s server communicates using the TCP protocol, so we can use the Telnet tool as a concrete process to understand synchronization from the database. Connect to the primary database at the command line first (the default port is 6379 and there is no connection from the database):

Telnet 127.0.0.1 6379Trying 127.0.0.1...Connected to  localhost. Escape  cha acter  i s ' ^] '.

Then as from the database, we first send the ping command to confirm whether the primary database can be connected:

Ping+pong

The primary database will reply to +pong. If you do not receive a reply from the primary database, the user is prompted with an error. If the primary database requires a password to connect, we also have to send the AUTH command for verification. Then send the replconf command to the main database to describe your port number (choose one here):

replconf  l Istening-por t 6381+ok

At this point, you can start the synchronization process: Send Sync command to the primary database to begin synchronization, at which point the primary database sends back the snapshot files and cached commands. Currently there is only one Foo key in the main database, so the content received is as follows (the snapshot file is in binary format, starting with the third line):

Sync29redi s0006?foobar? 6_? "

The received content is written to a temporary file on the hard disk from the database, and the Rdb snapshot file is replaced with the temporary file (the location of the Rdb snapshot file is the location configured at the time of the persistence, as determined by the Dir and dbfilename two parameters) when the write is completed from the database. The subsequent operation is the same as when the RDB is started to resume during persistence. It is important to note that during synchronization, the database does not block, but that the commands sent by the client can continue to be processed. By default, commands are responded to using data from the database before synchronization. You can configure the Slave-serve-stale-data parameter to No to restore the error to all commands (except info and slaveof) from the database before synchronization is complete: "Sync with Master in progress."
Any data changes from the master database will then be synchronized to the same content as the Redis communication protocol, for example, we execute set foo hi in the main database, and through Telnet we receive:

*3$3set$3foo$2hi

During replication, snapshots play a significant role both in the primary database and in the database, as long as replication takes place, even if we turn off the RDB persistence (by removing all the save parameters). Further, regardless of whether or not the RDB-mode persistence is enabled, Redis attempts to recover the database at startup by attempting to read the Rdb file specified by dir and dbfilename two parameters.

3. Diagram structure

From the database can not only receive the synchronization of the main database, you can also exist as the primary database, the structure of similar graphs, database A's data will be synchronized to B and C, and B data will be synchronized to D and E. Writing data to B is not synchronized to a or C, only to D and E,

4. Read and write separation

Replication enables read-write separation to increase the load capacity of the server. In a common scenario, the frequency of reading is greater than the write, when a single-machine redis cannot cope with a large number of Read requests (especially the more resource-intensive requests, such as the sort command, etc.) can be established through the replication function from the database, the primary database only write operations, and from the database is responsible for read operations.

5. Persisting from a database

Another relatively time-consuming operation is persistence, in order to improve performance, you can create one (or several) from the database through the replication function, and enable persistence from the database while disabling persistence in the primary database. Restarting the base database when it crashes from the database automatically synchronizes 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 promote the service from the database to the primary database, and then use the slaveof command to set it to the new primary database from the database after the original primary database is started, and then synchronize the data back.

Redis Research (12)-Data replication