upstream/vault
1
0
Fork 0
mirror of https://github.com/hashicorp/vault.git synced 2026-02-03 20:40:45 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 11

Fixing link to pre-autopilot HA upgrade documentation (#30539)

Browse source 
* update link to versioned documentation

* Remove duplicate sections

* Update website/content/docs/upgrade/replicated-deployment.mdx

---------

Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
This commit is contained in:
kevin-loehfelm 2025-07-16 20:16:22 -04:00 committed by GitHub
parent cde500aca9
commit ce9c011706
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 13 additions and 62 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

75
website/content/docs/upgrade/replicated-deployment.mdx
View file

@ -18,13 +18,19 @@ upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades)
Enterprise](/vault/tutorials/raft/raft-upgrade-automation)
tutorial for more details.
If you're currently on a version of Vault before 1.11, or you've chosen to
opt-out the Autopilot automated upgrade features when running Vault after 1.11
with Integrated Storage, or if you are running Vault with another storage backend,
such as Consul. Please refer to our [Vault HA upgrades Pre 1.11/Without
Autopilot Upgrade Automation](/vault/docs/upgrade/vault-ha-upgrade)
documentation for more details. Please note that this upgrade procedure also
applies if you are upgrading Vault from pre 1.11 to post 1.11.
<Note>
If you:
- run Vault v1.10.x or earlier
- opt-out of the Autopilot automated upgrade features when running Vault v1.11.x or later with integrated storage
- run Vault with external backend storage
Refer to our HA upgrade guide for
[Pre-1.11 Vault deployments or deployments without autopilot upgrade automation](/vault/docs/v1.13.x/upgrading/vault-ha-upgrade).
The pre-1.11 upgrade procedure also applies when upgrading Vault from pre 1.11 to post 1.11.
</Note>
## Enterprise replication installations
@ -100,58 +106,3 @@ party resources (cloud credentials, database credentials, etc.) ensure that you
do not allow external network connectivity during testing, in case credentials
expire. This prevents the test cluster from trying to revoke these resources
along with the non-test cluster.
## HA installations
The recommended upgrade procedure depends on the version of Vault you're currently on and the storage backend of Vault. If you're currently running on Vault 1.11 or later with Integrated Storage and you have Autopilot enabled, you should let Autopilot do the upgrade for you, as that's easier and
less prone to human error. Please refer to our [automated
upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) documentation for information on this feature and our
[Automate Upgrades with Vault
Enterprise](/vault/tutorials/raft/raft-upgrade-automation)
tutorial for more details.
If you're currently on a version of Vault before 1.11, or you've chosen to opt-out the Autopilot automated upgrade features when running Vault after 1.11 with Integrated Storage, or if you are running Vault with other storage backend such as Consul. Please refer to our [Vault HA upgrades Pre 1.11/Without Autopilot Upgrade Automation](/vault/docs/upgrading/vault-ha-upgrade) documentation for more details. Please note that this upgrade procedure also applies if you are upgrading Vault from pre 1.11 to post 1.11.
## Enterprise replication installations
<Note>
Prior to any upgrade, be sure to also read and follow any instructions in the
version-specific upgrade notes which are found in the navigation menu for this
documentation.
</Note>
Upgrading Vault Enterprise clusters which participate in [Enterprise
Replication](/vault/docs/enterprise/replication) requires the following basic
order of operations:
- **Upgrade the replication secondary instances first** using appropriate
guidance from the previous sections
- Verify functionality of each secondary instance after upgrading
- When satisfied with functionality of upgraded secondary instances, upgrade
the primary instance
<Note>
It is not safe to replicate from a newer version of Vault to an older version.
When upgrading replicated clusters, ensure that upstream clusters are always on
older versions of Vault than downstream clusters.
</Note>
Here is an example of upgrading four Vault replicated Vault clusters:
![Upgrading multiple replicated clusters](/img/vault-replication-upgrade.png)
In the above scenario, the ideal upgrade procedure would be as follows,
verifying functionality after each cluster upgrade.
1. Upgrade Clusters B and D. These clusters have no downstream clusters, so they
should be upgraded first, but the ordering of B vs D does not matter.
2. Upgrade Cluster C, which now has an upgraded downstream cluster (Cluster D).
Because Cluster C is a cluster, it should also use the HA upgrade process.
3. Finally, upgrade Cluster A. All clusters downstream of A will already be
upgraded. It should be upgraded last, as it is a Performance Primary and a DR
Primary.