欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

Redis-复制

程序员文章站 2022-06-29 23:12:49
复制 A few things to understand ASAP about Redis replication. 复制的实现 1. 设置主节点的地址和端口 简而言之,是执行SLAVEOF命令,该命令是个异步命令,在设置完masterhost和masterport属性之后,从节点将向发送SLAV ......

复制

a few things to understand asap about redis replication.

1) redis replication is asynchronous, but you can configure a master to
   stop accepting writes if it appears to be not connected with at least
   a given number of slaves.
2) redis slaves are able to perform a partial resynchronization with the
   master if the replication link is lost for a relatively small amount of
   time. you may want to configure the replication backlog size (see the next
   sections of this file) with a sensible value depending on your needs.
3) replication is automatic and does not need user intervention. after a
   network partition slaves automatically try to reconnect to masters
   and resynchronize with them.

 

复制的实现

1. 设置主节点的地址和端口

简而言之,是执行slaveof命令,该命令是个异步命令,在设置完masterhost和masterport属性之后,从节点将向发送slaveof的客户端返回ok。表示复制指令已经被接受,而实际的复制工作将在ok返回之后才真正开始执行。

 

2. 创建套接字连接。

在执行完slaveof命令后,从节点根据命令所设置的ip和端口,创建连向主节点的套接字连接。如果创建成功,则从节点将为这个套接字关联一个专门用于处理复制工作的文件事件处理器,这个处理器将负责执行后续的复制工作,比如接受rdb文件,以及接受主节点传播来的写命令等。

 

3. 发送ping命令。

从节点成为主节点的客户端之后,首先会向主节点发送一个ping命令,其作用如下:

1. 检查套接字的读写状态是否正常。

2. 检查主节点是否能正常处理命令请求。

如果从节点读取到“pong”的回复,则表示主从节点之间的网路连接状态正常,并且主节点可以正常处理从节点发送的命令请求。

 

4. 身份验证

从节点在收到主节点返回的“pong”回复之后,接下来会做的就是身份验证。如果从节点设置了masterauth选项,则进行身份验证。反之则不进行。

在需要进行身份验证的情况下,从节点将向主节点发送一条auth命令,命令的参数即可从节点masterauth选项的值。

 

5. 发送端口信息。

在身份验证之后,从节点将执行replconf listening-port  <port-number>,向主节点发送从节点的监听端口号。

主节点会将其记录在对应的客户端状态的slave_listening_port属性中,这点可通过info replication查看。

127.0.0.1:6379> info replication
# replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=3696,lag=0

 

6. 同步。

从节点向主节点发送psync命令,执行同步操作,并将自己的数据库更新至主节点数据库当前所处的状态。

 

7. 命令传播

当完成了同步之后,主从节点就会进入命令传播阶段。这时主节点只要一直将自己执行的写命令发送到从节点,而从节点只要一直接收并执行主节点发来的写命令,就可以保证主从节点保持一致了。

 

8. 心跳检测

在命令传播阶段,从节点默认会以每秒一次的频率,向主节点发送命令。

replconf ack <replication_offset>

其中,replication_offset是从节点当前的复制偏移量。

发送replconf ack主从节点有三个作用:

1> 检测主从节点的网络连接状态。

2> 辅助实现min-slave选项。

3> 检查是否存在命令丢失。

replconf ack命令和复制积压缓冲区是redis 2.8版本新增的,在此之前,即使命令在传播过程中丢失,主从节点都不会注意到。

 

复制的相关参数

slaveof <masterip> <masterport>
masterauth <master-password>

slave-serve-stale-data yes

slave-read-only yes

repl-diskless-sync no

repl-diskless-sync-delay 5

repl-ping-slave-period 10

repl-timeout 60

repl-disable-tcp-nodelay no

repl-backlog-size 1mb

repl-backlog-ttl 3600

slave-priority 100

min-slaves-to-write 3
min-slaves-max-lag 10

slave-announce-ip 5.5.5.5
slave-announce-port 1234

其中,

slaveof <masterip> <masterport>:开启复制,只需这条命令即可。

masterauth <master-password>:如果master中通过requirepass参数设置了密码,则slave中需设置该参数。

