2013-08-29 07:24:34 +08:00
|
|
|
[[modules-gateway]]
|
2020-05-11 20:34:55 +08:00
|
|
|
=== Local gateway settings
|
2015-06-23 05:49:45 +08:00
|
|
|
|
2020-05-11 20:34:55 +08:00
|
|
|
The local gateway stores the cluster state and shard data across full
|
2015-06-23 05:49:45 +08:00
|
|
|
cluster restarts.
|
|
|
|
|
|
2017-09-05 16:42:58 +08:00
|
|
|
The following _static_ settings, which must be set on every master node,
|
|
|
|
|
control how long a freshly elected master should wait before it tries to
|
2020-09-02 03:48:45 +08:00
|
|
|
recover the cluster state and the cluster's data.
|
2015-06-23 05:49:45 +08:00
|
|
|
|
2020-09-02 03:48:45 +08:00
|
|
|
NOTE: These settings only take effect on a full cluster restart.
|
2015-06-23 05:49:45 +08:00
|
|
|
|
|
|
|
|
`gateway.expected_data_nodes`::
|
2020-09-02 03:48:45 +08:00
|
|
|
(<<static-cluster-setting,Static>>)
|
|
|
|
|
Number of data nodes expected in the cluster.
|
|
|
|
|
Recovery of local shards begins when the expected number of
|
|
|
|
|
data nodes join the cluster. Defaults to `0`.
|
2015-06-23 05:49:45 +08:00
|
|
|
|
|
|
|
|
`gateway.recover_after_time`::
|
2020-09-02 03:48:45 +08:00
|
|
|
(<<static-cluster-setting,Static>>)
|
|
|
|
|
If the expected number of nodes is not achieved, the recovery process waits
|
|
|
|
|
for the configured amount of time before trying to recover.
|
2021-02-03 22:10:45 +08:00
|
|
|
Defaults to `5m`.
|
2020-09-02 03:48:45 +08:00
|
|
|
+
|
2015-06-23 05:49:45 +08:00
|
|
|
Once the `recover_after_time` duration has timed out, recovery will start
|
2021-02-03 22:10:45 +08:00
|
|
|
as long as the following condition is met:
|
2015-06-23 05:49:45 +08:00
|
|
|
|
|
|
|
|
`gateway.recover_after_data_nodes`::
|
2020-09-02 03:48:45 +08:00
|
|
|
(<<static-cluster-setting,Static>>)
|
|
|
|
|
Recover as long as this many data nodes have joined the cluster.
|
2018-01-22 16:39:21 +08:00
|
|
|
|
2021-02-03 22:10:45 +08:00
|
|
|
These settings can be configured in `elasticsearch.yml` as follows:
|
|
|
|
|
|
|
|
|
|
[source,yaml]
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
gateway.expected_data_nodes: 3
|
|
|
|
|
gateway.recover_after_time: 600s
|
|
|
|
|
gateway.recover_after_data_nodes: 3
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
2020-05-11 20:34:55 +08:00
|
|
|
[[dangling-indices]]
|
|
|
|
|
==== Dangling indices
|
2018-01-22 16:39:21 +08:00
|
|
|
|
2020-07-17 22:17:58 +08:00
|
|
|
When a node joins the cluster, if it finds any shards stored in its local
|
|
|
|
|
data directory that do not already exist in the cluster, it will consider
|
|
|
|
|
those shards to belong to a "dangling" index. You can list, import or
|
|
|
|
|
delete dangling indices using the <<dangling-indices-api,Dangling indices
|
|
|
|
|
API>>.
|
|
|
|
|
|
|
|
|
|
NOTE: The API cannot offer any guarantees as to whether the imported data
|
|
|
|
|
truly represents the latest state of the data when the index was still part
|
|
|
|
|
of the cluster.
|
