La primera vez que obtengo esto, puede haber algunos problemas en la siguiente descripción, solo como referencia, intente ver los documentos oficiales y los enlaces que se enumeran a continuación.
1. Problemas del cerebro dividido
ref: https://qbox.io/blog/split-brain-problem-elasticsearch
Cuando un nodo falla o la comunicación entre los nodos se interrumpe por alguna razón, aparecerá un problema. Si un nodo esclavo
no puede comunicarse con el nodo maestro, elegirá un nuevo nodo maestro del nodo maestro que todavía está conectado a él. Luego, el nuevo
nodo maestro asumirá las responsabilidades del nodo maestro anterior. Si el antiguo nodo maestro vuelve a unirse al clúster o reanuda la comunicación, el nuevo
nodo maestro lo degradará a un nodo esclavo, por lo que no hay conflicto. En la mayoría de los casos, este proceso es fluido y "efectivo".
Sin embargo, si considera el caso de solo dos nodos: un nodo maestro y un nodo esclavo. Si se interrumpe la comunicación entre los dos, el
esclavo será promovido a maestro, pero una vez que se restablezca la comunicación, tendrá dos nodos maestros. El nodo maestro original
cree que el nodo esclavo está fuera de línea y debe volver a funcionar como un nodo esclavo, mientras que el nuevo nodo maestro cree que el nodo maestro original está fuera de línea y debería ser un nodo esclavo.
En este momento, habrá un problema de cerebro dividido en racimos. (Las pruebas personales no reprodujeron el problema del cerebro dividido de los dos nodos. Puede que no haya una
razón para realizar pruebas en profundidad. Después de que el nodo esclavo de los dos nodos de mi lado cuelga, el nodo maestro normalmente puede realizar modificaciones / operaciones de consulta, pero el nodo maestro se cuelga
Más tarde, debido a que el nodo esclavo también es un nodo de datos, aún se puede consultar, pero no se puede modificar. Debido a que
el complemento python es se usa desde el nivel de código, el complemento puede proteger el problema del cerebro dividido causado por dos nodos. Mecanismo,
cuando el código realiza operaciones de modificación, siempre intentará conectarse al nodo maestro fallido, lo que da como resultado una excepción de tiempo de espera, y la sincronización de datos durante la operación es normal)
Consulte otro blog para obtener una descripción: suponga que tiene un clúster de 10 nodos y 3 nodos están desconectados del clúster.
Debido al mecanismo de descubrimiento, estos 3 nodos pueden formar un nuevo clúster, lo que da como resultado dos El clúster con el mismo nombre, esto es
cerebro dividido, necesita establecer discovery.zen.minium_master_nodes: 6 (este nodo es demasiado,
no hay una prueba real, pero es comprensible mirando la descripción, aquí hay 4 nodos para probar 3 quórums , es decir, 3 quórumes)
Hay una publicación en el foro oficial para discutir los problemas del cerebro dividido de dos nodos, puede consultar Para evitar problemas del cerebro dividido.
Ref: https://discuss.elastic.co/t/how-can-a-configure- dos-nodos-en-un-clúster / 171088/11
publicaciones tienen miembros es equipo, dijo:. Eso es en la recomendación para Evitar el cerebro dividido y la DELINCUENCIA
. Los 3 nodos DEBEN SER nodos elegibles Master Básicamente y enumera la información de configuración para tres Nodos.
Por lo tanto, se recomienda configurar al menos 3 nodos. Por supuesto, cuantos más nodos, mejor HA puede ser, dependiendo de la situación real del negocio y los
recursos disponibles del servidor.
También hay una descripción del clúster de dos nodos en el documento oficial es, pero es importante señalar: Debido a que no es resistente a fallas,
no recomendamos implementar un clúster de dos nodos en producción. Por lo tanto, no se recomienda para
participar en un clúster de dos nodos en producción .
Cuando estaba probando la conmutación por error de dos nodos, después de realizar la siguiente configuración simple,
discovery.seed_hosts: ["ip1", "ip2"]
cluster.initial_master_nodes: ["ip1", "ip2"]
descubrió:
Si el nodo esclavo está abajo: Hay un nodo principal a la izquierda, los Informe eS puede ver que el nodo esclavo está a la izquierda (a la izquierda) y no hay información anormal es lanzada, y
las operaciones de modificación y operaciones de consulta en el lado código todavía se puede completar con normalidad.
Si el cuelga nodo maestro: restante para un nodo esclavo, el informe ES informará de un error de conexión y siempre tratar de desencadenar la elección, pero siempre tratar de acceder al nodo maestro durante la elección (consulte el registro de más abajo).
la operación de consulta sobre la El lado del código se puede completar normalmente, pero la operación de modificación no se puede realizar. Realizar la operación de modificación desde el lado del código informará la conexión a la excepción de tiempo de espera del nodo maestro
(quiero lograr el efecto de la replicación maestro-esclavo con redis-that es decir, el nodo esclavo actualizará automáticamente el nodo maestro después de que el nodo maestro se cuelgue, pero en realidad, no se puede lograr. Debido a que el nodo esclavo ha estado
intentando hacer ping al nodo maestro, lo que resultó en una excepción de error de conexión)
Después de que el nodo maestro cuelga, el registro del nodo esclavo: maestro no descubierto o elegido todavía, una elección requiere un nodo con id [ID de nodo maestro], ... he descubierto [nodo esclavo] que no es un quórum; el descubrimiento continuará usando [master Node]
ref: https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability-cluster-small-clusters.html#high-availability-cluster-design-two-nodes
2.es mecanismo de descubrimiento automático incorporado: zen
ref: https://www.elastic.co/guide/en/elasticsearch/reference/6.8/modules-discovery-zen.html
solo necesita configurar el mismo cluster.name para conectar el nodo Unirse al mismo clúster
Clúster de 4 nodos
cluster.name: my-application
node.name: node-1
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip1
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
cluster.name: my-application
node.name: node-2
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip2
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
cluster.name: my-application
node.name: node-3
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip3
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
cluster.name: my-application
node.name: node-4
path.data: /opt/es/elasticsearch-7.6.1/data
path.logs: /opt/es/elasticsearch-7.6.1/log
network.host: ip4
http.port: 9200
discovery.seed_hosts: ["ip1", "ip2", "ip3", "ip4"]
cluster.initial_master_nodes: ["ip1", "ip2", "ip3", "ip4"]
bootstrap.system_call_filter: false
bootstrap.memory_lock: false
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.minimum_master_nodes: 3
Verifique el estado de salud de un nodo
Visita: http: // ip: 9200 / _cluster / health
returns:
{
"cluster_name": "my-application",
"status": "green",
"timed_out": false,
"number_of_nodes": 4,
"number_of_data_nodes": 4,
"active_primary_shards": 6,
"active_shards": 12,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 100
}