游戏网站建设教程,广告免费推广网,网站架设流程,简述网站开发过程1. 前言 脑裂就是指在主从集群中#xff0c;同时有两个主节点#xff0c;它们都能接收写请求。而脑裂最直接的影响#xff0c;就是客户端不知道应该往哪个主节点写入数据#xff0c;结果就是不同的客户端会往不同的主节点上写入数据。而且#xff0c;严重的话#xff0c;…1. 前言 脑裂就是指在主从集群中同时有两个主节点它们都能接收写请求。而脑裂最直接的影响就是客户端不知道应该往哪个主节点写入数据结果就是不同的客户端会往不同的主节点上写入数据。而且严重的话脑裂会进一步导致数据丢失。
2. 为什么会发生脑裂 第一步确认是不是数据同步出现了问题 在主从集群中发生数据丢失最常见的原因就主库的数据还没有同步到从库结果主库发生了故障等从库升级为主库后未同步的数据就丢失了。 如果是这种情况的数据丢失我们可以通过比对主从库上的复制进度差值来进行判断也就是计算 master_repl_offset 和 slave_repl_offset 的差值。如果从库上的slave_repl_offset 小于原主库的 master_repl_offset那么我们就可以认定数据丢失是由数据同步未完成导致的。
第二步排查客户端的操作日志发现脑裂现象 在排查客户端的操作日志时我们发现在主从切换后的一段时间内有一个客户端仍然在和原主库通信并没有和升级的新主库进行交互。这就相当于主从集群中同时有了两个主库。根据这个迹象我们就想到了在分布式主从集群发生故障时会出现的一个问题脑裂。 但是不同客户端给两个主库发送数据写操作按道理来说只会导致新数据会分布在不同的主库上并不会造成数据丢失。那么为什么我们的数据仍然丢失了呢到这里我们的排查思路又一次中断了。 不过在分析问题时我们一直认为“从原理出发是追本溯源的好方法”。脑裂是发生在主从切换的过程中我们猜测肯定是漏掉了主从集群切换过程中的某个环节所以我们把研究的焦点投向了主从切换的执行过程。
第三步发现是原主库假故障导致的脑裂 我们是采用哨兵机制进行主从切换的当主从切换发生时一定是有超过预设数量quorum 配置项的哨兵实例和主库的心跳都超时了才会把主库判断为客观下线然后哨兵开始执行切换操作。哨兵切换完成后客户端会和新主库进行通信发送请求操作。 但是在切换过程中既然客户端仍然和原主库通信这就表明原主库并没有真的发生故障例如主库进程挂掉。我们猜测主库是由于某些原因无法处理请求也没有响应哨兵的心跳才被哨兵错误地判断为客观下线的。结果在被判断下线之后原主库又重新开始处理请求了而此时哨兵还没有完成主从切换客户端仍然可以和原主库通信客户端发送的写操作就会在原主库上写入数据了。
3. 为什么脑裂会导致数据丢失 主从切换后从库一旦升级为新主库哨兵就会让原主库执行 slave of 命令和新主库重新进行全量同步。而在全量同步执行的最后阶段原主库需要清空本地的数据加载新主库发送的 RDB 文件这样一来原主库在主从切换期间保存的新写数据就丢失了。 在主从切换的过程中如果原主库只是“假故障”它会触发哨兵启动主从切换一旦等它从假故障中恢复后又开始处理请求这样一来就会和新主库同时存在形成脑裂。等到哨兵让原主库和新主库做全量同步后原主库在切换期间保存的数据就丢失了。
4. 如何应对脑裂问题 既然问题是出在原主库发生假故障后仍然能接收请求上我们就开始在主从集群机制的配置项中查找是否有限制主库接收请求的设置。Redis 已经提供了两个配置项来限制主库的请求处理分别是 min-slaves-to-write 和 min-slaves-max-lag。
min-slaves-to-write这个配置项设置了主库能进行数据同步的最少从库数量 min-slaves-max-lag这个配置项设置了主从库间进行数据复制时从库给主库发送ACK 消息的最大延迟以秒为单位。 我们可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用分别给它们设置一定的阈值假设为 N 和 T。这两个配置项组合后的要求是主库连接的从库中至少有 N 个从库和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒否则主库就不会再接收客户端的请求了。 等到新主库上线时就只有新主库能接收和处理客户端请求此时新写的数据会被直接写到新主库中。而原主库会被哨兵降为从库即使它的数据被清空了也不会有新数据丢失。 假设我们将 min-slaves-to-write 设置为 1把 min-slaves-max-lag 设置为 12s把哨兵的 down-after-milliseconds 设置为 10s主库因为某些原因卡住了 15s导致哨兵判断主库客观下线开始进行主从切换。同时因为原主库卡住了 15s没有一个从库能和原主库在 12s 内进行数据复制原主库也无法接收客户端请求了。这样一来主从切换完成后也只有新主库能接收请求不会发生脑裂也就不会发生数据丢失的问题了。
小结 这节课我们学习了主从切换时可能遇到的脑裂问题。脑裂是指在主从集群中同时有两个主库都能接收写请求。在 Redis 的主从切换过程中如果发生了脑裂客户端数据就会写入到原主库如果原主库被降为从库这些新写入的数据就丢失了。 为了应对脑裂你可以在主从集群部署时 通过合理地配置参数 min-slaves-to-write 和min-slaves-max-lag来预防脑裂的发生。 在实际应用中可能会因为网络暂时拥塞导致从库暂时和主库的 ACK 消息超时。在这种情况下并不是主库假故障我们也不用禁止主库接收请求。 所以我给你的建议是假设从库有 K 个可以将 min-slaves-to-write 设置为K/21如果 K 等于 1就设为 1将 min-slaves-max-lag 设置为十几秒例如 1020s在这个配置下如果有一半以上的从库和主库进行的 ACK 消息延迟超过十几秒我们就禁止主库接收客户端写请求。 ----------------------------------- mysql脑裂失效恢复 mysql集群脑裂 https://blog.51cto.com/u_13229/10027588
