discovery-settings.asciidoc 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248
  1. [[modules-discovery-settings]]
  2. === Discovery and cluster formation settings
  3. <<modules-discovery,Discovery and cluster formation>> are affected by the
  4. following settings:
  5. `discovery.seed_hosts`::
  6. +
  7. --
  8. Provides a list of the addresses of the master-eligible nodes in the cluster.
  9. May also be a single string containing the addresses separated by commas. Each
  10. address has the format `host:port` or `host`. The `host` is either a host name
  11. to be resolved by DNS, an IPv4 address, or an IPv6 address. IPv6 addresses
  12. must be enclosed in square brackets. If a host name resolves via DNS to multiple
  13. addresses, {es} uses all of them. DNS lookups are subject to
  14. <<networkaddress-cache-ttl,JVM DNS caching>>. If the `port` is not given then it
  15. is determined by checking the following settings in order:
  16. . `transport.profiles.default.port`
  17. . `transport.port`
  18. If neither of these is set then the default port is `9300`. The default value
  19. for `discovery.seed_hosts` is `["127.0.0.1", "[::1]"]`. See <<unicast.hosts>>.
  20. --
  21. `discovery.seed_providers`::
  22. Specifies which types of <<built-in-hosts-providers,seed hosts provider>>
  23. to use to obtain the addresses of the seed nodes used to start the
  24. discovery process. By default, it is the
  25. <<settings-based-hosts-provider,settings-based seed hosts provider>> which
  26. obtains the seed node addresses from the `discovery.seed_hosts` setting.
  27. `discovery.type`::
  28. Specifies whether {es} should form a multiple-node cluster. By default, {es}
  29. discovers other nodes when forming a cluster and allows other nodes to join
  30. the cluster later. If `discovery.type` is set to `single-node`, {es} forms
  31. a single-node cluster and suppresses the timeout set by
  32. `cluster.publish.timeout`. For more information about when you might use
  33. this setting, see <<single-node-discovery>>.
  34. `cluster.initial_master_nodes`::
  35. Sets the initial set of master-eligible nodes in a brand-new cluster. By
  36. default this list is empty, meaning that this node expects to join a cluster
  37. that has already been bootstrapped. See <<initial_master_nodes>>.
  38. [discrete]
  39. ==== Expert settings
  40. Discovery and cluster formation are also affected by the following
  41. _expert-level_ settings, although it is not recommended to change any of these
  42. from their default values.
  43. WARNING: If you adjust these settings then your cluster may not form correctly
  44. or may become unstable or intolerant of certain failures.
  45. `discovery.cluster_formation_warning_timeout`::
  46. Sets how long a node will try to form a cluster before logging a warning
  47. that the cluster did not form. Defaults to `10s`. If a cluster has not
  48. formed after `discovery.cluster_formation_warning_timeout` has elapsed then
  49. the node will log a warning message that starts with the phrase `master not
  50. discovered` which describes the current state of the discovery process.
  51. `discovery.find_peers_interval`::
  52. Sets how long a node will wait before attempting another discovery round.
  53. Defaults to `1s`.
  54. `discovery.probe.connect_timeout`::
  55. Sets how long to wait when attempting to connect to each address. Defaults
  56. to `3s`.
  57. `discovery.probe.handshake_timeout`::
  58. Sets how long to wait when attempting to identify the remote node via a
  59. handshake. Defaults to `1s`.
  60. `discovery.request_peers_timeout`::
  61. Sets how long a node will wait after asking its peers again before
  62. considering the request to have failed. Defaults to `3s`.
  63. `discovery.seed_resolver.max_concurrent_resolvers`::
  64. Specifies how many concurrent DNS lookups to perform when resolving the
  65. addresses of seed nodes. Defaults to `10`.
  66. `discovery.seed_resolver.timeout`::
  67. Specifies how long to wait for each DNS lookup performed when resolving the
  68. addresses of seed nodes. Defaults to `5s`.
  69. `cluster.auto_shrink_voting_configuration`::
  70. Controls whether the <<modules-discovery-voting,voting configuration>>
  71. sheds departed nodes automatically, as long as it still contains at least 3
  72. nodes. The default value is `true`. If set to `false`, the voting
  73. configuration never shrinks automatically and you must remove departed
  74. nodes manually with the <<voting-config-exclusions,voting configuration
  75. exclusions API>>.
  76. [[master-election-settings]]`cluster.election.back_off_time`::
  77. Sets the amount to increase the upper bound on the wait before an election
  78. on each election failure. Note that this is _linear_ backoff. This defaults
  79. to `100ms`. Changing this setting from the default may cause your cluster
  80. to fail to elect a master node.
  81. `cluster.election.duration`::
  82. Sets how long each election is allowed to take before a node considers it
  83. to have failed and schedules a retry. This defaults to `500ms`. Changing
  84. this setting from the default may cause your cluster to fail to elect a
  85. master node.
  86. `cluster.election.initial_timeout`::
  87. Sets the upper bound on how long a node will wait initially, or after the
  88. elected master fails, before attempting its first election. This defaults
  89. to `100ms`. Changing this setting from the default may cause your cluster
  90. to fail to elect a master node.
  91. `cluster.election.max_timeout`::
  92. Sets the maximum upper bound on how long a node will wait before attempting
  93. an first election, so that an network partition that lasts for a long time
  94. does not result in excessively sparse elections. This defaults to `10s`.
  95. Changing this setting from the default may cause your cluster to fail to
  96. elect a master node.
  97. [[fault-detection-settings]]`cluster.fault_detection.follower_check.interval`::
  98. Sets how long the elected master waits between follower checks to each
  99. other node in the cluster. Defaults to `1s`. Changing this setting from the
  100. default may cause your cluster to become unstable.
  101. `cluster.fault_detection.follower_check.timeout`::
  102. Sets how long the elected master waits for a response to a follower check
  103. before considering it to have failed. Defaults to `10s`. Changing this
  104. setting from the default may cause your cluster to become unstable.
  105. `cluster.fault_detection.follower_check.retry_count`::
  106. Sets how many consecutive follower check failures must occur to each node
  107. before the elected master considers that node to be faulty and removes it
  108. from the cluster. Defaults to `3`. Changing this setting from the default
  109. may cause your cluster to become unstable.
  110. `cluster.fault_detection.leader_check.interval`::
  111. Sets how long each node waits between checks of the elected master.
  112. Defaults to `1s`. Changing this setting from the default may cause your
  113. cluster to become unstable.
  114. `cluster.fault_detection.leader_check.timeout`::
  115. Sets how long each node waits for a response to a leader check from the
  116. elected master before considering it to have failed. Defaults to `10s`.
  117. Changing this setting from the default may cause your cluster to become
  118. unstable.
  119. `cluster.fault_detection.leader_check.retry_count`::
  120. Sets how many consecutive leader check failures must occur before a node
  121. considers the elected master to be faulty and attempts to find or elect a
  122. new master. Defaults to `3`. Changing this setting from the default may
  123. cause your cluster to become unstable.
  124. `cluster.follower_lag.timeout`::
  125. Sets how long the master node waits to receive acknowledgements for cluster
  126. state updates from lagging nodes. The default value is `90s`. If a node
  127. does not successfully apply the cluster state update within this period of
  128. time, it is considered to have failed and is removed from the cluster. See
  129. <<cluster-state-publishing>>.
  130. `cluster.max_voting_config_exclusions`::
  131. Sets a limit on the number of voting configuration exclusions at any one
  132. time. The default value is `10`. See
  133. <<modules-discovery-adding-removing-nodes>>.
  134. `cluster.publish.info_timeout`::
  135. Sets how long the master node waits for each cluster state update to be
  136. completely published to all nodes before logging a message indicating that
  137. some nodes are responding slowly. The default value is `10s`.
  138. `cluster.publish.timeout`::
  139. Sets how long the master node waits for each cluster state update to be
  140. completely published to all nodes, unless `discovery.type` is set to
  141. `single-node`. The default value is `30s`. See <<cluster-state-publishing>>.
  142. [[no-master-block]]`cluster.no_master_block`::
  143. Specifies which operations are rejected when there is no active master in a
  144. cluster. This setting has three valid values:
  145. +
  146. --
  147. `all`::: All operations on the node (both read and write operations) are rejected.
  148. This also applies for API cluster state read or write operations, like the get
  149. index settings, put mapping and cluster state API.
  150. `write`::: (default) Write operations are rejected. Read operations succeed,
  151. based on the last known cluster configuration. This situation may result in
  152. partial reads of stale data as this node may be isolated from the rest of the
  153. cluster.
  154. `metadata_write`::: Only metadata write operations (e.g. mapping updates,
  155. routing table changes) are rejected but regular indexing operations continue
  156. to work. Read and write operations succeed, based on the last known cluster
  157. configuration. This situation may result in partial reads of stale data as
  158. this node may be isolated from the rest of the cluster.
  159. [NOTE]
  160. ===============================
  161. * The `cluster.no_master_block` setting doesn't apply to nodes-based APIs
  162. (for example, cluster stats, node info, and node stats APIs). Requests to these
  163. APIs are not be blocked and can run on any available node.
  164. * For the cluster to be fully operational, it must have an active master.
  165. ===============================
  166. --
  167. `monitor.fs.health.enabled`::
  168. (<<cluster-update-settings,Dynamic>>, boolean) If `true`, the node runs
  169. periodic <<cluster-fault-detection-filesystem-health,filesystem health
  170. checks>>. Defaults to `true`.
  171. `monitor.fs.health.refresh_interval`::
  172. (<<time-units, Time value>>) Interval between successive
  173. <<cluster-fault-detection-filesystem-health,filesystem health checks>>.
  174. Defaults to `2m`.
  175. `monitor.fs.health.slow_path_logging_threshold`::
  176. (<<time-units, Time value>>) If a
  177. <<cluster-fault-detection-filesystem-health,filesystem health checks>>
  178. takes longer than this threshold then {es} logs a warning. Defaults to
  179. `5s`.