tutorial pelicula kafka juego game apache-zookeeper

apache-zookeeper - pelicula - zookeeper kafka



Error de conexión de Zookeeper (18)

Acabo de resolver el problema. Estoy usando centos 7. Y el creador de problemas es el firewall. Si usa "systemctl stop firewalld" para apagarlo todo en cada servidor, simplemente puede resolver el problema. O puede usar un comando como

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

Finalmente usar

zkServer.sh restart

Para reiniciar tus servidores y resolver el problema.

Tenemos una configuración de zookeeper independiente en una máquina de desarrollo. Funciona bien para cualquier otra máquina de desarrollo, excepto esta máquina de testdev.

Obtenemos este error una y otra vez cuando intentamos conectarnos con zookeeper a través de 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

Intentamos reiniciar la máquina de desarrollo de prueba y también reiniciar el host de zookeeper pero nada funcionó. Estamos totalmente confundidos de por qué funciona perfectamente bien con otras máquinas excepto esta. ¿Cuál podría ser la causa de esto?

Ahora mismo resolví la misma pregunta y publico un blog .

En resumen, si xx''s zoo.cfg gusta:

server.1=xx:2888:3888 server.2=yy:2888:3888 server.3=zz:2888:3888

entonces myx de xx = 1 es must

Asegúrese de que todos los servicios requeridos se estén ejecutando

Paso 1: Comprueba si hbase-master se está ejecutando

sudo /etc/init.d/hbase-master status

si no, entonces inicie sudo /etc/init.d/hbase-master start

Paso 2: Comprueba si hbase-regionserver se está ejecutando

sudo /etc/init.d/hbase-regionserver status

si no, entonces inicie sudo /etc/init.d/hbase-regionserver start

Paso 3: Comprueba si zookeeper-server se está ejecutando

sudo /etc/init.d/zookeeper-server status

si no, entonces inicie sudo /etc/init.d/zookeeper-server start


o simplemente ejecute estos 3 comandos en una fila.

sudo /etc/init.d/hbase-master restart sudo /etc/init.d/hbase-regionserver restart sudo /etc/init.d/zookeeper-server restart

Después de eso no te olvides de revisar el estado.

sudo /etc/init.d/hbase-master status sudo /etc/init.d/hbase-regionserver status sudo /etc/init.d/zookeeper-server status

Es posible que el guardián del zoológico aún no se esté ejecutando: entonces puede ejecutar el guardián del zoológico

sudo /usr/lib/zookeeper/bin/zkServer.sh stop sudo /usr/lib/zookeeper/bin/zkServer.sh start

después de eso otra vez verifique el estado y asegúrese de que está funcionando

sudo /etc/init.d/zookeeper-server status

Esto debería funcionar.

Comienzo una instancia independiente en mi máquina y encuentro el mismo problema. Finalmente, cambio de ip "127.0.0.1" a "localhost" y el problema desaparece.

Compruebe los registros de zookeeper (/ var / log / zookeeper). Parece que se ha establecido una conexión, lo que debería significar que hay un registro de la misma.

Tuve la misma situación y fue porque un proceso abrió conexiones y no pudo cerrarlas. Esto finalmente excedió el límite de conexión por host y mis registros se desbordaron

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

Suponiendo que el guardián del zoológico se encuentre en el puerto habitual, podría verificarlo con:

lsof -i -P | grep 2181

En mi caso, configuro zoo.cfg así:

server.1=host-1:2888:3888 server.2=host-2:2888:3888 server.3=host-3:2888:3888

Pero, en el host-1, configuro el host-1 para resolver 127.0.0.1 en / etc / hosts:

127.0.0.1 localhost host-1

lo que puede resultar que otros hosts no puedan comunicarse con él. Resolver el host-1 a su ip real resuelto este problema.

Espero que esto pueda ayudar.

Enfrenté el mismo problema y descubrí que se debía a que los nodos del clúster Zookeeper necesitan puertos abiertos para comunicarse entre sí.

server.1=xx.xx.xx.xx:2888:3888 server.2=xx.xx.xx.xx:2888:3888 server.3=xx.xx.xx.xx:2888:3888

Una vez permití estos puertos a través del grupo de seguridad aws y reinicié. Todo funciono bien para mi

