|运维必备:Zookeeper集群“脑裂”问题处理大全( 四 )


Zookeeper除了可以采用上面默认的Quorums方式来避免出现''脑裂'' , 还可以可采用下面的预防措施:
2)添加冗余的心跳线 , 例如双线条线 , 尽量减少“裂脑”发生机会
3)启用磁盘锁
正在服务一方锁住共享磁盘 , ''裂脑''发生时 , 让对方完全''抢不走''共享磁盘资源 。 但使用锁磁盘也会有一个不小的问题 , 如果占用共享盘的一方不主动''解锁'' , 另一方就永远得不到共享磁盘 。
现实中假如服务节点突然死机或崩溃 , 就不可能执行解锁命令 。 后备节点也就接管不了共享资源和应用服务 。 于是有人在HA中设计了''智能''锁 。 即正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁 。 平时就不上锁了 。
4)设置仲裁机制
例如设置参考IP(如网关IP) , 当心跳线完全断开时 , 2个节点都各自ping一下 参考IP , 不通则表明断点就出在本端 , 不仅''心跳''、还兼对外''服务''的本端网络链路断了 , 即使启动(或继续)应用服务也没有用了 , 那就主动放弃竞争 , 让能够ping通参考IP的一端去起服务 。
更保险一些 , ping不通参考IP的一方干脆就自我重启 , 以彻底释放有可能还占用着的那些共享资源 。
作者丨散尽浮华
来源丨https://www.cnblogs.com/kevingrace/p/12433503.html
dbaplus社群欢迎广大技术人员投稿 , 投稿邮箱:editor@dbaplus.cn
2020 DAMS中国数据智能管理峰会即将于10月30日在上海举办 , 部分精彩议题先睹为快:

  • 腾讯《腾讯游戏大数据资产管理实战:元数据管理与数据治理》
  • 京东《京东EB级全域大数据平台建设和治理之路》
  • 阿里《大规模容器云基础设施环境架构、管理与运维》
  • 工商银行《DevOps转型的探索与实践》
  • 中国银联《从自研演进看分布式数据库》
  • 民生银行《开源数据库MySQL在民生银行的应用实践》
  • 平安银行《“传统+互联网”混合CMDB及运营中台实践》
  • 中国联通《大数据资产管理平台的设计、研发、运营实践》
  • AWS《基于数据湖构建云上的数据分析架构》
  • ****《字节跳动数据治理实践》
  • 苏宁《苏宁大规模智能告警收敛与告警根因的实践》
  • 滴滴《万亿级消息队列Kafka在滴滴的实践》

|运维必备:Zookeeper集群“脑裂”问题处理大全
本文插图
【|运维必备:Zookeeper集群“脑裂”问题处理大全】


推荐阅读