-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add voting-only master node #43410
Add voting-only master node #43410
Changes from 26 commits
0567b49
7dd80ce
c298508
0d3750d
ee52a89
1a50872
2cb2010
8383823
9ee9fdc
77c252f
9de65ea
03d249f
b170c9d
c11b2e6
d109686
e410121
88f081d
5e260d5
65fda75
1b30c71
fbba2c3
e7c325e
1caa1b6
6907d06
e284426
bcd6ec2
264e5a3
d8a0b9a
ccdb483
28efcf0
7bb6fa2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -134,6 +134,37 @@ cluster.remote.connect: false <4> | |
<3> Disable the `node.ingest` role (enabled by default). | ||
<4> Disable {ccs} (enabled by default). | ||
|
||
[float] | ||
[[voting-only-node]] | ||
==== Voting-only master-eligible node | ||
|
||
A voting-only master-eligible node is a node that can participate in master | ||
elections but will not act as a master in the cluster. In particular, a | ||
voting-only node can help elect another master-eligible node as master, and | ||
can serve as a tiebreaker in elections. To mark a master-eligible node as | ||
voting-only, set: | ||
|
||
[source,yaml] | ||
------------------- | ||
node.voting_only: true <1> | ||
------------------- | ||
<1> The `node.voting_only` role is disabled by default. | ||
|
||
IMPORTANT: If you use the {oss-dist}, do not set `node.voting_only`. Otherwise, | ||
the node fails to start. Also note that only master-eligible nodes can be | ||
marked as voting-only. | ||
|
||
High availability (HA) clusters require at least three master-eligible nodes, | ||
so that if one of the three nodes is down, then the remaining two can still | ||
elect a master amongst them-selves. This only requires one of the two remaining | ||
nodes to have the capability to act as master, but both need to have voting | ||
powers. This means that one of the three master-eligible nodes can be made as | ||
voting-only. If this voting-only node is a dedicated master, a less powerful | ||
machine or a smaller heap-size can be chosen for this node. Alternatively, | ||
a voting-only non-dedicated master node can play the role of the third | ||
master-eligible node, which allows running an HA cluster with only two | ||
dedicated master nodes. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should make it clearer that voting-only nodes still need a fast disk and a low-latency connection to the true masters in order to be effective, and will use the same amount of disk space as any other dedicated master node. They should need less CPU and less heap. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've tried to address this in ccdb483. Let me know if that's ok, or perhaps suggest an alternative wording. |
||
|
||
[float] | ||
[[data-node]] | ||
=== Data Node | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the docs should clearly delineate that
voting_only
requires x-pack, we can wrap it in conditionals and add x-pack annotations so that it doesn't show in the docs if someone builds the OSS-only docs, and has x-pack designations in the docs when the full docs are published.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know that OSS-only docs were even a thing. Are we publishing those somewhere? How do you build those? You will have to spell out the details on how to set up the conditionals, I'm not aware of any such infrastructure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we do have
[x-pack]
macros, I'm not aware of an OSS-only docs build functionality.@debadair @lcawl Are you aware of an OSS-only docs build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don’t build them but it’s available for users that want to build OSS-only docs.
@lcawl Can you help @ywelsch add the appropriate x-pack annotations here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Content that requires the default distribution should be tagged with the [role="xpack"] directive. Now that all of the doc source is in the public repo we no longer maintain two versions of the index.asciidoc file, so conditional statements based on the
include_xpack
attribute have no effect.Inline references like this are tricky. If using the
voting_only
attribute throws an error in the OSS distro, I'd be inclined to add a note to that effect. Something like:@lcawl can correct me if I'm wrong, but I don't think there's (currently) any way to attach the xpack bug to an admonition block.