Estaba teniendo el mismo error cuando intentaba conectar mi agente con mi conjunto Zookeeper usando registros A para apuntar a las IP de Zookeeper. El problema estaba en mis cuidadores. Mis cuidadores no pudieron vincularse al puerto 2181 porque estaba apuntando mis registros A a IP pública. Esto impedía que el conjunto del guardián del zoológico eligiera un líder y se comunicara entre ellos. Los registros de apuntar A a IP privada permitieron al conjunto del zookeeper elegir un líder y el clúster se activó. Después de esto, cuando intenté conectar uno de mis corredores al conjunto, se conectó correctamente.

Este es un problema común si el servidor Zookeeper no se está ejecutando o ya no se está ejecutando (es decir, se bloqueó después de que lo inició).

Así que primero, comprueba que tienes el servidor Zookeeper en ejecución. Una forma sencilla de comprobar es grep los procesos en ejecución:

# ps -ef | grep zookeeper

(ejecute esto un par de veces para ver si el mismo ID de proceso todavía está allí. Es posible que continúe reiniciando con un nuevo ID de proceso. Alternativamente, puede usar ''systemctl status zookeeper'' si su distribución Linux es compatible con systemd)

Debería ver el proceso ejecutándose como un proceso java:

# ps -ef | grep zookeeper root 492 0 0 00:01 pts/1 00:00:00 java -Dzookeeper.log.dir=. -Dzookeeper.root.logger=INFO,CONSOLE -cp /root/zookeeper-3.5.0-alpha/bin/../build/classes:/root/zookeeper-3.5.0-alpha/bin/../build/lib/*.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/slf4j-log4j12-1.7.5.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/slf4j-api-1.7.5.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/servlet-api-2.5-20081211.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/netty-3.7.0.Final.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/log4j-1.2.16.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/jline-2.11.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/jetty-util-6.1.26.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/jetty-6.1.26.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/javacc.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/jackson-mapper-asl-1.9.11.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/jackson-core-asl-1.9.11.jar:/root/zookeeper-3.5.0-alpha/bin/../lib/commons-cli-1.2.jar:/root/zookeeper-3.5.0-alpha/bin/../zookeeper-3.5.0-alpha.jar:/root/zookeeper-3.5.0-alpha/bin/../src/java/lib/*.jar:/root/zookeeper-3.5.0-alpha/bin/../conf: -Xmx1000m -Xmx1000m -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /root/zookeeper-3.5.0-alpha/bin/../conf/zoo.cfg

Si no está allí, es probable que haya algo en el archivo de registro del guardián del zoológico que indique el problema.

Para encontrar el archivo de registro del guardián del zoológico, primero debe averiguar dónde está configurado para el registro. En mi caso, tengo instalado zookeeper en mi directorio raíz (no sugiero que lo instale allí):

[root@centos6_zookeeper conf]# pwd /root/zookeeper-3.5.0-alpha/conf

Y puede encontrar la configuración de registro en este archivo:

[root@centos6_zookeeper conf]# grep "zookeeper.log" log4j.properties zookeeper.log.dir=/var/log zookeeper.log.file=zookeeper.log zookeeper.log.threshold=INFO zookeeper.log.maxfilesize=256MB zookeeper.log.maxbackupindex=20

Así que Zookeeper está configurado para registrar en / var / log.

Luego suele haber un archivo zookeeper.log y / o zookeeper.out que debería indicar el error de inicio.

Esto puede suceder si hay demasiadas conexiones abiertas.

Intente aumentar la configuración maxClientCnxns .

De la documentation :

maxClientCnxns (ninguna propiedad del sistema Java)

Limita el número de conexiones simultáneas (a nivel de socket) que un solo cliente, identificado por dirección IP, puede realizar a un solo miembro del conjunto ZooKeeper. Esto se utiliza para prevenir ciertas clases de ataques DoS, incluido el agotamiento del descriptor de archivos. Al establecer esto en 0 u omitirlo, se elimina por completo el límite de conexiones simultáneas.

Puede editar la configuración en el archivo de configuración. Lo más probable es que se pueda encontrar en /etc/zookeeper/conf/zoo.cfg .

En las versiones modernas de ZooKeeper, el valor predeterminado es 60. Puede aumentarlo agregando la línea maxClientCnxns=4096 al final del archivo de configuración.

