Skip to main content

Эта версия GitHub Enterprise Server была прекращена 2024-09-25. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Восстановление после неудачного обновления

Узнайте, как выполнить откат от неудачного обновления.

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. 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. 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."