slave-serve-stale-data:当主从连接中断,或主从复制建立期间,是否允许slave对外提供服务。默认为yes,即允许对外提供服务,但有可能会读到脏的数据。

slave-read-only:将slave设置为只读模式。需要注意的是,只读模式针对的只是客户端的写操作,对于管理命令无效。

repl-diskless-sync,repl-diskless-sync-delay:是否使用无盘复制。为了降低主节点磁盘开销,redis支持无盘复制,生成的rdb文件不保存到磁盘而是直接通过网络发送给从节点。无盘复制适用于主节点所在机器磁盘性能较差但网络宽带较充裕的场景。需要注意的是,无盘复制目前依然处于实验阶段。

repl-ping-slave-period:master每隔一段固定的时间向slave发送一个ping命令。

repl-timeout:复制超时时间。

# the following option sets the replication timeout for:
#
# 1) bulk transfer i/o during sync, from the point of view of slave.
# 2) master timeout from the point of view of slaves (data, pings).
# 3) slave timeout from the point of view of masters (replconf ack pings).
#
# it is important to make sure that this value is greater than the value
# specified for repl-ping-slave-period otherwise a timeout will be detected
# every time there is low traffic between the master and the slave.

 

repl-disable-tcp-nodelay:设置为yes,主节点会等待一段时间才发送tcp数据包,具体等待时间取决于linux内核,一般是40毫秒。适用于主从网络环境复杂或带宽紧张的场景。默认为no。

 

repl-backlog-size:复制积压缓冲区,复制积压缓冲区是保存在主节点上的一个固定长度的队列。用于从redis 2.8开始引入的部分复制。

# set the replication backlog size. the backlog is a buffer that accumulates
# slave data when slaves are disconnected for some time, so that when a slave
# wants to reconnect again, often a full resync is not needed, but a partial
# resync is enough, just passing the portion of data the slave missed while
# disconnected.
#
# the bigger the replication backlog, the longer the time the slave can be
# disconnected and later be able to perform a partial resynchronization.
#
# the backlog is only allocated once there is at least a slave connected.

只有slave连接上来,才会开辟backlog。

 

repl-backlog-ttl:如果master上的slave全都断开了,且在指定的时间内没有连接上,则backlog会被master清除掉。repl-backlog-ttl即用来设置该时长,默认为3600s,如果设置为0,则永不清除。

 

slave-priority:设置slave的优先级,用于redis sentinel主从切换时使用,值越小,则提升为主的优先级越高。需要注意的是,如果设置为0,则代表该slave不参加选主。

 

slave-announce-ip,slave-announce-port :常用于端口转发或nat场景下,对master暴露真实ip和端口信息。

 

同步的过程

1. 从节点向主节点发送psync命令。

2. 收到psync命令的主节点执行bgsave命令,在后台生成一个rdb文件,并使用一个缓冲区记录从现在开始执行的所有写命令。

3. 当主节点的bgsave命令执行完毕时,主节点会将bgsave命令生成的rdb文件发送给从节点,从节点接受并载入这个rdb文件,将自己的数据库状态更新至主节点执行bgsave命令时的数据库状态。

4. 主节点将记录在缓冲区里面的所有写命令发送给从节点,从节点执行这些写命令,将自己的数据库状态更新至主节点数据库当前所处的状态。

 

需要注意的是,在步骤2中提到的缓冲区,其实是有大小限制的,其由client-output-buffer-limit slave 256mb 64mb 60决定,该参数的语法及解释如下:

# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
#
# a client is immediately disconnected once the hard limit is reached, or if
# the soft limit is reached and remains reached for the specified number of
# seconds (continuously).

意思是如果该缓冲区的大小超过256m,或该缓冲区的大小超过64m,且持续了60s,主节点会马上断开从节点的连接。断开连接后,在60s之后(repl-timeout),从节点发现没有从主节点中获得数据,会重新启动复制。

 

在redis 2.8之前,如果因网络原因,主从节点复制中断,当再次建立连接时,还是会执行sync命令进行全量复制。效率较为低下。从redis 2.8开始,引入了psync命令代替sync命令来执行复制时的同步操作。

