Redis数据丢失问题
主备切换的过程中( 异步复制,脑裂 ),可能会导致数据丢失
因为 master -> slave的复制是异步 的(客户端发送给redis,主节点数据同步到内存中后就返回成功了)
所以可能有部分数据还没复制到slave,master就宕机了,此时master内存中的数据也没了,这些部分数据就丢失了。
脑裂,也就是说,某个master所在机器突然脱离了正常的网络,跟其他slave机器不能连接,但是实际上master还运行着(这种分布式中间件脑裂是常规操作,类似的,比如 rabiitmq脑裂 )
此时哨兵可能就会认为master宕机了,然后开启选举,将其他slave切换成了master
这个时候,集群里就会有两个master,也就是所谓的脑裂
此时虽然某个slave被切换成了master,但是可能client还没来得及切换到新的master,还继续写向旧master的数据,然后旧master再次恢复的时候,会被作为一个slave挂到新的master上去,自己的数据会清空,重新从新的master复制数据,就导致了我们之前在脑裂时候向旧master写的数据全部都丢失了。
解决以上两种情况redis数据丢失的问题 都是靠 以下两个参数配置将数据损失降到最低。
min-slaves-to-write x
min-slaves-max-lag y
(要求y秒内至少有x个slave同步接收到这个数据,比如x=1,y=10)
有了min-slaves-max-lag这个配置,就可以确保说,一旦slave复制数据和ack延时太长,就 认为 可能master宕机后 损失 的数据 太多 了,那么就 拒绝 新的 写 请求,这样可以把master 宕机时 由于部分数据未同步到slave导致的数据丢失的损失 降低的可控范围内 ,但是 仅有一个从库要谨慎设置1,只有一个从库且要去维护的时候,请先设置 最少写从库的个数为0,再去维护从库
如果一个master出现了脑裂,跟其他slave丢了连接,那么上面两个配置可以确保说,如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己ack消息,那么就直接拒绝客户端的写请求
这样脑裂后的 旧master就不会接受client的新数据 ,也就避免了更多的数据丢失
上面的配置就确保了,如果跟任何一个slave(配置的x为所有从结点的数量)丢了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的写请求
2024-08-23 广告