redis entry to the proficiency (VIII): redis high availability - Detailed master-slave replication

(A) from the master copy Introduction

Stated before operating on redis belong to the stand-alone operation, stand-alone operation, although simple, but limited processing power, not availability. The so-called high-availability, is that when a server goes down, when there is spare can replace the server, in stand-alone operation which can not be achieved, so there have been a master-slave replication.

We put a server is seen as the primary server (master), in addition to multiple servers from a server is seen as a (slave), the Lord is the real-efficient replication to copy data from the master to the slave in the middle.

 

Wherein the master copy from:

You can have a plurality of slave master, a slave to a master corresponding to only

master responsible for performing data write data, change will occur automatically synchronized to the slave

slave is responsible for reading data , writing data ban

With the master-slave After copying, a high availability can be achieved, when a slave station is down, there are a plurality of slave exist; when the master is down, since the master and slave data is the same, one can elect slave as the new master, can achieve high availability.

The main role of the copy:

Separate read and write: master write, slave read

Load balancing: a master load balancing slave, and the number may be varied according to the specific needs of slave

Recovery: When the master problems, may be replaced by a master slave, fast recovery

Data redundancy: With more than one slave, data backup becomes easier

(B) the master-slave replication workflow

Master-slave replication workflow can be divided into three stages:

1. Establish a connection phase

2. Data synchronization phase

3. Command dissemination phase (repeatedly sync)

 

2.1 to establish a connection stage

1. Set the master address and port number

2. establish socket connections

3. Send the ping command (Task Timer)

4. Authentication

 

In order to achieve the above process, and I were at the two ports open redis service, 6379 represents the master, 6380 on behalf of slave

Redis two copies of the configuration file, rename redis6379.conf and redis6380.conf, respectively, modify the configuration file for the port 6379 and 6380. Open the two services in cmd:

 Then open two clients are connected to two redis service, 6379 is the master, 6380 is a slave

redis-cli -p 6379
redis-cli -p 6380

Master-slave connection

slaveof <masterip> <masterport>

 

At this time, the master has been completed from the connection, my name is provided on a master, the slave may be obtained directly from

Main, also connected from outside in addition to the connection command in the configuration file configuration, which an increase in the redis6380.conf

slaveof 127.0.0.1 6379

When done automatically restart from the master connection

Disconnect main connection

slaveof no one

2.2 Data synchronization phase

1. synchronous request data

2. Create a data synchronization RDB

3. recovery RDB data synchronization

4. The request data synchronization portion

The recovery synchronization data portion

Such steps may look somewhat abstract 5, with one graph:

Synchronous data replication is divided into two partial duplication total and wherein the total amount of copying is performed after you start synchronizing instruction RDB operation, the data is sent to the master by the slave RDB. Since the RDB use bgsave instruction , so the total amount during the copy operation will be made into the master a buffer, when the total amount after the end of the recovery operation needs to be copied by the partial buffer copy, used here AOF.

Note that part of the data synchronization issues:

Through the above description we know the full amount during the operation when the copy will be placed in the buffer zone, but if the cache is set too small will lead to master blocking, you can set the size of the buffer by the following ways :

repl-backlog-size 1mb

可以通过配置以下参数暂时关闭slave对外服务

slave-server-stable-data yes|no

2.3 命令传播阶段

命令传播阶段就是当master数据库状态发生变化，就会通过命令传播阶段同步给slave

命令传播阶段有三个核心要素：

服务器的运行id、主服务器的复制积压缓冲区、主从服务器的复制偏移量

服务器运行id：

服务器运行id是每台服务器每次运行的身份识别码，由40个字符组成，用于在服务器之间传输时识别身份。

主服务器的复制积压缓冲区：

复制积压缓冲区又称为复制缓冲区，是一个先进先出的队列。当master数据库发生变化时，master会将要传播给slave的命令保存在复制缓冲区中，slave分别从复制缓冲区接收信息。

主从服务器的复制偏移量：

因为命令传播阶段首先由master把数据放入缓冲区中，因此master需要一个复制偏移量记录发送给slave的指令对应的位置。而slave要把缓冲区中的数据同步到自己这里，因此也需要一个复制偏移量记录接收到的位置，如果因为意外断网，等网络再次连接之后就可以直接从复制偏移量的位置继续复制。

2.4 心跳机制

进入命令传播阶段后，master和slave需要通过心跳机制保持双方连接

master心跳：

通过ping指令查询slave是否在线，可由repl-ping-slave-period设置周期，默认10秒

slave心跳：

指令：

replconf ack {offset}

周期1秒；

作用：汇报slave自己的复制偏移量；判断master是否在线

当slave多数都掉线或者slave延迟过高时，可以强制关闭master的写功能，停止数据同步：

min-slaves-to-write 2    当连接的slave小于等于2台时停止数据同步
min-slaves-max-lag 10    当连接的slave延迟大于10秒，停止数据同步