Skip to content

Commit f2babe7

Browse files
authored
Round up shard allocation / recovery / relocation concepts (#109943) (#112292)
(cherry picked from commit 50bccf5)
1 parent 0c45cc7 commit f2babe7

File tree

8 files changed

+103
-22
lines changed

8 files changed

+103
-22
lines changed

docs/reference/cat/recovery.asciidoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ The cat recovery API returns information about shard recoveries, both
3939
ongoing and completed. It is a more compact view of the JSON
4040
<<indices-recovery,index recovery>> API.
4141

42-
include::{es-ref-dir}/indices/recovery.asciidoc[tag=shard-recovery-desc]
42+
include::{es-ref-dir}/modules/shard-recovery-desc.asciidoc[]
4343

4444

4545
[[cat-recovery-path-params]]

docs/reference/high-availability/cluster-design.asciidoc

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -246,7 +246,8 @@ accumulate into a noticeable performance penalty. An unreliable network may
246246
have frequent network partitions. {es} will automatically recover from a
247247
network partition as quickly as it can but your cluster may be partly
248248
unavailable during a partition and will need to spend time and resources to
249-
resynchronize any missing data and rebalance itself once the partition heals.
249+
<<shard-recovery,resynchronize any missing data>> and <<shards-rebalancing-settings,rebalance>>
250+
itself once the partition heals.
250251
Recovering from a failure may involve copying a large amount of data between
251252
nodes so the recovery time is often determined by the available bandwidth.
252253

docs/reference/indices/recovery.asciidoc

Lines changed: 2 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -35,21 +35,7 @@ index, or alias.
3535
Use the index recovery API to get information about ongoing and completed shard
3636
recoveries.
3737

38-
// tag::shard-recovery-desc[]
39-
Shard recovery is the process of initializing a shard copy, such as restoring a
40-
primary shard from a snapshot or syncing a replica shard from a primary shard.
41-
When a shard recovery completes, the recovered shard is available for search
42-
and indexing.
43-
44-
Recovery automatically occurs during the following processes:
45-
46-
* Node startup. This type of recovery is called a local store recovery.
47-
* Primary shard replication.
48-
* Relocation of a shard to a different node in the same cluster.
49-
* <<snapshots-restore-snapshot,Snapshot restore>> operation.
50-
* <<indices-clone-index,Clone>>, <<indices-shrink-index,shrink>>, or
51-
<<indices-split-index,split>> operation.
52-
// end::shard-recovery-desc[]
38+
include::{es-ref-dir}/modules/shard-recovery-desc.asciidoc[]
5339

5440
The index recovery API reports information about completed recoveries only for
5541
shard copies that currently exist in the cluster. It only reports the last
@@ -360,7 +346,7 @@ The API returns the following response:
360346
"index1" : {
361347
"shards" : [ {
362348
"id" : 0,
363-
"type" : "STORE",
349+
"type" : "EXISTING_STORE",
364350
"stage" : "DONE",
365351
"primary" : true,
366352
"start_time" : "2014-02-24T12:38:06.349",

docs/reference/modules/cluster.asciidoc

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,7 @@
11
[[modules-cluster]]
22
=== Cluster-level shard allocation and routing settings
33

4-
_Shard allocation_ is the process of allocating shards to nodes. This can
5-
happen during initial recovery, replica allocation, rebalancing, or
6-
when nodes are added or removed.
4+
include::{es-ref-dir}/modules/shard-allocation-desc.asciidoc[]
75

86
One of the main roles of the master is to decide which shards to allocate to
97
which nodes, and when to move shards between nodes in order to rebalance the
Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
Shard allocation is the process of assigning shard copies to nodes. This can
2+
happen during initial recovery, replica allocation, rebalancing, when nodes are added to or removed from the cluster, or when cluster or index settings that impact allocation are updated.
Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
[[shard-allocation-relocation-recovery]]
2+
=== Shard allocation, relocation, and recovery
3+
4+
Each <<documents-indices,index>> in Elasticsearch is divided into one or more <<scalability,shards>>.
5+
Each document in an index belongs to a single shard.
6+
7+
A cluster can contain multiple copies of a shard. Each shard has one distinguished shard copy called the _primary_, and zero or more non-primary copies called _replicas_. The primary shard copy serves as the main entry point for all indexing operations. The operations on the primary shard copy are then forwarded to its replicas.
8+
9+
Replicas maintain redundant copies of your data across the <<modules-node,nodes>> in your cluster, protecting against hardware failure and increasing capacity to serve read requests like searching or retrieving a document. If the primary shard copy fails, then a replica is promoted to primary and takes over the primary's responsibilities.
10+
11+
Over the course of normal operation, Elasticsearch allocates shard copies to nodes, relocates shard copies across nodes to balance the cluster or satisfy new allocation constraints, and recovers shards to initialize new copies. In this topic, you'll learn how these operations work and how you can control them.
12+
13+
TIP: To learn about optimizing the number and size of shards in your cluster, refer to <<size-your-shards,Size your shards>>. To learn about how read and write operations are replicated across shards and shard copies, refer to <<docs-replication,Reading and writing documents>>.
14+
15+
[[shard-allocation]]
16+
==== Shard allocation
17+
18+
include::{es-ref-dir}/modules/shard-allocation-desc.asciidoc[]
19+
20+
By default, the primary and replica shard copies for an index can be allocated to any node in the cluster, and may be relocated to rebalance the cluster.
21+
22+
===== Adjust shard allocation settings
23+
24+
You can control how shard copies are allocated using the following settings:
25+
26+
- <<modules-cluster,Cluster-level shard allocation settings>>: Use these settings to control how shard copies are allocated and balanced across the entire cluster. For example, you might want to allocate nodes availability zones, or prevent certain nodes from being used so you can perform maintenance.
27+
28+
- <<index-modules-allocation,Index-level shard allocation settings>>: Use these settings to control how the shard copies for a specific index are allocated. For example, you might want to allocate an index to a node in a specific data tier, or to an node with specific attributes.
29+
30+
===== Monitor shard allocation
31+
32+
If a shard copy is unassigned, it means that the shard copy is not allocated to any node in the cluster. This can happen if there are not enough nodes in the cluster to allocate the shard copy, or if the shard copy can't be allocated to any node that satisfies the shard allocation filtering rules. When a shard copy is unassigned, your cluster is considered unhealthy and returns a yellow or red cluster health status.
33+
34+
You can use the following APIs to monitor shard allocation:
35+
36+
- <<cluster-allocation-explain,Cluster allocation explain>>
37+
- <<cat-allocation,cat allocation>>
38+
- <<cluster-health,cluster health>>
39+
40+
<<red-yellow-cluster-status,Learn more about troubleshooting unassigned shard copies and recovering your cluster health>>.
41+
42+
[[shard-recovery]]
43+
==== Shard recovery
44+
45+
include::{es-ref-dir}/modules/shard-recovery-desc.asciidoc[]
46+
47+
===== Adjust shard recovery settings
48+
49+
To control how shards are recovered, for example the resources that can be used by recovery operations, and which indices should be prioritized for recovery, you can adjust the following settings:
50+
51+
- <<recovery,Index recovery settings>>
52+
- <<modules-cluster,Cluster-level shard allocation settings>>
53+
- <<index-modules-allocation,Index-level shard allocation settings>>, including <<delayed-allocation,delayed allocation>> and <<recovery-prioritization,index recovery prioritization>>
54+
55+
Shard recovery operations also respect general shard allocation settings.
56+
57+
===== Monitor shard recovery
58+
59+
You can use the following APIs to monitor shard allocation:
60+
61+
- View a list of in-progress and completed recoveries using the <<cat-recovery,cat recovery API>>
62+
- View detailed information about a specific recovery using the <<indices-recovery,index recovery API>>
63+
64+
[[shard-relocation]]
65+
==== Shard relocation
66+
67+
Shard relocation is the process of moving shard copies from one node to another. This can happen when a node joins or leaves the cluster, or when the cluster is rebalancing.
68+
69+
When a shard copy is relocated, it is created as a new shard copy on the target node. When the shard copy is fully allocated and recovered, the old shard copy is deleted. If the shard copy being relocated is a primary, then the new shard copy is marked as primary before the old shard copy is deleted.
70+
71+
===== Adjust shard relocation settings
72+
73+
You can control how and when shard copies are relocated. For example, you can adjust the rebalancing settings that control when shard copies are relocated to balance the cluster, or the high watermark for disk-based shard allocation that can trigger relocation. These settings are part of the <<modules-cluster,cluster-level shard allocation settings>>.
74+
75+
Shard relocation operations also respect shard allocation and recovery settings.
Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
Shard recovery is the process of initializing a shard copy, such as restoring a
2+
primary shard from a snapshot or creating a replica shard from a primary shard.
3+
When a shard recovery completes, the recovered shard is available for search
4+
and indexing.
5+
6+
Recovery automatically occurs during the following processes:
7+
8+
* When creating an index for the first time.
9+
* When a node rejoins the cluster and starts up any missing primary shard copies using the data that it holds in its data path.
10+
* Creation of new replica shard copies from the primary.
11+
* Relocation of a shard copy to a different node in the same cluster.
12+
* A <<snapshots-restore-snapshot,snapshot restore>> operation.
13+
* A <<indices-clone-index,clone>>, <<indices-shrink-index,shrink>>, or
14+
<<indices-split-index,split>> operation.
15+
16+
You can determine the cause of a shard recovery using the <<indices-recovery,recovery>> or <<cat-recovery,cat recovery>> APIs.

docs/reference/setup.asciidoc

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,6 @@ include::setup/configuration.asciidoc[]
3333

3434
include::setup/important-settings.asciidoc[]
3535

36-
3736
include::setup/secure-settings.asciidoc[]
3837

3938
include::settings/audit-settings.asciidoc[]
@@ -82,6 +81,8 @@ include::modules/indices/search-settings.asciidoc[]
8281

8382
include::settings/security-settings.asciidoc[]
8483

84+
include::modules/shard-ops.asciidoc[]
85+
8586
include::modules/indices/request_cache.asciidoc[]
8687

8788
include::settings/snapshot-settings.asciidoc[]
@@ -93,7 +94,9 @@ include::modules/threadpool.asciidoc[]
9394
include::settings/notification-settings.asciidoc[]
9495

9596
include::setup/advanced-configuration.asciidoc[]
97+
9698
include::setup/sysconfig.asciidoc[]
99+
97100
include::setup/bootstrap-checks.asciidoc[]
98101

99102
include::setup/bootstrap-checks-xes.asciidoc[]

0 commit comments

Comments
 (0)