You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/troubleshooting/common-issues/red-yellow-cluster-status.asciidoc
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,12 +2,12 @@
2
2
=== Red or yellow cluster health status
3
3
4
4
A red or yellow cluster health status indicates one or more shards are not assigned to
5
-
a node.
5
+
a node.
6
6
7
7
* **Red health status**: The cluster has some unassigned primary shards, which
8
-
means that some operations such as searches and indexing may fail.
9
-
* **Yellow health status**: The cluster has no unassigned primary shards but some
10
-
unassigned replica shards. This increases your risk of data loss and can degrade
8
+
means that some operations such as searches and indexing may fail.
9
+
* **Yellow health status**: The cluster has no unassigned primary shards but some
10
+
unassigned replica shards. This increases your risk of data loss and can degrade
11
11
cluster performance.
12
12
13
13
When your cluster has a red or yellow health status, it will continue to process
@@ -16,8 +16,8 @@ cleanup activities until the cluster returns to green health status. For instanc
16
16
some <<index-lifecycle-management,{ilm-init}>> actions require the index on which they
17
17
operate to have a green health status.
18
18
19
-
In many cases, your cluster will recover to green health status automatically.
20
-
If the cluster doesn't automatically recover, then you must <<fix-red-yellow-cluster-status,manually address>>
19
+
In many cases, your cluster will recover to green health status automatically.
20
+
If the cluster doesn't automatically recover, then you must <<fix-red-yellow-cluster-status,manually address>>
21
21
the remaining problems so management and cleanup activities can proceed.
22
22
23
23
[discrete]
@@ -107,7 +107,7 @@ asynchronously in the background.
107
107
108
108
[source,console]
109
109
----
110
-
POST _cluster/reroute?metric=none
110
+
POST _cluster/reroute
111
111
----
112
112
113
113
[discrete]
@@ -231,10 +231,10 @@ unassigned. See <<high-jvm-memory-pressure>>.
231
231
232
232
If a node containing a primary shard is lost, {es} can typically replace it
233
233
using a replica on another node. If you can't recover the node and replicas
234
-
don't exist or are irrecoverable, <<cluster-allocation-explain,Allocation
235
-
Explain>> will report `no_valid_shard_copy` and you'll need to do one of the following:
234
+
don't exist or are irrecoverable, <<cluster-allocation-explain,Allocation
235
+
Explain>> will report `no_valid_shard_copy` and you'll need to do one of the following:
236
236
237
-
* restore the missing data from <<snapshot-restore,snapshot>>
237
+
* restore the missing data from <<snapshot-restore,snapshot>>
238
238
* index the missing data from its original data source
239
239
* accept data loss on the index-level by running <<indices-delete-index,Delete Index>>
240
240
* accept data loss on the shard-level by executing <<cluster-reroute,Cluster Reroute>> allocate_stale_primary or allocate_empty_primary command with `accept_data_loss: true`
0 commit comments