Apache zookeeper Zookeeper：若服务器处于r-o模式，来自旧客户端的连接请求将被丢弃

风暴版：0.82

zookeeper版本：3.4.5

我们有一个小风暴集群（1个nimbus和3个supervisors），所以只使用1个zookeeper实例，它与风暴nimbus位于同一位置

我们很少在zookeeper日志中出现以下错误，我们的风暴群就会停止

2014-04-05 13:27:32,885 [myid:] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFact
ory@197] - Accepted socket connection from /10.0.1.183:56121
2014-04-05 13:27:32,886 [myid:] - WARN  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@7
93] - Connection request from old client /10.0.1.183:56121; will be dropped if server is in r-o mode

2014-04-05 13:27:32,886 [myid:] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@8
32] - Client attempting to renew session 0x1452dd02834002e at /10.0.1.183:56121
2014-04-05 13:27:32,886 [myid:] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@5
95] - Established session 0x1452dd02834002e with negotiated timeout 40000 for client /10.0.1.183:561
21

在风暴结束时，我们开始在主管和工人日志中看到以下内容：

2014-04-05 11:37:29 ConnectionStateManager [WARN] There are no ConnectionStateListeners registered.
2014-04-05 11:37:29 cluster [WARN] Received event :disconnected::none: with disconnected Zookeeper.
2014-04-05 11:37:31 ClientCnxn [WARN] Session 0x1452dd028340015 for server null, unexpected error,
losing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
        at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1119)
2014-04-05 11:37:42 CuratorFrameworkImpl [ERROR] Background operation retry gave up
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss
        at org.apache.zookeeper.KeeperException.create(KeeperException.java:90)
        at com.netflix.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(Curat
rFrameworkImpl.java:380)
        at com.netflix.curator.framework.imps.BackgroundSyncImpl$1.processResult(BackgroundSyncImpl
java:49)
        at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:617)
        at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:506)

---

我们是否需要将zookeeper降级到3.3.3，还是缺少已知的问题/配置？

我们在Storm 0.9和zookeeper 3.4.X中也遇到了一些问题，尽管与您描述的不完全一样

Storm邮件列表也报告了此类不兼容问题：

后面的这一条向我们指出了这个Storm pull请求，希望它能让我们在Storm的未来版本发布时使用ZK 3.4.X：

---

在此之前，我建议将ZK降级到3.3.6（如果您绝对需要ZK 3.4.X用于其他系统，则可以为Storm安装一个特定的单独ZK实例）。您也可以克隆Storm代码并在本地合并请求，或者编译最新版本的主干，但这比仅仅等待那些善良的人为我们发布一个新版本有点冒险，也更令人厌倦：）

这种情况的解决方法是清除Storm的数据目录（在strom.yaml==>storm.local.dir中配置），然后重新启动监控程序。我在测试环境中通过清除storm的数据目录并重新启动nimbus和监控程序实现了这一点。

---

我认为这是由storm群集以前的崩溃造成的，并且主管无法从这种情况下恢复。

谢谢Svend。您的经验如何？您建议将storm升级到0.9x吗？我们无法负担一个不稳定的版本，因此选择0.82作为开始。到目前为止，0.9.0.1没有任何问题，因此我建议使用此版本一次尝试。我听说有些人正在使用0.9.1，但我有几个问题，其中包括最近在Netty和0MQ之间发生的内部元组通信迁移。我知道应该在下一个版本中修复，让我们拭目以待……希望这有帮助。按照建议将我们的生产ZK降级为3.3.6。希望如此ngs会更好。在我们的测试集群中试用storm 0.9.0.1。zookeeper事务日志已经失控，扩展速度超过了宇宙。以前没有注意到这种增长速度。您在cron之外做过任何具体的管理吗？我不这么认为，我没有过多接触这一部分，但我记得一位同事提到了script安装在cron中。我没有其他相关信息。