本篇内容主要讲解“Zookeeper bug的排查方法”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Zookeeper bug的排查方法”吧!
某一天突然有同事说zk client连不上server,考虑到最近业务代码没有变更,怀疑是运维同学做了什么操作导致,急忙联系运维同学,确实最近做了变更。为了避免扩大影响范围,先让运维同学回滚了变更,回滚后可以正常访问了。
询问运维同学后,得到变更流程:由于zk集群有一台服务器存在性能隐患,需要变更到新的一个实例。于是运维先将新机器加入zk集群,修改旧服务器上配置逐个重启,重启后新zk的角色是leader,此时zk状态正常,运维同学也就认为变更完成。
结果意想不到的是使用mntr命令查看,所有的机器状态都是正常,但是zk client无法访问,一访问就卡住,问题可以在测试环境稳定复现。
1 猜测zk端口没有监听成功,登录服务器使用netstat查看server打开的三个端口都是正常状态,也使用了telnet测试可以连上。
2 猜测同步节点数不足一半,或者follower连不上leader触发重新选举,但很快就被排除,因为上面说了使用mntr命令查看节点状态都正常,从日志中也未能找到对应日志记录。
3 我们再使用stat来观察server的连接情况,运行zk client发现server收到了client的请求,但是没有回消息,看来原因就是zk server没处理client的请求了。
跟踪到这里,就应该进入源码了,由于对zk源码不熟悉,咨询了某位大佬,建议我们看zk请求处理类CommitProcessor。
在CommitProcessor我们发现了原因,代码如下:
<code>@Override public void start() { ... if (workerPool == null) { workerPool = new WorkerService("CommitProcWork", numWorkerThreads, true); } ... } public void shutdown() { LOG.info("Shutting down"); halt(); if (workerPool != null) { workerPool.join(workerShutdownTimeoutMS); } if (nextProcessor != null) { nextProcessor.shutdown(); } } </code><button>复制</button>
在shutdown中调用了 workerPool.join实际上已经将请求处理的开关关闭了,但是并没有将workerPool设置为null。在start方法中会根据workerPool==null来创建WorkerService并开始处理请求。
修改后重新验证解决。
到此,相信大家对“Zookeeper bug的排查方法”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。