mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-25 22:36:20 +00:00
1a23417aeb
This commit overhauls the documentation of discovery and cluster coordination, removing mention of the Zen Discovery module and replacing it with docs for the new cluster coordination mechanism introduced in 7.0. Relates #32006
76 lines
2.9 KiB
Plaintext
76 lines
2.9 KiB
Plaintext
[[modules-discovery]]
|
|
== Discovery and cluster formation
|
|
|
|
The discovery and cluster formation module is responsible for discovering
|
|
nodes, electing a master, forming a cluster, and publishing the cluster state
|
|
each time it changes. It is integrated with other modules. For example, all
|
|
communication between nodes is done using the <<modules-transport,transport>>
|
|
module. This module is divided into the following sections:
|
|
|
|
<<modules-discovery-hosts-providers>>::
|
|
|
|
Discovery is the process where nodes find each other when the master is
|
|
unknown, such as when a node has just started up or when the previous
|
|
master has failed.
|
|
|
|
<<modules-discovery-bootstrap-cluster>>::
|
|
|
|
Bootstrapping a cluster is required when an Elasticsearch cluster starts up
|
|
for the very first time. In <<dev-vs-prod-mode,development mode>>, with no
|
|
discovery settings configured, this is automatically performed by the nodes
|
|
themselves. As this auto-bootstrapping is
|
|
<<modules-discovery-quorums,inherently unsafe>>, running a node in
|
|
<<dev-vs-prod-mode,production mode>> requires bootstrapping to be
|
|
explicitly configured via the
|
|
<<modules-discovery-bootstrap-cluster,`cluster.initial_master_nodes`
|
|
setting>>.
|
|
|
|
<<modules-discovery-adding-removing-nodes,Adding and removing master-eligible nodes>>::
|
|
|
|
It is recommended to have a small and fixed number of master-eligible nodes
|
|
in a cluster, and to scale the cluster up and down by adding and removing
|
|
master-ineligible nodes only. However there are situations in which it may
|
|
be desirable to add or remove some master-eligible nodes to or from a
|
|
cluster. This section describes the process for adding or removing
|
|
master-eligible nodes, including the extra steps that need to be performed
|
|
when removing more than half of the master-eligible nodes at the same time.
|
|
|
|
<<cluster-state-publishing>>::
|
|
|
|
Cluster state publishing is the process by which the elected master node
|
|
updates the cluster state on all the other nodes in the cluster.
|
|
|
|
<<no-master-block>>::
|
|
|
|
The no-master block is put in place when there is no known elected master,
|
|
and can be configured to determine which operations should be rejected when
|
|
it is in place.
|
|
|
|
Advanced settings::
|
|
|
|
There are settings that allow advanced users to influence the
|
|
<<master-election-settings,master election>> and
|
|
<<fault-detection-settings,fault detection>> processes.
|
|
|
|
<<modules-discovery-quorums>>::
|
|
|
|
This section describes the detailed design behind the master election and
|
|
auto-reconfiguration logic.
|
|
|
|
include::discovery/discovery.asciidoc[]
|
|
|
|
include::discovery/bootstrapping.asciidoc[]
|
|
|
|
include::discovery/adding-removing-nodes.asciidoc[]
|
|
|
|
include::discovery/publishing.asciidoc[]
|
|
|
|
include::discovery/no-master-block.asciidoc[]
|
|
|
|
include::discovery/master-election.asciidoc[]
|
|
|
|
include::discovery/fault-detection.asciidoc[]
|
|
|
|
include::discovery/quorums.asciidoc[]
|
|
|