redis 主从复制和数据丢失

redis 主从复制和数据丢失

从节点启动时复制的完整流程

1. slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始，master host和ip是从哪儿来的，redis.conf里面的slaveof配置的
2. slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接
3. slave node发送ping命令给master node
4. 口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
5. master node第一次执行全量复制，将所有数据发给slave node
6. master node后续持续将写命令，异步复制给slave node

数据同步相关的核心机制

第一次slave连接msater的时候，执行的全量复制：

offset

• master和slave都会维护一个offset，master会在自身不断累加offset，slave也会在自身不断累加offset，slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset
• 这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况

backlog

• Backlog是一个固定大小的环形缓冲区，用于存储主服务器接收到的写命令，默认是1MB大小
• 当从服务器与主服务器断开连接时，从服务器会尝试重新连接。在重新连接过程中，从服务器会向主服务器请求丢失的写命令。backlog用于存储这些写命令，确保从服务器可以恢复数据一致性，避免全量同步的开销‌，offset就是保存在backlog中的

master run id

info server，可以看到master run id
如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化（master节点重新加载旧的RDB文件），那么slave node应该根据不同的run id区分，run id不同就做全量复制，如果需要不更改run id重启redis，可以使用redis-cli debug reload命令

psync

从节点使用psync从master node进行复制，psync runid offset， master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复制

全量复制过程

1. master执行bgsave，在本地生成一份rdb快照文件
2. master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数，对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
3. master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node， client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
4. slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
5. 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF

其中，rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间

增量复制过程

1. 如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
2. master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
3. msater就是根据slave发送的psync中的offset来从backlog中获取数据的

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

repl-diskless-sync

该参数默认值为no，也即从节点请求全量复制的时候，主节点上不开启无盘复制，先通过bgsave做持久化，然后传输RDB文件到从节点。

全量同步的可以通过两种方式进行：

基于磁盘的复制： Redis主节点会创建一个新的进程，在磁盘上写入RDB文件。之后，父进程会逐步将文件传输给副本。
无磁盘复制： Redis主节点创建的新进程会直接将RDB文件写入副本的套接字，完全不涉及磁盘操作。

在使用基于磁盘的复制时，当RDB文件正在生成时，其他的副本可以排队，并能在当前子进程完成RDB文件生成后立刻使用这个文件。

repl-diskless-sync-delay

默认值为5，单位为秒，该参数只有开启了repl-diskless-sync 为yes的时候才会生效

• 在使用无磁盘复制时，一旦传输开始，新到达的副本会被排队，直到当前传输结束，新的传输才会开始。
• 当使用无磁盘复制时，主节点会等待一个时间段repl-diskless-sync-delay（以秒为单位）再开始传输，这样做的目的是希望多个副本能够在这段时间内到达，从而使传输过程可以并行化。

过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

两种数据丢失的情况

异步复制导致的数据丢失

因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了

脑裂导致的数据丢失

脑裂，也就是说，某个master所在机器突然脱离了正常的网络（出现网络分区），跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂。

此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

数据丢失问题减少

减少异步复制的数据丢失

min-slaves-max-lag 10 表示一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内。

减少脑裂的数据丢失

min-slaves-max-lag 10 和 min-slaves-to-write 1 表示要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失，上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求。因此在脑裂场景下，最多就丢失10秒的数据。