Erreur de connexion Zookeeper
Nous avons une configuration autonome de gardien de zoo sur une machine de développement. Cela fonctionne bien pour toutes les autres machines de développement, sauf cette machine testdev.
Nous obtenons cette erreur encore et encore lorsque nous essayons de nous connecter à zookeeper via testdev:
2012-11-09 14:06:53,909 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@947] - Socket connection established to zk01.dev.bunchball.net/192.168.8.58:2181, initiating session
2012-11-09 14:06:53,911 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@1183] - Unable to read additional data from server sessionid 0x0, likely server has closed socket, closing socket connection and attempting reconnect
2012-11-09 14:06:55,366 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@1058] - Opening socket connection to server zk01.dev.bunchball.net/192.168.8.58:2181
2012-11-09 14:06:55,368 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@947] - Socket connection established to zk01.dev.bunchball.net/192.168.8.58:2181, initiating session
2012-11-09 14:06:55,368 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@1183] - Unable to read additional data from server sessionid 0x0, likely server has closed socket, closing socket connection and attempting reconnect
2012-11-09 14:06:57,271 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@1058] - Opening socket connection to server zk01.dev.bunchball.net/192.168.8.58:2181
2012-11-09 14:06:57,274 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@947] - Socket connection established to zk01.dev.bunchball.net/192.168.8.58:2181, initiating session
2012-11-09 14:06:57,275 - INFO [main-SendThread(zk01.dev.bunchball.net:2181):ClientCnxn$SendThread@1183] - Unable to read additional data from server sessionid 0x0, likely server has closed socket, closing socket connection and attempting reconnect
Nous avons essayé de redémarrer la machine de développement de test, et également de redémarrer l'hôte zookeeper, mais rien n'a fonctionné. Nous ne savons absolument pas pourquoi cela fonctionne parfaitement avec d'autres machines, sauf celle-ci. Quelle pourrait en être la cause?
J'ai juste la même situation que vous et je viens de résoudre ce problème.
C'est la raison pour laquelle vous avez configuré un nombre pair de gardiens de zoo qui entraînent directement ce problème, essayez de changer votre nombre de nœuds de gardien de zoo en un impair.
par exemple, le statut d'origine de mon cluster zookeeper est composé de 4 nœuds, puis supprimez simplement l'un d'entre eux, ce qui entraîne un nombre de nœuds égal à 3, il est maintenant possible de démarrer le cluster zookeeper
ci-dessous est la sortie de se connecter avec succès au serveur zookeeper
2013-04-22 22:07:05,654 [myid:] - INFO [main:ZooKeeper@438] - Initiating client connection, connectString=localhost:2181 sessionTimeout=30000 watcher=org.Apache.zookeeper.ZooKeeperMain$MyWatcher@1321ed6
Welcome to ZooKeeper!
2013-04-22 22:07:05,704 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@966] - Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error)
JLine support is enabled
2013-04-22 22:07:05,727 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@849] - Socket connection established to localhost/127.0.0.1:2181, initiating session
[zk: localhost:2181(CONNECTING) 0] 2013-04-22 22:07:05,846 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@1207] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x13e3211c06e0000, negotiated timeout = 30000
J'ai rencontré le même problème et j'ai découvert que c'était dû aux nœuds de cluster zookeeper qui avaient besoin de ports ouverts pour communiquer entre eux.
server.1=xx.xx.xx.xx:2888:3888
server.2=xx.xx.xx.xx:2888:3888
server.3=xx.xx.xx.xx:2888:3888
une fois que j'ai autorisé ces ports via le groupe de sécurité aws et redémarré. Tout a bien fonctionné pour moi
Je viens de résoudre le problème. J'utilise centos 7. Et le fauteur de troubles est le pare-feu. L'utilisation de "systemctl stop firewalld" pour tout fermer sur chaque serveur peut simplement résoudre le problème. Ou vous pouvez utiliser une commande comme
firewall-cmd --zone=public --add-port=2181/udp --add-port=2181/tcp --permanent" to configure all three ports ,include 2181,2888,3888 in each server.And then "firewall-cmd --reload
Enfin utiliser
zkServer.sh restart
pour redémarrer vos serveurs et problème résolu.
Dans mon cas, je configure Zoo.cfg comme ceci:
server.1=Host-1:2888:3888
server.2=Host-2:2888:3888
server.3=Host-3:2888:3888
Mais, dans Host-1, je configure la résolution Host-1 à 127.0.0.1 dans/etc/hosts:
127.0.0.1 localhost Host-1
ce qui peut empêcher d'autres hôtes de communiquer avec lui. Résoudre Host-1 à sa véritable adresse IP a résolu ce problème.
J'espère que cela peut vous aider.
J'avais la même erreur lorsque j'essayais de connecter mon courtier à mon ensemble Zookeeper en utilisant des enregistrements A pour pointer vers les adresses IP de Zookeeper. Le problème était dans mes zookeepers. Mes zookeepers n'ont pas pu se lier au port 2181 car je pointais mes enregistrements A vers l'IP publique. Cela empêchait l'ensemble de gardien de zoo de choisir un leader et de communiquer entre eux. Le pointage des enregistrements A vers une adresse IP privée a permis à l'ensemble zookeeper de choisir un leader et le cluster est devenu actif. Après cela, lorsque j'ai essayé de connecter l'un de mes courtiers à l'ensemble, il s'est connecté avec succès.
J'ai aussi eu ce problème, et il s'est avéré que je disais à zookeeper de se connecter au mauvais port. Avez-vous vérifié que zookeeper fonctionne réellement sur le port 2181 sur la machine de développement?
J'ai aussi eu ce problème, et j'ai trouvé que je dois juste redémarrer zookeeper, puis redémarrer Tomcat pour que ma webapp se connecte bien puis
J'ai également rencontré ce problème la semaine dernière et j'ai réussi à le résoudre maintenant. J'ai eu l'idée de résoudre celui-ci à partir de la réponse partagée par @gukoff.
Mes exigences et ma situation étaient légèrement différentes de celles partagées jusqu'à présent, mais le problème était fondamentalement le même, alors j'ai pensé à le partager sur ce fil.
J'essayais en fait d'interroger le quorum zookeeper (après toutes les 30 secondes) pour obtenir des informations de mon application et j'utilisais le Curator Framework à cette fin (les méthodes disponibles dans la classe LeaderLatch ). Donc, essentiellement, je démarrais un client CuratorFramework et je le fournissais à l'objet LeaderLatch .
Ce n'est qu'après avoir rencontré l'erreur mentionnée dans ce fil - je me suis rendu compte que je n'avais pas fermé la ou les connexions client zookeeper établies dans mes applications. La propriété maxClientCnxns avait la valeur 60 et dès que le nombre de connexions (toutes étaient des connexions périmées) atteignait 60, mon application a commencé à se plaindre de cette erreur.
J'ai découvert le nombre de connexions ouvertes par:
Vérification des journaux zookeeper, où il y avait des messages d'avertissement indiquant "Trop de connexions de {adresse IP de l'hôte}"
Exécution de la commande
netstatsuivante à partir du même hôte mentionné dans les journaux ci-dessus où mon application s'exécutait:
netstat -no | grep: 2181 | wc -l
Remarque : Le port 2181 est le port par défaut pour zookeeper fourni comme paramètre dans grep pour correspondre aux connexions zookeeper.
Pour résoudre ce problème, j'ai effacé toutes ces connexions obsolètes manuellement, puis ajouté le code pour fermer les connexions client zookeeper avec élégance dans mon application.
J'espère que ça aide!
Cela peut se produire s'il y a trop de connexions ouvertes.
Essayez d'augmenter le paramètre maxClientCnxns.
De documentation :
maxClientCnxns (No Java)
Limite le nombre de connexions simultanées (au niveau du socket) qu'un seul client, identifié par l'adresse IP, peut établir avec un seul membre de l'ensemble ZooKeeper. Ceci est utilisé pour empêcher certaines classes d'attaques DoS, y compris l'épuisement des descripteurs de fichiers. La définition de 0 ou son omission supprime entièrement la limite de connexions simultanées.
Vous pouvez modifier les paramètres dans le fichier de configuration. Très probablement, il peut être trouvé à /etc/zookeeper/conf/Zoo.cfg.
Dans les versions modernes de ZooKeeper, la valeur par défaut est 60. Vous pouvez l'augmenter en ajoutant le maxClientCnxns=4096 ligne jusqu'à la fin du fichier de configuration.
J'ai pu commencer avec zookeeper et kafka ayant 2 nœuds chacun. J'ai eu l'erreur parce que j'avais démarré zookeeper avec ./zkServer.sh au lieu de kafka = wrapper bin/zookeeper-server-start.sh config/zookeeper.properties
Je démarre une instance autonome sur ma machine et rencontre le même problème. Enfin, je passe de l'ip "127.0.0.1" à "localhost" et le problème a disparu.
Vérifiez également le pare-feu local, état du pare-feu du service
S'il est en cours d'exécution, arrêtez-le simplement service firewalld stop
Et puis essayez-le.
Assurez-vous que tous les services requis sont en cours d'exécution
Étape 1: Vérifiez si hbase-master est en cours d'exécution
Sudo /etc/init.d/hbase-master status
sinon, démarrez-le Sudo /etc/init.d/hbase-master start
Étape 2: vérifier si le serveur de régions hbase est en cours d'exécution
Sudo /etc/init.d/hbase-regionserver status
sinon, démarrez-le Sudo /etc/init.d/hbase-regionserver start
Étape 3: Vérifiez si le serveur zookeeper est en cours d'exécution
Sudo /etc/init.d/zookeeper-server status
sinon, démarrez-le Sudo /etc/init.d/zookeeper-server start
ou exécutez simplement ces 3 commandes d'affilée.
Sudo /etc/init.d/hbase-master restart
Sudo /etc/init.d/hbase-regionserver restart
Sudo /etc/init.d/zookeeper-server restart
après cela, n'oubliez pas de vérifier l'état
Sudo /etc/init.d/hbase-master status
Sudo /etc/init.d/hbase-regionserver status
Sudo /etc/init.d/zookeeper-server status
Vous pourriez constater que zookeeper ne fonctionne toujours pas: alors vous pouvez exécuter le zookeeper
Sudo /usr/lib/zookeeper/bin/zkServer.sh stop
Sudo /usr/lib/zookeeper/bin/zkServer.sh start
après cela, vérifiez à nouveau l'état et assurez-vous que son fonctionnement
Sudo /etc/init.d/zookeeper-server status
Cela devrait fonctionner.
J'ai juste la même situation que vous et je viens de résoudre ce problème.
mon conf/Zoo.cfg juste comme ça:
server.1=10.194.236.32:2888:3888
server.2=10.194.236.33:2888:3888
server.3=10.208.177.15:2888:3888
server.4=10.210.154.23:2888:3888
server.5=10.210.154.22:2888:3888
alors j'ai mis data/myid le contenu du fichier comme ceci:
1 //at Host 10.194.236.32
2 //at Host 10.194.236.33
3 //at Host 10.208.177.15
4 //at Host 10.210.154.23
5 //at Host 10.210.154.22
enfin redémarrer zookeeper
Vérifiez les journaux zookeeper (/ var/log/zookeeper). Il semble qu'une connexion soit établie, ce qui devrait signifier qu'elle existe.
J'ai eu la même situation et c'est parce qu'un processus a ouvert des connexions et n'a pas réussi à les fermer. Cela a finalement dépassé la limite de connexion par hôte et mes journaux débordaient de
2016-08-03 15:21:13,201 [myid:] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@188] - Too many connections from /172.31.38.64 - max is 50
En supposant que zookeeper se trouve sur le port habituel, vous pouvez vérifier cela avec:
lsof -i -P | grep 2181
A eu la même erreur lors de l'installation sur un cluster à 2 nœuds. J'ai découvert que j'avais mélangé le contenu du fichier myid avec le server.id = Host_IP: entrée de port.
Essentiellement, si vous avez deux serveurs (SERVER1 et SERVER2) pour lesquels vous avez créé des fichiers "myid" dans dataDir pour zookeeper comme ci-dessous
SERVER1 (myid)
1
SERVER2 (myid)
2
Assurez-vous que l'entrée dans votre fichier Zoo.cfg correspond à chacun d'entre eux, c'est-à-dire que server.1 doit utiliser le nom d'hôte SERVER1 et server.2 doit utiliser le nom d'hôte SERVER2 suivi du port comme ci-dessous
SERVER1 (Zoo.cfg)
... (other config omitted)
server.1=SERVER1:2888:3888
server.2=SERVER2:2888:3888
SERVER2 (Zoo.cfg)
... (other config omitted)
server.1=SERVER1:2888:3888
server.2=SERVER2:2888:3888
Juste pour être sûr, j'ai également supprimé le dossier version- * dans le dataDir puis redémarré Zookeeper pour le faire fonctionner.
Impossible de lire les données supplémentaires du serveur sessionid 0x0, le serveur a probablement fermé le socket, fermé la connexion du socket et tenté de se reconnecter (org.Apache.zookeeper.ClientCnxn)
J'ai changé juste le nombre de courtiers dans le fichier Zoo.cfg et redémarré zookeeper et le service kafka
J'ai également la même erreur lorsque j'ai démarré mon zk répliqué, l'un des zkClient ne peut pas se connecter à localhost: 2181, j'ai vérifié le fichier journal sous le répertoire Apache-zookeeper-3.5.5-bin/logs, et j'ai trouvé ceci:
2019-08-20 11: 30: 39,763 [myid: 5] - AVERTISSEMENT [QuorumPeermyid = 5 (sécurisé = désactivé): QuorumCnxManager @ 677] - Impossible d'ouvrir le canal à 3 à l'adresse électorale/xxxx: 3888 Java.net.SocketTimeoutException: connect timed out sur Java.net.PlainSocketImpl.socketConnect (Native Method) sur Java.net.AbstractPlainSocketImpl.doConnect (AbstractPlainSocketImpl.Java:350) sur Java.net.AbstractPlainSocketImpl.connectToAddress (AbstractPlainSocketImpl.Java:206) sur Java.net. AbstractPlainSocketImpl.connect (AbstractPlainSocketImpl.Java:188) sur Java.net.SocksSocketImpl.connect (SocksSocketImpl.Java:392) sur Java.net.Socket.connect (Socket.Java:589) sur org.Apache.zookeeper.server.quorum .QuorumCnxManager.connectOne (QuorumCnxManager.Java:648) à org.Apache.zookeeper.server.quorum.QuorumCnxManager.connectOne (QuorumCnxManager.Java:705) à org.Apache.zookeeper.server.quorum.QuorumCnxManagerConnect : 733) sur org.Apache.zookeeper.server.quorum.FastLeaderElection.lookForLeader (FastLeaderElection.Java:910) sur org. Apache.zookeeper.server.quorum.QuorumPeer.run (QuorumPeer.Java:1247) 2019-08-20 11: 30: 44,768 [myid: 5] - WARN [QuorumPeermyid = 5 (secure = désactivé): QuorumCnxManager @ 677] - Impossible d'ouvrir le canal à 4 à l'adresse d'élection/xxxxxx: 3888 Java.net.SocketTimeoutException: la connexion a expiré à Java.net.PlainSocketImpl.socketConnect (méthode native) à Java.net.AbstractPlainSocketImpl.doConnect (AbstractPlainSocketImpl.Java:350) à Java .net.AbstractPlainSocketImpl.connectToAddress (AbstractPlainSocketImpl.Java:206) sur Java.net.AbstractPlainSocketImpl.connect (AbstractPlainSocketImpl.Java:188) sur Java.net.SocksSocketImpl.connect (SocksSocketImpl.Java:392) sur Java.net.Socket. connect (Socket.Java:589) à org.Apache.zookeeper.server.quorum.QuorumCnxManager.connectOne (QuorumCnxManager.Java:648) à org.Apache.zookeeper.server.quorum.QuorumCnxManager.connectOne (QuorumCnxManager.Java:705) à org.Apache.zookeeper.server.quorum.QuorumCnxManager.connectAll (QuorumCnxManager.Java:733) à org.Apache.zookeeper.server.quorum .FastLeaderElection.lookForLeader (FastLeaderElection.Java:910) sur org.Apache.zookeeper.server.quorum.QuorumPeer.run (QuorumPeer.Java:1247) 2019-08-20 11: 30: 44,769 [myid: 5] - INFO [ QuorumPeermyid = 5 (sécurisé = désactivé): FastLeaderElection @ 919] - Délai de notification: 51200
cela signifie que ce serveur zk ne peut pas se connecter à d'autres serveurs, et j'ai trouvé que ce serveur ping d'autres serveurs échouent, et après avoir supprimé ce serveur de la réplique, le problème est résolu.
j'espère que cela vous sera utile.
J'ai aussi rencontré le même problème. Dans mon cas, le problème concerne les règles iptables.
Pour communiquer avec le nœud zookeeper, le port 2181 doit accepter la demande entrante, également pour la communication interne entre les nœuds zookeeper, les ports 2888,3888 doivent être ouverts pour la demande entrante.
iptables -t nat -I PREROUTING -p tcp -s 10.0.0.0/24 --dport 2181 -j DNAT --to-destination serverIp:2181
iptables -t nat -I PREROUTING -p udp -s 10.0.0.0/24 --dport 2181 -j DNAT --to-destination serverIp:2181
iptables -t nat -I PREROUTING -p tcp -s 10.0.0.0/24 --dport 2888 -j DNAT --to-destination serverIp:2888
iptables -t nat -I PREROUTING -p udp -s 10.0.0.0/24 --dport 2888 -j DNAT --to-destination serverIp:2888
iptables -t nat -I PREROUTING -p tcp -s 10.0.0.0/24 --dport 3888 -j DNAT --to-destination serverIp:3888
iptables -t nat -I PREROUTING -p udp -s 10.0.0.0/24 --dport 3888 -j DNAT --to-destination serverIp:3888
Sudo service iptables save