mirror of
https://github.com/elastic/kibana.git
synced 2025-06-28 11:05:39 -04:00
94caafd57d
## Summary This PR: - adds a page that is a compiled list of all breaking changes and deprecations introduced since the last major version. I slightly edited some bits to align the wording and add version information to each item, and took a bit of freedom (not too much!) to ignore items that shouldn't be identified as deprecations or breaking changes, or to move them to the appropriate section in this page. - adds a link to the new page from the Upgrade Kibana page. <img width="1483" alt="image" src="https://github.com/user-attachments/assets/16109072-d5c6-4eb4-8a52-ef209a07072a"> <img width="810" alt="image" src="https://github.com/user-attachments/assets/939e9212-b750-4a6f-bd8f-f8df04e46d76"> I'm wondering if we should leave this uncategorized or at least identify which items are specific to a solution. It also doesn't make much sense that we have Obs here while we don't have Security. Let's think about a consistent way to do it. Note: In this PR, the page is initially added under the Release notes section. I'll need to make sure that this does not interfere with the release notes automation. Note 2: If we move forward with this proposal, we'll need update the release notes internal docs to add the relevant information to this page with each minor release, or find a way to automate. Closes: https://github.com/elastic/kibana-team/issues/1075 --------- Co-authored-by: Lisa Cawley <lcawley@elastic.co> Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co> Co-authored-by: Luke Elmers <lukeelmers@gmail.com>
78 lines
3.8 KiB
Text
78 lines
3.8 KiB
Text
[[upgrade]]
|
|
== Upgrade {kib}
|
|
|
|
To upgrade from 7.16.0 or earlier to {version},
|
|
**you must first upgrade to {prev-major-last}**, which enables you to use the *Upgrade Assistant* to
|
|
{stack-ref}/upgrading-elastic-stack.html#prepare-to-upgrade[prepare for the upgrade].
|
|
Before you upgrade, you must resolve all critical issues identified by the *Upgrade Assistant*.
|
|
|
|
In addition, we recommend to carefully review the <<breaking-changes-summary,list of breaking changes and deprecations>> and to take any necessary actions to mitigate their impact on the upgrade.
|
|
|
|
Rolling upgrades are unsupported in {kib}. To upgrade,
|
|
you must shut down all {kib} instances, install the new software, and restart {kib}.
|
|
Upgrading while older {kib} instances are running can cause data loss or upgrade failures.
|
|
|
|
[WARNING]
|
|
====
|
|
When required, {kib} automatically migrates <<saved-object-migrations, saved objects>>.
|
|
In case of an upgrade failure, you can roll back to an
|
|
earlier version of {kib}. To roll back, you **must** have a
|
|
{ref}/snapshot-restore.html[backup snapshot] that includes the `kibana` feature
|
|
state. By default, snapshots include the `kibana` feature state.
|
|
====
|
|
|
|
For more information about upgrading,
|
|
refer to {stack-ref}/upgrading-elastic-stack.html[Upgrading to Elastic {version}.]
|
|
|
|
IMPORTANT: You can upgrade to pre-release versions for testing,
|
|
but upgrading from a pre-release to the General Available version is unsupported.
|
|
You should use pre-release versions only for testing in a temporary environment.
|
|
|
|
[float]
|
|
=== Upgrading multiple {kib} instances
|
|
When upgrading several {kib} instances connected to the same {es} cluster,
|
|
ensure that all outdated instances are shut down before starting the upgrade.
|
|
|
|
Rolling upgrades are unsupported in {kib}. However, when outdated instances are shut down, you can start all upgraded instances in parallel,
|
|
which allows all instances to participate in the upgrade migration in parallel.
|
|
|
|
For large deployments with more than 10 {kib} instances, and more than 10,000 saved objects,
|
|
you can reduce the upgrade downtime by bringing up a single {kib} instance and waiting for it to
|
|
complete the upgrade migration before bringing up the remaining instances.
|
|
|
|
[float]
|
|
[[preventing-migration-failures]]
|
|
=== Preparing for migration
|
|
|
|
Take these extra steps to ensure you are ready for migration.
|
|
|
|
[float]
|
|
==== Ensure your {es} cluster is healthy
|
|
Problems with your {es} cluster can prevent {kib} upgrades from succeeding.
|
|
|
|
During the upgrade process, {kib} creates new indices into which updated documents are written. If a cluster is approaching the low watermark, there's a high risk of {kib} not being able to create these. Reading, transforming and writing updated documents can be memory intensive, using more available heap than during routine operation. You must make sure that enough heap is available to prevent requests from timing out or throwing errors from circuit breaker exceptions. You should also ensure that all shards are replicated and assigned.
|
|
|
|
A healthy cluster has:
|
|
|
|
* Enough free disk space, at least twice the amount of storage taken up by the `.kibana` and `.kibana_task_manager` indices
|
|
* Sufficient heap size
|
|
* A "green" cluster status
|
|
|
|
[float]
|
|
==== Ensure that all {kib} instances are the same
|
|
When you perform an upgrade migration of different {kib} versions, the migration can fail.
|
|
Ensure that all {kib} instances are running the same version, configuration, and plugins.
|
|
|
|
[float]
|
|
==== Back up your data
|
|
Be sure to have a {ref}/snapshot-restore.html[snapshot] of all your data before attempting a migration.
|
|
If something goes wrong during migration, you can restore from the snapshot and try again.
|
|
|
|
Review the <<resolve-migrations-failures,common causes of {kib} upgrade failures>> and how to prevent them.
|
|
|
|
|
|
include::upgrade/saved-objects-migration.asciidoc[]
|
|
|
|
include::upgrade/resolving-migration-failures.asciidoc[]
|
|
|
|
include::upgrade/rollback-migration.asciidoc[]
|