Просмотр исходного кода

[DOCS] Synced with 8.0 stack upgrade changes (#83489) (#83596)

This moves the bulk of the upgrade information into the consolidated upgrade guide, but leaves the primary upgrade topic in place as a cross reference.

Relates to: https://github.com/elastic/stack-docs/pull/1970

Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: James Rodewig <40268737+jrodewig@users.noreply.github.com>
(cherry picked from commit f6473d71f9bf32e33103d0b4eb9465978c426868)

Co-authored-by: debadair <debadair@elastic.co>
James Rodewig 3 лет назад
Родитель
Сommit
2f03112b5b

+ 3 - 3
docs/reference/modules/discovery/quorums.asciidoc

@@ -56,11 +56,11 @@ election settings>>.
 ==== Cluster maintenance, rolling restarts and migrations
 
 Many cluster maintenance tasks involve temporarily shutting down one or more
-nodes and then starting them back up again. By default Elasticsearch can remain
+nodes and then starting them back up again. By default {es} can remain
 available if one of its master-eligible nodes is taken offline, such as during a
-<<rolling-upgrades,rolling restart>>. Furthermore, if multiple nodes are stopped
+rolling upgrade. Furthermore, if multiple nodes are stopped
 and then started again then it will automatically recover, such as during a
-<<restart-upgrade,full cluster restart>>. There is no need to take any further
+full cluster restart. There is no need to take any further
 action with the APIs described here in these cases, because the set of master
 nodes is not changing permanently.
 

+ 4 - 8
docs/reference/modules/remote-clusters.asciidoc

@@ -50,8 +50,7 @@ Sniff mode is the default connection mode.
 The _gateway nodes_ selection depends on the following criteria:
 
 * *version*: Remote nodes must be compatible with the cluster they are
-registered to, similar to the rules for
-<<rolling-upgrades,rolling upgrades>>:
+registered to:
 ** Any node can communicate with another node on the same
 major version. For example, 7.0 can talk to any 7.x node.
 ** Only nodes on the last minor version of a certain major version can
@@ -87,12 +86,9 @@ are opened to the proxy address. The proxy is required to route those
 connections to the remote cluster. Proxy mode does not require remote cluster
 nodes to have accessible publish addresses.
 
-The proxy mode is not the default connection mode and must be configured. Similar
-to the sniff <<gateway-nodes-selection,gateway nodes>>, the remote
-connections are subject to the same version compatibility rules as
-<<rolling-upgrades,rolling upgrades>>.
-
-Proxy mode has the same version compatibility requirements as sniff mode.
+The proxy mode is not the default connection mode and must be configured.
+Proxy mode has the same <<gateway-nodes-selection, version compatibility
+requirements>> as sniff mode. 
 
 [%collapsible]
 [[proxy-mode-version-compatibility]]

+ 17 - 2
docs/reference/redirects.asciidoc

@@ -354,8 +354,9 @@ See <<xpack-ccr,Cross-cluster replication>>.
 [role="exclude",id="indices-upgrade"]
 === Upgrade API
 
-The `_upgrade` API is no longer useful and will be removed. Instead, see
-<<reindex-upgrade>>.
+The `_upgrade` API is no longer useful and will be removed.
+For information about upgrading, see 
+{stack-ref}/upgrading-elasticsearch.html[Upgrading {es}].
 
 [role="exclude",id="mapping-parent-field"]
 === `_parent` field
@@ -1802,4 +1803,18 @@ See <<security-api-kibana-enrollment>>.
 See the <<sql-search-api-request-body,request body parameters>> for the
 <<sql-search-api,SQL search API>>.
 
+[role="exclude",id="restart-upgrade"]
+=== Full cluster restart upgrade
 
+When upgrading to {es} 8.0 and later, you must first upgrade to {prev-major-last}
+even if you opt to perform a full-cluster restart instead of a rolling upgrade.
+For more information about upgrading, see 
+{stack-ref}/upgrading-elastic-stack.html[Upgrading to Elastic {version}].
+
+role="exclude",id="rolling-upgrade"]
+=== Rolling upgrade
+
+When upgrading to {es} 8.0 and later, you must first upgrade to {prev-major-last}
+whether you opt to perform a rolling upgrade (upgrade one node at a time) or a full-cluster restart upgrade.
+For more information about upgrading, see 
+{stack-ref}/upgrading-elastic-stack.html[Upgrading to Elastic {version}].

+ 4 - 1
docs/reference/search/search-your-data/search-across-clusters.asciidoc

@@ -462,9 +462,12 @@ cluster as the local cluster when running a {ccs}.
 ==== {ccs-cap} during an upgrade
 
 You can still search a remote cluster while performing a
-<<rolling-upgrades,rolling upgrade>> on the local cluster. However, the local
+rolling upgrade on the local cluster. However, the local
 coordinating node's "upgrade from" and "upgrade to" version must be compatible
 with the remote cluster's gateway node.
 
 WARNING: Running multiple versions of {es} in the same cluster beyond the
 duration of an upgrade is not supported.
+
+For more information about upgrades, see
+{stack-ref}/upgrading-elasticsearch.html[Upgrading {es}].

+ 13 - 103
docs/reference/upgrade.asciidoc

@@ -1,111 +1,29 @@
 [[setup-upgrade]]
 = Upgrade {es}
 
