[Zen2] Update documentation for Zen2 #34714
Conversation
DaveCTurner
added
>docs
|
Pinging @elastic/es-distributed |
|
Pinging @vladimirdolzhenko and @andrershov since our discussions a couple of weeks back helped me write these docs. |
There was a problem hiding this comment.
@DaveCTurner Thank you for the nice write-up, it really makes things easier to understand. I still feel that we can a better job of expaining cluster.master_nodes_failure_tolerance, probably by giving more examples...
|
I have substantially reworked the section about auto-reconfiguration and offered a different setting as we discussed to cover the ≥2-node-redundancy case. I think I've also addressed most of the other comments. I haven't renamed the retirement API to something else because I'm still seeking a good name. I think the form of this API is good, it just needs renaming. |
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
Co-Authored-By: DaveCTurner <david.turner@elastic.co>
| has already been bootstrapped. | ||
|
|
||
| This setting can be given on the command line when starting up each | ||
| master-eligible node, or added to the `elasticsearch.yml` configuration file on |
There was a problem hiding this comment.
If we only did it on one node, and then that node failed at some point during cluster formation, then there's no truly safe way to proceed. Setting it on multiple nodes avoids this risk.
Reworked in 8e34a77.
| It is technically sufficient to set this on a single master-eligible node in | ||
| the cluster, and only to mention that single node in the setting, but this | ||
| provides no fault tolerance before the cluster has fully formed. It | ||
| is therefore better to bootstrap using at least three master-eligible nodes. |
There was a problem hiding this comment.
Ok done in 8e34a77.
| discovered before bootstrapping can take place. This requirement will be | ||
| relaxed in production-ready releases. | ||
|
|
||
| WARNING: You must put exactly the same set of initial master nodes in each |
There was a problem hiding this comment.
Ok, redundancy reduced in 8e34a77.
| The `cluster.name` allows you to create multiple clusters which are separated | ||
| from each other. Nodes verify that they agree on their cluster name when they | ||
| first connect to each other, and if two nodes have different cluster names then | ||
| they will not communicate meaningfully and will not belong to the same cluster. |
There was a problem hiding this comment.
Really we want to say the nodes don't communicate at all, but they do: they communicate their respective cluster names. After they discover the disagreement they don't really do any further communication.
Reworked in 8e34a77 to still be technically correct without being so awkwardly worded.
| @@ -0,0 +1,121 @@ | |||
| [[modules-discovery-adding-removing-nodes]] | |||
| === Adding and removing nodes | |||
|
|
|||
There was a problem hiding this comment.
There just isn't really a lot to say about adding nodes in this context. I added headings to divide the page up in e466ed0.
| has either discovered an elected master node or else it has discovered enough | ||
| masterless master-eligible nodes to complete an election. If neither of these | ||
| occur quickly enough then the node will retry after | ||
| `discovery.find_peers_interval` which defaults to `1s`. |
There was a problem hiding this comment.
Agreed, moved in ec4e739.
…iidoc Co-Authored-By: DaveCTurner <david.turner@elastic.co>
|
Thank you @lcawl for all the suggestions, they are greatly appreciated. I've held off on addressing any comments asking for more major structural changes here in the interests of time. For instance, I think it makes sense to collect many of the settings into one place, although that place does not yet exist. I think I've addressed everything else, and we can move some things around in follow-ups. |
The introduction of
zen2substantially changes how discovery and clusterformation work. This commit updates the reference documentation, migration
documentation, and various other locations to bring them in line with today's
reality.