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
If you are using {ls} and the {logstash-ref}/plugins-filters-elastic_integration.html[`logstash-filter-elastic_integration`] plugin to extend Elastic integrations, upgrade {ls} (or the `logstash-filter-elastic_integration` plugin specifically) _before_ you upgrade {kib}.
26
22
27
-
The {es}-{ls}-{kib} installation order for this specific plugin ensures the best experience with {agent}-managed pipelines, and embeds functionality from a version of {es} Ingest Node that is compatible with the plugin version (`major`.`minor`).
23
+
The {es} -> {ls} -> {kib} installation order for this specific plugin ensures the best experience with {agent}-managed pipelines, and embeds functionality from a version of {es} Ingest Node that is compatible with the plugin version (`major`.`minor`).
Copy file name to clipboardExpand all lines: docs/en/install-upgrade/upgrading-stack.asciidoc
+8-5Lines changed: 8 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,18 +76,18 @@ If you’re running the {stack} on your own self-managed infrastructure, you’l
76
76
77
77
Before you upgrade to {version}, it's important to take some preparation steps. Unless noted, these following recommendations are best practices regardless of deployment method.
78
78
79
-
IMPORTANT: Upgrading from a release candidate build, such as 9.0.0-rc1 or 9.0.0-rc2, is not supported. Pre-releases should only be used for testing in a temporary environment.
79
+
IMPORTANT: Upgrading from a release candidate build, such as 9.0.0-rc1, is not supported. Pre-releases should only be used for testing in a temporary environment.
80
80
81
81
To upgrade to {version} from 8.17 or earlier, **you must first upgrade to the latest patch version of 8.18**. This enables you to use the **Upgrade Assistant** to identify and resolve issues,
82
-
reindex indices created before 8.0, and then perform a rolling upgrade.
82
+
reindex indices created before 8.0 or mark them as read-only, and perform a rolling upgrade.
83
83
84
84
*Upgrading to 8.18 before upgrading to {version} is required
85
85
even if you opt to do a full-cluster restart of your {es} cluster.*
86
86
87
87
Alternatively, you can create a new {version} deployment and reindex from remote.
88
88
For more information, refer to <<upgrading-reindex,Reindex to upgrade>>.
89
89
90
-
{beats} and {ls} 8.17 are compatible with {es} {version}
90
+
{beats} and {ls} 8.18 are compatible with {es} {version}
91
91
to give you flexibility in scheduling the upgrade.
92
92
93
93
.Remote cluster compatibility
@@ -130,10 +130,13 @@ For more information, see {ref}/rest-api-compatibility.html[REST API compatibili
130
130
IMPORTANT: You cannot downgrade {es} nodes after upgrading. If you cannot complete the upgrade process, you will need to {ref}/snapshots-restore-snapshot.html[restore from the snapshot].
131
131
+
132
132
. If you use a separate {ref}/monitoring-production.html[monitoring cluster], you should upgrade the monitoring cluster before the production cluster. In general, the monitoring cluster and the clusters being monitored should be running the same version of the stack. A monitoring cluster cannot monitor production clusters running newer versions of the stack. If necessary, the monitoring cluster can monitor production clusters running the latest release of the previous major version.
133
+
. To reduce overhead on the cluster during the upgrade, close {ml} jobs. Although {ml} jobs can run during a rolling upgrade, doing so increases the cluster workload.
134
+
. If you have `.ml-anomalies-*` anomaly detection result indices created in Elasticsearch 7.x, reindex, mark as read-only, or delete them before you upgrade to {version}. For more information, refer to <<anomaly-detection-results-migration, Migrate anomaly detection results>>.
135
+
. If you have transform destination indices created in Elasticsearch 7.x, reset, reindex, or delete them before you upgrade to {version}. For more information, refer to <<breaking_90_transform_destination_index, Migrate transform destination indices>>.
133
136
134
137
[discrete]
135
138
[[anomaly-detection-results-migration]]
136
-
=== Anomaly detection results migration
139
+
=== Migrate anomaly detection results
137
140
138
141
The {anomaly-detect} result indices `.ml-anomalies-*` created in {es} 7.x must be either reindexed, marked read-only, or deleted before upgrading to 9.x.
139
142
@@ -464,7 +467,7 @@ The {transform} destination indices created in {es} 7.x must be either reset, re
464
467
465
468
**Reindexing**: You can reindex the destination index and then update the {transform} to write to the new destination index. This is useful if there are results that you want to retain that may not exist in the source index. To prevent the {transform} and reindex tasks from conflicting with one another, you can either pause the {transform} while the reindex runs, or you can write to the new destination index while the reindex backfills old results.
466
469
467
-
**Deleting**: You can delete any {transform} that are no longer being used. Once the {transform} is deleted, you can either delete the destination index or make it read-only.
470
+
**Deleting**: You can delete any {transforms} that are no longer being used. Once the {transform} is deleted, you can either delete the destination index or make it read-only.
0 commit comments