磁盘爆满导致zookeeper卡住

场景复现：

线上服务器磁盘满了导致部署在上面的namenode zookeeper Kafka 均无法工作 抛出异常，清理kafka备份文件后系统磁盘还原了100G+，但是此时的zookeeper节点已经无法再加入集群。

3台 zookeeper节点 出问题的节点在当时是作为leader工作的。

错误日志

抛出异常后节点挂掉。

再次启动之后 该节点已经无法加入已经存在的集群中。

经过查找相关资料

https://issues.apache.org/jira/browse/ZOOKEEPER-1621?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=13557022#comment-13557022

得到的处理方法是清除snapshot快照。

snapshot只是用于加快崩溃后数据恢复的速度而进行的快照，其保存的数据只是大部分的内容，zookeeper启动时先用snapshot恢复 之后再根据事务日志恢复数据，所以如果删除了快照只是启动较慢，并不会丢失数据。

最后发现线上version2中并没有快照文件，采用滚动重启后zookeeper正常启动。

原因见： http://siye1982.github.io/2015/06/16/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台实例的集群中,最后一直报这个问题.