磁盘爆满导致zookeeper卡住
场景复现：线上服务器磁盘满了导致部署在上面的namenode zookeeper Kafka 均无法工作 抛出异常，清理kafka备份文件后系统磁盘还原了100G+，但是此时的zookeeper节点已经无法再加入集群。3台 zookeeper节点 出问题的节点在当时是作为leader工作的。错误日志抛出异常后节点挂掉。再次启动之后 该节点已经无法加入已经存在的集群中。经过查找相关资料https:/
·
场景复现：
线上服务器磁盘满了导致部署在上面的namenode zookeeper Kafka 均无法工作 抛出异常，清理kafka备份文件后系统磁盘还原了100G+，但是此时的zookeeper节点已经无法再加入集群。
3台 zookeeper节点 出问题的节点在当时是作为leader工作的。
错误日志
抛出异常后节点挂掉。
再次启动之后 该节点已经无法加入已经存在的集群中。
经过查找相关资料
得到的处理方法是清除snapshot快照。
snapshot只是用于加快崩溃后数据恢复的速度而进行的快照，其保存的数据只是大部分的内容，zookeeper启动时先用snapshot恢复 之后再根据事务日志恢复数据，所以如果删除了快照只是启动较慢，并不会丢失数据。
最后发现线上version2中并没有快照文件，采用滚动重启后zookeeper正常启动。
ok, 这里我说另外一个坑, 我们重启服务的时候最好是依从myid从小到大依次重启, 因为这个里面又涉及到zookeeper另外一个设计.zookeeper是需要集群中所有集群两两建立连接, 其中配置中的3555端口是用来进行选举时机器直接建立通讯的端口, 为了避免重复创建tcp连接,如果对方myid比自己大，则关闭连接，这样导致的结果就是大id的server才会去连接小id的server，避免连接浪费.如果是最后重启myid最小的实例,该实例将不能加入到集群中,因为不能和其他集群建立连接, 这时你使用nc命令, 会有如下的提示: This ZooKeeper instance is not currently serving requests. 在zookeeper的启动日志里面你会发现这样的日志: Have smaller server identifier, so dropping the connection. 如果真的出现了这个问题, 也没关系, 但是需要先将报出该问题的实例起着,然后按照myid从小到大依次重启zk实例即可. 是的,我们确实碰到了这个问题, 因为我们稍后会将机房3的那个zk实例的myid变为0,并最后加入到11台实例的集群中,最后一直报这个问题.
Kafka开源项目指南提供详尽教程，助开发者掌握其架构、配置和使用，实现高效数据流管理和实时处理。它高性能、可扩展，适合日志收集和实时数据处理，通过持久化保障数据安全，是企业大数据生态系统的核心。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)