La anomalía en la comunicación entre clústeres del registro de pasos ES hizo que el nodo no pudiera unirse

Descripción del problema

La empresa ha construido un nuevo clúster ES con 4 máquinas y ES versión 7.5.0 La configuración inicial se realizó sin problemas, pero surgirán problemas después de que el clúster se ejecute durante un período de tiempo. El problema se refleja específicamente en la comunicación anormal entre los nodos. El clúster volverá a elegir al maestro, pero después de elegir al maestro, la operación del clúster solo se puede realizar a través del nuevo nodo maestro y otros nodos no pueden unirse al nodo maestro.

Al consultar el registro de ES, encontramos el siguiente error:

[WARN ][o.e.c.s.MasterService    ] [node-1] failing [elected-as-master ([2] nodes joined)[{node-2}{lY51PsdiSW-kBOYQFYjQQw}{HtVGqYX2QRyEjVwQJQEVvA}{134.85.21.43}{134.85.21.43:9303}{dilmrt}{ml.machine_memory=67385552896, ml.max_open_jobs=20, xpack.installed=true, transform.node=true} elect leader, {node-1}{8hu8HMjLRJSJoDNtxtJ1LQ}{bT_S2fTXSeq8GfCwsHUsAA}{134.85.21.42}{134.85.21.42:9303}{dilmrt}{ml.machine_memory=67385552896, xpack.installed=true, transform.node=true, ml.max_open_jobs=20} elect leader, _BECOME_MASTER_TASK_, _FINISH_ELECTION_]]: failed to commit cluster state version [986]
org.elasticsearch.cluster.coordination.FailedToCommitClusterStateException: publication failed
 at org.elasticsearch.cluster.coordination.Coordinator$CoordinatorPublication$4.onFailure(Coordinator.java:1467) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.action.ActionRunnable.onFailure(ActionRunnable.java:88) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:39) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.common.util.concurrent.EsExecutors$DirectExecutorService.execute(EsExecutors.java:226) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.common.util.concurrent.ListenableFuture.notifyListener(ListenableFuture.java:106) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.common.util.concurrent.ListenableFuture.addListener(ListenableFuture.java:68) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.cluster.coordination.Coordinator$CoordinatorPublication.onCompletion(Coordinator.java:1390) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.cluster.coordination.Publication.onPossibleCompletion(Publication.java:125) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.cluster.coordination.Publication.onPossibleCommitFailure(Publication.java:173) ~[elasticsearch-7.9.0.jar:7.9.0]
 at org.elasticsearch.cluster.coordination.Publication.access$500(Publication.java:42) ~[elasticsearch-7.9.0.jar:7.9.0]

El significado general es que el nodo 1 no puede unirse al clúster donde el nodo 2 es el nodo maestro.

Hay dos preguntas aquí. Primero, el nodo 1 era originalmente el nodo maestro. ¿Por qué se unió a los nodos de otras personas? En segundo lugar, ¿por qué el nodo 1 no puede unirse al clúster?

análisis del problema

Desde la perspectiva del fenómeno, el nodo 1 en el clúster era originalmente el nodo maestro, pero ahora el nodo 2 se ha convertido en el nodo maestro, lo que significa que hay un problema con el nodo maestro original, lo que hace que el clúster se vuelva a elegir. el maestro. Pero al observar los registros, no vimos ningún error obvio en el clúster.

A través de las soluciones que se encuentran en Internet, puede ajustar la configuración del tiempo de espera de conexión del clúster ES

cluster.publish.timeout: 15s
cluster.fault_detection.leader_check.timeout: 5s
cluster.fault_detection.follower_check.timeout: 5s
cluster.follower_lag.timeout: 10s

Después de la modificación, aún no hay efecto y aún se producirá una excepción después de que el clúster se haya ejecutado normalmente durante un período de tiempo.

Después de un tiempo de investigación, descubrimos que todavía hay algunos problemas con la comunicación entre los hosts y necesitamos modificar los parámetros de mantenimiento de la comunicación entre los hosts. /etc/sysctl.conf:

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3 
net.ipv4.tcp_keepalive_intvl = 60 

Ejecute el comando para probar que la configuración surta efecto:

sysctl -p

Supongo que te gusta

Origin blog.csdn.net/qq_32907195/article/details/132275023
Recomendado
Clasificación