Redis主从复制进阶常见问题解决

  • 1.复制数据延迟
  • 2.异步复制导致数据丢失
  • 3.规避全量复制
  • 4.单机器的复制风暴


  • 在还没讲哨兵之前，我自己先列举了几个比较容易遇到的问题，并且可以手动人为的去控制。

1.复制数据延迟

主从复制延迟多少都会有的，只能减轻

可以通过 info replication 的 offset 指标进行排查监控偏移量 offset 。对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点

同时从节点的 slave-serve-stale-data 参数也与此有关，它控制这种情况下从节点的表现 当从库同主机失去连接或者复制正在进行，从机库有两种运行方式：

1.如果slave-serve-stale-data设置为yes(默认设置)，从库会继续响应客户端的请求。
2.如果slave-serve-stale-data设置为no，除去INFO和SLAVOF命令之外的任何请求都会返回一个错误”SYNC with master in progress”。

2.异步复制导致数据丢失

因为master->slave的复制是异步，所以可能有部分还没来得及复制到slave就宕机了，此时这些部分数据就丢失了。 怎么解决?(请记住只能降低到可控范围,没办法做到100%不丢失)

解决办法：

1.最少有多少台从机器才能写入

min-slaves-to-write 1

2.从节点最大延迟时间,延迟小于min-slaves-max-lag秒的slave才认为是健康的

slave min-slaves-max-lag 10

3.规避全量复制

造成全量复制的原因:(但是第一次肯定是要全量复制的)

  1. 是主从机的运行 runid 不匹配。解释一下，主节点如果重启， runid 将会发生变化。如果从节点监控到 runid 不是同一个，它就会认为你的节点不安全。 当发生故障转移的时候，如果主节点发生故障，那么从机就会变成主节点。我们会在后面讲解哨兵和集群。
  2. 复制缓冲区空间不足，比如默认值1M，可以部分复制。但如果缓存区不够大的话，首先需要网络中断，部分复制就无法满足。其次需要增大复制缓冲区配置（relbacklogsize），对网络的缓冲增强。参考之前的说明。

解决办法：

为了解决这个问题，Redis提供了debug reload的重启方式：重启后，主节点的runid和offset都不受影响，避免了全量复制。

4.单机器的复制风暴

当一个主机下面挂了很多个 slave 从机的时候，主机 master 挂了，这时 master 主机重启后，因为 runid 发生了变化，所有的 slave 从机都要做一次全 量复制。这将引起单节点和单机器的复制风暴，开销会非常大。

解决办法：

1.可以采用树状结构降低多个从节点对主节点的消耗 从节点采用树状树非常有用，网络开销交给位于中间层的从节点，而不必消耗顶层的主节点。但是这种树状结构也带来了运维的复杂性，增加了手动和自动 处理故障转移的难度,如下图

redis多实例主从 redis主从问题_redis多实例主从