|
@@ -91,25 +91,20 @@ already have local shard copies.
|
|
|
+
|
|
|
--
|
|
|
When all nodes have joined the cluster and recovered their primary shards,
|
|
|
-reenable allocation.
|
|
|
+reenable allocation by restoring `cluster.routing.allocation.enable` to its
|
|
|
+default:
|
|
|
|
|
|
[source,js]
|
|
|
------------------------------------------------------
|
|
|
PUT _cluster/settings
|
|
|
{
|
|
|
- "transient": {
|
|
|
- "cluster.routing.allocation.enable": "all"
|
|
|
+ "persistent": {
|
|
|
+ "cluster.routing.allocation.enable": null
|
|
|
}
|
|
|
}
|
|
|
------------------------------------------------------
|
|
|
// CONSOLE
|
|
|
|
|
|
-NOTE: Because <<_precedence_of_settings, transient
|
|
|
-settings take precedence over persistent settings>>, this overrides the
|
|
|
-persistent setting used to disable shard allocation in the first step. If you
|
|
|
-don't explicitly reenable shard allocation after a full cluster restart, the
|
|
|
-persistent setting is used and shard allocation remains disabled.
|
|
|
-
|
|
|
Once allocation is reenabled, the cluster starts allocating replica shards to
|
|
|
the data nodes. At this point it is safe to resume indexing and searching,
|
|
|
but your cluster will recover more quickly if you can wait until all primary
|