2.0 KiB
title, intro, redirect_from, versions, type, topics, shortTitle
| title | intro | redirect_from | versions | type | topics | shortTitle | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Restoring from a failed upgrade | Learn how to roll back from a failed upgrade. |
|
|
how_to |
|
Restore from a failed upgrade |
If an upgrade fails or is interrupted, you should revert your instance back to its previous state. The process for completing this depends on the type of upgrade.
If your instance is configured for high availability and your primary node upgrade fails, you can promote the (not upgraded) replica to be the primary. You will also need to update your DNS to point to the new primary node. Once you have a working primary node, you can then consider creating a new replica node. See AUTOTITLE and AUTOTITLE.
Rolling back a patch release
To roll back a patch release, use the ghe-upgrade command with the --allow-patch-rollback switch. Before rolling back, replication must be temporarily stopped by running ghe-repl-stop on all replica nodes, or ghe-repl-stop-all on the primary node. {% data reusables.enterprise_installation.command-line-utilities-ghe-upgrade-rollback %}
After the rollback is complete, restart replication by running ghe-repl-start on all nodes, or ghe-repl-start-all on the primary node. See AUTOTITLE.
Rolling back a feature release
To roll back from a feature release, restore from a virtual machine snapshot to ensure that root and data partitions are in a consistent state. See AUTOTITLE.