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 About high availability configuration and Recovering a high availability configuration.
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. When rolling back an upgrade, you must use an upgrade package file with the .pkg extension. Hotpatch package files with the .hpkg extension are not supported.
ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg
A reboot is required after running the command. Rolling back does not affect the data partition, as migrations are not run on patch releases.
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 Command-line utilities.
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 Taking a snapshot.