psync命令具有全量同步(full resynchronization)和增量同步(partial resynchronization)。

全量同步的日志:

master:

19544:m 05 oct 20:44:04.713 * slave 127.0.0.1:6380 asks for synchronization
19544:m 05 oct 20:44:04.713 * partial resynchronization not accepted: replication id mismatch (slave asked for 'dc419fe03ddc9ba30cf2a2cf1894872513f1ef96', my 
replication ids are 'f8a035fdbb7cfe435652b3445c2141f98a65e437' and '0000000000000000000000000000000000000000')19544:m 05 oct 20:44:04.713 * starting bgsave for sync with target: disk
19544:m 05 oct 20:44:04.713 * background saving started by pid 20585
20585:c 05 oct 20:44:04.723 * db saved on disk
20585:c 05 oct 20:44:04.723 * rdb: 0 mb of memory used by copy-on-write
19544:m 05 oct 20:44:04.813 * background saving terminated with success
19544:m 05 oct 20:44:04.814 * synchronization with slave 127.0.0.1:6380 succeeded

slave:

19746:s 05 oct 20:44:04.288 * before turning into a slave, using my master parameters to synthesize a cached master: i may be able to synchronize with the new
 master with just a partial transfer.19746:s 05 oct 20:44:04.288 * slave of 127.0.0.1:6379 enabled (user request from 'id=3 addr=127.0.0.1:37128 fd=8 name= age=929 idle=0 flags=n db=0 sub=0 psub=
0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')19746:s 05 oct 20:44:04.712 * connecting to master 127.0.0.1:6379
19746:s 05 oct 20:44:04.712 * master <-> slave sync started
19746:s 05 oct 20:44:04.712 * non blocking connect for sync fired the event.
19746:s 05 oct 20:44:04.713 * master replied to ping, replication can continue...
19746:s 05 oct 20:44:04.713 * trying a partial resynchronization (request dc419fe03ddc9ba30cf2a2cf1894872513f1ef96:1191).
19746:s 05 oct 20:44:04.713 * full resync from master: f8a035fdbb7cfe435652b3445c2141f98a65e437:1190
19746:s 05 oct 20:44:04.713 * discarding previously cached master state.
19746:s 05 oct 20:44:04.814 * master <-> slave sync: receiving 224566 bytes from master
19746:s 05 oct 20:44:04.814 * master <-> slave sync: flushing old data
19746:s 05 oct 20:44:04.815 * master <-> slave sync: loading db in memory
19746:s 05 oct 20:44:04.817 * master <-> slave sync: finished with success

 

增量同步的日志:

master:

19544:m 05 oct 20:42:06.423 # connection with slave 127.0.0.1:6380 lost.
19544:m 05 oct 20:42:06.753 * slave 127.0.0.1:6380 asks for synchronization
19544:m 05 oct 20:42:06.753 * partial resynchronization request from 127.0.0.1:6380 accepted. sending 0 bytes of backlog starting from offset 1037.

slave:

19746:s 05 oct 20:42:06.423 # connection with master lost.
19746:s 05 oct 20:42:06.423 * caching the disconnected master state.
19746:s 05 oct 20:42:06.752 * connecting to master 127.0.0.1:6379
19746:s 05 oct 20:42:06.752 * master <-> slave sync started
19746:s 05 oct 20:42:06.752 * non blocking connect for sync fired the event.
19746:s 05 oct 20:42:06.753 * master replied to ping, replication can continue...
19746:s 05 oct 20:42:06.753 * trying a partial resynchronization (request f8a035fdbb7cfe435652b3445c2141f98a65e437:1037).
19746:s 05 oct 20:42:06.753 * successful partial resynchronization with master.
19746:s 05 oct 20:42:06.753 * master <-> slave sync: master accepted a partial resynchronization.

 

在redis 4.0中,master_replid和offset存储在rdb文件中。当从节点被优雅的关闭并重新启动时,redis能够从rdb文件中重新加载master_replid和offset,从而使增量同步成为可能。

 

增量同步的实现依赖于以下三部分:

1. 主从节点的复制偏移量。

2. 主节点的复制积压缓冲区。

3. 节点的运行id(run id)。

 

当一个从节点被提升为主节点时,其它的从节点必须与新主节点重新同步。在redis 4.0 之前,因为master_replid发生了变化,所以这个过程是一个全量同步。在redis 4.0之后,新主节点会记录旧主节点的naster_replid和offset,因为能够接受来自其它从节点的增量同步请求,即使请求中的master_replid不同。在底层实现上,当执行slaveof no one时,会将master_replid,master_repl_offset+1复制为master_replid,second_repl_offset。

 

复制相关变量

# replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=5698,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=5698,lag=0
master_replid:e071f49c8d9d6719d88c56fa632435fba83e145d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5698
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5698

# replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:126
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:15715bc0bd37a71cae3d08b9566f001ccbc739de
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:126
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:126

 

其中,

role: value is "master" if the instance is replica of no one, or "slave" if the instance is a replica of some master instance. note that a replica can be master of another replica (chained replication).

master_replid: the replication id of the redis server. 每个redis节点启动后都会动态分配一个40位的十六进制字符串作为运行id。主的运行id。

master_replid2: the secondary replication id, used for psync after a failover. 在执行slaveof no one时,会将master_replid,master_repl_offset+1复制为master_replid,second_repl_offset。

master_repl_offset: the server's current replication offset.  master的复制偏移量。

second_repl_offset: the offset up to which replication ids are accepted.

repl_backlog_active: flag indicating replication backlog is active 是否开启了backlog。

repl_backlog_size: total size in bytes of the replication backlog buffer. repl-backlog-size的大小。

repl_backlog_first_byte_offset: the master offset of the replication backlog buffer. backlog中保存的master最早的偏移量,

repl_backlog_histlen: size in bytes of the data in the replication backlog buffer. backlog中数据的大小。


if the instance is a replica, these additional fields are provided:

master_host: host or ip address of the master. master的ip。

master_port: master listening tcp port. master的端口。

master_link_status: status of the link (up/down). 主从之间的连接状态。

master_last_io_seconds_ago: number of seconds since the last interaction with master.  主节点每隔10s对从从节点发送ping命令,以判断从节点的存活性和连接状态。该变量代表多久之前,主从进行了心跳交互。

master_sync_in_progress: indicate the master is syncing to the replica. 主节点是否在向从节点同步数据。个人觉得,应该指的是全量同步或增量同步。

slave_repl_offset: the replication offset of the replica instance. slave的复制偏移量。

slave_priority: the priority of the instance as a candidate for failover. slave的权重。

slave_read_only: flag indicating if the replica is read-only. slave是否处于可读模式。


if a sync operation is on-going, these additional fields are provided:

master_sync_left_bytes: number of bytes left before syncing is complete. 

master_sync_last_io_seconds_ago: number of seconds since last transfer i/o during a sync operation. 


if the link between master and replica is down, an additional field is provided:

master_link_down_since_seconds: number of seconds since the link is down. 主从连接中断持续的时间。

 

the following field is always provided:

connected_slaves: number of connected replicas. 连接的slave的数量。

 

if the server is configured with the min-slaves-to-write (or starting with redis 5 with the min-replicas-to-write) directive, an additional field is provided:

min_slaves_good_slaves: number of replicas currently considered good。状态正常的从节点的数量。

 

for each replica, the following line is added:
slavexxx: id, ip address, port, state, offset, lag. slave的状态。

slave0:ip=127.0.0.1,port=6381,state=online,offset=1288,lag=1

 

如何监控主从延迟

# replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=560,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=560,lag=0
master_replid:15715bc0bd37a71cae3d08b9566f001ccbc739de
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:560

其中,master_repl_offset是主节点的复制偏移量,slavex中的offset即对应从节点的复制偏移量,两者的差值即主从的延迟量。

 

如何评估backlog缓冲区的大小

t * (master_repl_offset2 - master_repl_offset1 ) / (t2 - t1)

t is how long the disconnections may last in seconds.

 

参考:

1. 《redis开发与运维》

2. 《redis设计与实现》

3. 《redis 4.x cookbook》