-[partintro]
---
-ifeval::["{release-state}"!="released"]
-[[upgrade-pre-release]]
-IMPORTANT: This documentation is for a pre-release of {es} {minor-version}. 
-Upgrades from pre-release builds are not supported and
-could result in errors or data loss. 
-If you upgrade from a released version to a pre-release verion for testing, 
-discard the contents of the cluster when you are done.
-Do not attempt to upgrade to the final release. 
-endif::[]
+{es} clusters can usually be upgraded one node at a time so
+upgrading does not interrupt service. To upgrade to 8.0 or later, 
+**you must first upgrade to {prev-major-last}**, even if you opt to
+do a full-cluster restart instead of a rolling upgrade. 
 
-{es} can usually be upgraded using a <<rolling-upgrades,Rolling upgrade>>
-process so upgrading does not interrupt service. Rolling upgrades are supported:
+This enables you to use the **Upgrade Assistant** to identify and resolve issues,
+reindex indices created before 7.0, and then perform a rolling upgrade.
 
-// tag::rolling-upgrade-versions[]
-* Between minor versions of the same major version
-* From 5.6 to 6.8
-* From 6.8 to {prev-major-version}
-* From {prev-major-version} to {version}
-ifeval::[ "{bare_version}" != "{minor-version}.0" ]
-* From any version since {minor-version}.0 to {version}
-endif::[]
-// end::rolling-upgrade-versions[]
-
-[TIP]
-====
-For rolling upgrades between major versions, we recommend
-using the {kibana-ref}/upgrade-assistant.html[Kibana Upgrade Assistant].
-
-The upgrade assistant identifies deprecated settings in your cluster and guides
-you through the process of resolving issues, including reindexing.
-
-We also recommend checking your <<deprecation-logging,deprecation logs>> for any
-other functionality that may have changed.
-====
-
-[discrete]
-[[upgrade-paths]]
-=== Upgrade paths to {version}
-
-[cols="<1,3",options="header",]
-|====
-|Upgrade from   
-|Recommended upgrade path to {version}
-
-ifeval::[ "{bare_version}" != "{minor-version}.0" ]
-|A previous {minor-version} version (e.g., {minor-version}.0)
-|<<rolling-upgrades,Rolling upgrade>> to {version}
-endif::[]
-
-|{prev-major-version}
-|<<rolling-upgrades,Rolling upgrade>> to {version}
-
-|7.0–7.15
-a|
-. {ref-7x}/rolling-upgrades.html[Rolling upgrade] to 7.16
-. <<rolling-upgrades,Rolling upgrade>> to {version}
-
-|6.8
-a|
-. {ref-7x}/rolling-upgrades.html[Rolling upgrade] to 7.16
-. <<rolling-upgrades,Rolling upgrade>> to {version}
-
-|6.0–6.7
-a|
-
-. https://www.elastic.co/guide/en/elasticsearch/reference/6.8/rolling-upgrades.html[Rolling upgrade] to 6.8
-. {ref-7x}/rolling-upgrades.html[Rolling upgrade] to 7.16
-. <<rolling-upgrades,Rolling upgrade>> to {version}
-|====
-
-
-[WARNING]
-====
-The upgrade path from 6.8 to 7.0 is *not* supported (both full cluster restart and rolling upgrade).
-====
-
-To upgrade directly to {version} from 6.7 or earlier, you must shut down the
-cluster, install {version}, and restart. For more information, see
-<<restart-upgrade, Full cluster restart upgrade>>.
-
-[discrete]
-[[upgrade-downgrade]]
-=== Downgrades
-
-In-place downgrades to earlier versions are *not* supported. To downgrade to an
-earlier version, <<snapshots-restore-snapshot,restore a snapshot>> taken prior
-to the version upgrade.
+You must resolve all critical issues before proceeding with the upgrade.
 
+For upgrade instructions, see {stack-ref}/upgrading-elastic-stack.html[Upgrading to Elastic {version}].
 
 [discrete]
 [[upgrade-index-compatibility]]
 === Index compatibility
 
 {es} can read indices created in the previous major version. If you
-have indices created in 5.x or before, you must reindex or delete them
+have indices created in 6.x or earlier, you must reindex or delete them
 before upgrading to {version}. {es} nodes will fail to start if
-incompatible indices are present. Snapshots of 5.x or earlier indices cannot be
-restored to a 7.x cluster even if they were created by a 6.x cluster. For
-information about upgrading old indices, see <<reindex-upgrade, Reindex to upgrade>>.
-
-When upgrading to a new version of {es}, you need to upgrade each
-of the products in your Elastic Stack. For more information, see the
-{stack-ref}/upgrading-elastic-stack.html[Elastic Stack Installation and Upgrade Guide].
+incompatible indices are present. Snapshots of 6.x or earlier indices cannot be
+restored to a 8.x cluster even if they were created by a 7.x cluster. 
+The **Upgrade Assistant** in {prev-major-last} identifies any indices 
+that need to be reindexed or removed.
 
 [discrete]
 [[upgrade-rest-api-compatibility]]
@@ -121,12 +39,4 @@ See <<rest-api-compatibility>> for additional information.
 
 include::{xes-repo-dir}/security/fips-java17.asciidoc[]
 
---
-
-include::upgrade/rolling_upgrade.asciidoc[]
-
-include::upgrade/cluster_restart.asciidoc[]
-
-include::upgrade/reindex_upgrade.asciidoc[]
-
 include::upgrade/archived-settings.asciidoc[]