Design and implementation of high-performance NoSQL Ledisdb (2): Replication

LEDISDB has now supported the replication mechanism, which guarantees the high availability of ledisdb.

Use

Assume that the master has an IP of 10.20.187.100, the IP for Port 6380,slave is 10.20.187.101, and the port is 6380.

First we need master to open Binlog support, which is specified in the configuration file:

use_bin_log : true

On the slave machine we can specify slaveof to turn on the replication through the configuration file, or turn it on or off via the command slaveof display.

slaveof 10.20.187.100 6380

LEDISDB's replication mechanism refers to the implementation of Redis and MySQL, which is explained briefly below.

Redis replication

The replication mechanism of Redis is mainly described here, which has been explained in detail.

• Slave send sync command to Master
• Master dumps its current data to a file and caches new modification commands in memory
• When the data dump is complete, Master sends it to slave
• After slave accepts the dump data, it empties its native previous data and then imports the dump data
• Master then sends the previously cached command to Slave

After redis2.8, in order to prevent the disconnection caused by the regeneration Dump,redis added Psync command, when the disconnection of the master will remember the current synchronization state, so that the next time the breakpoint can be continued to pass.

MySQL Replication

MySQL's replication is mainly done by Binlog synchronization. Any data updates in master will be written to Binlog, as the Binlog format is no longer described here.

Assuming that Binlog's basename is the Mysql,index file with the name Mysql-bin.index, the file records all current Binlog files.

Binlog has the configuration of max file size, and when Binlog writes a file size that exceeds this value, MySQL generates a new Binlog file. When the MySQL service restarts, a new Binlog file is also generated.

In the MySQL version of Percona, Binlog also has a max file num setting, and when the number of Binlog files exceeds this value, MySQL deletes the oldest binlog.

Slave has a master.info file to record the current synchronization master Binlog information, mainly the current synchronization of the Binlog file name and data offset location, so that the next time the resynchronization can continue from this location.

Slave synchronized data is written to relay log, while another thread in the background logs relay log data to MySQL.

Because the master Binlog may be deleted, slave synchronization may occur when the Binlog lost situation, MySQL through the dump+binlog way to solve, in fact, slave completely dump master data, The current Binlog information is also logged in the generated dump to facilitate the next synchronization.

LEDISDB replication

LEDISDB's replication mechanism references Redis as well as MySQL, support for fullsync and incremental sync.

Master does not use the AOF mechanism, but instead uses binlog, which controls the overall size of the Binlog by specifying the max file size and max file num, so that I don't have to worry about the process of aof files continually growing and needing to be re-rewrite.

Binlog file name format is as follows:

ledis-bin.0000001ledis-bin.0000002

The suffix of the Binlog file name is incremented by the number, followed by the index to indicate it.

Slave side also has a master.info file, because Ledisdb will strictly guarantee the increment of binlog file suffix, so we only need to record the current synchronization of the Binlog file suffix index.

The entire replication process is as follows:

• Slave sends Fullsync for full synchronization when the Binlog information for the first synchronization or recording is inconsistent due to the binlog deletion of the master side.
• When Master receives the Fullsync information, it dumps the current data and binlog information to the file and sends it to slave.
• Slave accepts the entire dump file, clears all the data, imports the dump data into the LEVELDB, and saves the Binlog information for the current dump.

• Slave incremental synchronization via the Sync command, the Sync command format is as follows:

    sync binlog-index binlog-pos

  Master navigates to the specified Binlog file by index and seek to the POS location, sending the Binlog data that follows it to slave.

• Slave receive Binlog data, import leveldb, if sync does not receive any new data, sync again after 1s.

For the last point, the most important question is how the master new Binlog to synchronize slave. For this it is nothing more than two models, push and pull.

For push, any new data can be very timely notification slave to obtain, and pull model for performance considerations, it is not too frequent to polling, slightly delayed.

MySQL uses the push + pull mode, when the Binlog update, just notify the slave to have the update, slave is pulling the actual data through pulls. But in order to support push,master must maintain some state information of slave, which adds a little bit more complexity.

The LEDISDB uses a very simple way of timing pull, using 1s intervals, so that the performance overhead increases as polling is too frequent, while minimizing the risk of data loss at the time of the machine.

Summarize

LEDISDB's replication mechanism has just been completed, and a lot more needs to be perfected, but enough to make it a highly available nosql choice.

Ledisdb's web site is here Https://github.com/siddontang/ledisdb, hoping for the participation of children's shoes of interest.