Redis master-slave replication and Sentinel

Each instance Redis server can be configured with multiple slave nodes, slave server can also have a secondary slave node can be organized into complex tree structure (although the production environment very few people do).

Configure the master-slave replication

To try to configure the master-slave replication, we need at least two redis server instances. The easiest way is to download the official website redis redis-server binary executable files, respectively, on the master and slave directories.

Creating redis.conf configuration files are in each directory. Examples of master to the default configuration file, in a master-slave configuration slave replicate example:

# 和主服务器 6379 区分
port 6380

# 主服务器 ip 端口
slaveof 127.0.0.1 6379

# 如果主服务器配置了密码请写在这个配置项中
# masterauth <master-password>

##
## 接下来的选项保留默认配置即可，这里仅做介绍
##

# 当与 master 断开连接或正在进行同步时
# yes: 仍然正常响应客户端请求，但可能返回过时数据
# no: 除 INFO 和 SLAVEOF 命令正常外，其它命令均返回 SYNC with master in progress 错误
slave-serve-stale-data yes

# 从服务器只读
slave-read-only yes

Use the redis-server redis.confcommand to start the instance redis-server, respectively. Use redis-cli -p 6380the command from the server:

127.0.0.1:6380> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:16
master_sync_in_progress:0
slave_repl_offset:3640
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:0b4e100aa9e9fda54aeba2bc110316d811ac2ff6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:3640
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:3640
127.0.0.1:6380> get a
1
127.0.0.1:6380> set a 2
(error) READONLY You can't write against a read only slave.

SLAVEOF host portYou can dynamically change the master node from the server belongs. SLAVEOF NO ONEClose copy function, and the transition from the slave back to the master server the server, the original data sets obtained synchronization can not be discarded. When the primary server fails, use the SLAVEOF NO ONEcommand to lift a slave server is master.

Copy the master-slave principle

SYNC

In versions prior to 2.8 Redis years, Redis supports only full volume incremental replication does not support replication, which greatly affects the performance of the master-slave synchronization.

Versions prior to 2.8 Redis master-slave replication process is as follows:

1. slave SYNC command is sent to the master
2. master command execution bgsave generate rdb file. At the same time, all new write command will be written into the copy buffer
3. master file will be sent to the slave rdb
4. The master synchronization buffer command to slave, a master-slave synchronization is completed

PSYNC

Redis 2.8 PSYNC command instead to start using the SYNC command, PSYNC total and incremental replication replication.

master and slave nodes all have a runid as their unique identification.

master and slave will each maintain a copy offset, identifies synchronization progress at the time of incremental replication.

master maintains a copy of a FIFO buffer (replication backlog), the default size of 1mb.

# 复制缓冲区大小
repl-backlog-size 1mb

# 当 master 不再与任何 slave 保持连接时，复制缓冲区可能被清空
# repl-backlog-ttl 用于配置从断开连接到清空缓冲区间隔的秒数
# 0 表示永不清除缓冲区
repl-backlog-ttl 3600

Then we can begin to explain the process of PSYNC command:

1. slave synchronization request to the master
   1. If the slave is not synchronized with any master or through SLAVEOF NO ONE command is executed, the master sends a PSYNC ? -1command to synchronize the total amount requested.
   2. Otherwise, the master sends a psync <runid> <offset>command incremental synchronization requirements, where ID is the last runid master synchronization, offset is the synchronization offset
2. master synchronization request response
   1. If the slave incremental synchronization request and satisfies:.. 1 runid itself same; 2 synchronization offset copies of itself in the buffer, in response +continueto copy the data in the buffer to the slave synchronization
   2. If the slave incremental synchronization request but does not meet the above two conditions, or the total amount slave synchronization request, the response at the same time +fullresync <runid> <offset>to perform a full synchronization amount, wherein runid are self ID, offset itself is the synchronization offset.
3. If their version is too low does not support the PSYNCcommand in response error, slave tries to use the SYNC command to synchronize.

sentinel

Simple master-slave replication architecture after master failure will be unavailable, Redis official Sentinels (sentinel) standby switching mechanism automatically guarantee high availability.

Sentinel through a set of mechanisms to monitor sentinel node master-slave operation state of the node, and the election of a new primary node after the primary node fails.

Sentinel node periodically performs three tasks:

• Sentinel node 10s intervals from the master node sends a INFOcommand to update the topology, the new slave node automatically senses.

• Every 1s sentinel node to the master node transmits from the PINGheartbeat detection command.

• Sentinel node to every 2s __sentinel__:hellotransmits its own understanding of Sentinel node information and the master information channel. All sentinel node will subscribe to the channel, and this update Sentinel cluster information.

If the sentinel node discovery master node heartbeat response timeout, then that master subjective offline. At this point, master may really have collapsed it may only be a network failure occurs between this sentinel node and master.

He considers that the master subjective offline Sentinel will be sent to the other sentry sentinel is-master-down-by addrasked whether the master offline. If more than half of the Sentinel considers that the master has been off the assembly line is considered master objective offline.

Sentinel node will elect their first received is-master-down-by command of the sender for the sentry leader. If one node to get more than half the voting will be the sentry leader, if not the node receive more than half of votes will enter the next round of voting. This selection process is similar to the Paxos algorithm.

Sentinel leader is responsible for selecting a slave master node to a new node, select logic is:

1. Slave nodes filter out unhealthy
2. Select slave-priorityconfiguration values from the smallest node. If a plurality of slave-priority nodes from the smallest and the same goes to the next step
3. Select Copy from the node maximum offset, which means that the data from the node above the most complete. If a plurality of slave nodes are still the same as the offset to the next step
4. Selecting a minimum from the node runid

After the election of the new master node performs the upgrade process:

1. Issued SLAVEOF NO ONE command to the master node newly elected, to be the new master node
2. SLAVEOF issue commands to other slave nodes follow the new master node
3. In the sentinel node cluster offline to update the master to slave nodes offline, the command that follows the new master after its return