From 90c2aae28b8a2a4a712d28014b1041b91830f196 Mon Sep 17 00:00:00 2001 From: Jason Tedor Date: Tue, 23 Aug 2016 14:31:58 -0400 Subject: [PATCH] Remove minimum master nodes bootstrap docs The minimum master nodes bootstrap check was removed in 069fc2269664c5b2a4a393c893825f982b55ccc7 but the docs were left behind. This commit removes these stale docs. Relates #20127 --- .../reference/setup/bootstrap-checks.asciidoc | 30 ------------------- 1 file changed, 30 deletions(-) diff --git a/docs/reference/setup/bootstrap-checks.asciidoc b/docs/reference/setup/bootstrap-checks.asciidoc index 1da61360033..47b51975ea5 100644 --- a/docs/reference/setup/bootstrap-checks.asciidoc +++ b/docs/reference/setup/bootstrap-checks.asciidoc @@ -74,36 +74,6 @@ have `memlock unlimited`). The memory lock check verifies that *if* the able to lock the heap. To pass the memory lock check, you might have to configure <>. -=== Minimum master nodes check - -Elasticsearch uses a single master for managing cluster state but -enables there to be multiple master-eligible nodes for -high-availability. In the case of a partition, master-eligible nodes on -each side of the partition might be elected as the acting master without -knowing that there is a master on the side of the partition. This can -lead to divergent cluster states potentially leading to data loss when -the partition is healed. This is the notion of a split brain and it is -the worst thing that can happen to an Elasticsearch cluster. But by -configuring -<> to be -equal to a quorum of master-eligible nodes, it is not possible for the -cluster to suffer from split brain because during a network partition -there can be at most one side of the partition that contains a quorum of -master nodes. The minimum master nodes check enforces that you've set -<>. To pass -the minimum master nodes check, you must configure -<>. - -NOTE: The minimum master nodes check does not enforce that you've -configured <> -correctly, only that you have it configured. Elasticsearch does log a -warning message if it detects that -<> is -incorrectly configured based on the number of master-eligible nodes -visible in the cluster state. Future versions of Elasticsearch will -contain stricter enforcement of -<>. - === Maximum number of threads check Elasticsearch executes requests by breaking the request down into stages