Pude comenzar con Zookeeper y Kafka teniendo 2 nodos cada uno. Recibí el error porque había iniciado zookeeper con ./zkServer.sh en lugar de kafka wrapper bin / zookeeper-server-start.sh config / zookeeper.properties

También encontré el mismo problema. En mi caso el problema es sobre las reglas de iptables.

Para comunicarse con el nodo zookeeper, el puerto 2181 debe aceptar la solicitud entrante, también para la comunicación interna entre los nodos zookeeper. Los puertos 2888,3888 deben estar abiertos para la solicitud 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

También me encontré con este problema la semana pasada y he logrado solucionar este problema ahora. Tuve la idea de resolver esto a partir de la respuesta compartida por @gukoff.

Mi requerimiento y situación eran ligeramente diferentes a los compartidos hasta ahora, pero el problema era básicamente el mismo, así que pensé en compartirlo en este hilo.

En realidad, estaba intentando consultar el quórum del zookeeper (después de cada 30 segundos) para obtener información de mi aplicación y estaba utilizando el Marco Curator para este propósito (los métodos disponibles en la clase LeaderLatch ). Así que, básicamente, estaba iniciando un cliente CuratorFramework y suministrando esto al objeto LeaderLatch .

Solo después de que encontré el error mencionado en este hilo, me di cuenta de que no cerré la (s) conexión (es) de cliente zookeeper establecida en mis aplicaciones. La propiedad maxClientCnxns tenía el valor de 60 y, tan pronto como el número de conexiones (todas fueron conexiones obsoletas) llegó a 60, mi aplicación comenzó a quejarse con este error.

Descubrí el número de conexiones abiertas por:

  1. Verificando los registros del guardián del zoológico, donde había mensajes de advertencia que decían "Demasiadas conexiones desde {dirección IP del servidor}"

  2. Ejecutar el siguiente comando netstat desde el mismo host mencionado en los registros anteriores donde se ejecutaba mi aplicación:

netstat -no | grep: 2181 | wc -l

Nota : El puerto 2181 es el predeterminado para el guardián del zoológico que se proporciona como un parámetro en grep para que coincida con las conexiones del guardián del zoológico.

Para solucionar esto, borré todas esas conexiones obsoletas manualmente y luego agregué el código para cerrar las conexiones del cliente zookeeper con gracia en mi aplicación.

¡Espero que esto ayude!

También tuve este problema, y ​​encontré que solo necesito reiniciar Zookeeper, luego reiniciar Tomcat para que mi aplicación web se conecte bien.

También tuve este problema, y ​​resultó que le estaba diciendo a Zookeeper que se conecte al puerto incorrecto. ¿Has verificado que zookeeper se está ejecutando en el puerto 2181 en la máquina dev?

Tengo la misma situación que tú y acabo de solucionar este problema.

Es la razón por la que ha configurado un número par de cuidadores del zoológico que resultan directamente en este problema, intente cambiar su número de nodo de guardián del zook a uno impar.

por ejemplo, el estado original de mi clúster zookeeper consta de 4 nodos, luego solo elimine uno de ellos, lo que hace que la cantidad de nodos sea 3 bien, ahora está bien para iniciar el clúster zookeeper

A continuación se muestra la salida de la conexión exitosa al servidor 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

Tengo la misma situación que tú y acabo de solucionar este problema.

mi conf/zoo.cfg como este:

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

Luego configuro el contenido del archivo de data/myid como este:

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

finalmente reiniciar Zookeeper

Tuvo el mismo error durante la configuración en un clúster de 2 nodos. Descubrí que había mezclado el contenido del archivo myid en comparación con server.id = HOST_IP: entrada de puerto.

Esencialmente, si tiene dos servidores (SERVER1 y SERVER2) para los cuales ha creado archivos "myid" en dataDir para zookeeper como se muestra a continuación

SERVER1 (myid) 1 SERVER2 (myid) 2

Asegúrese de que la entrada en su archivo zoo.cfg se corresponda con cada uno de estos, es decir, server.1 debe usar el nombre de host SERVER1 y server.2 debe usar el nombre de host SERVER2 seguido del puerto como se muestra a continuación

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

Solo para asegurarme, también eliminé la carpeta version- * en el dataDir y luego reinicié Zookeeper para que funcionara.