Upgrading GitHub Enterprise Server

Preparing to upgrade

1. Determine an upgrade strategy and choose a version to upgrade to. For more information, see "Upgrade requirements" and refer to the 升级助手 to find the upgrade path from your current release version.

2. Create a fresh backup of your primary instance with the GitHub Enterprise Server Backup Utilities. For more information, see the README.md file in the GitHub Enterprise Server Backup Utilities project documentation.

   Note: Your GitHub Enterprise Server Backup Utilities version needs to be the same version as, or at most two versions ahead of, your GitHub Enterprise Server instance. For more information, see "Upgrading GitHub Enterprise Server Backup Utilities."

3. If your GitHub Enterprise Server instance uses ephemeral self-hosted runners for GitHub Actions and you've disabled automatic updates, upgrade your runners to the version of the runner application that your upgraded instance will run.

4. If you are upgrading using an upgrade package, schedule a maintenance window for GitHub Enterprise Server end users. If you are using a hotpatch, maintenance mode is not required.

   Note: The maintenance window depends on the type of upgrade you perform. Upgrades using a hotpatch usually don't require a maintenance window. Sometimes a reboot is required, which you can perform at a later time. Following the versioning scheme of MAJOR.FEATURE.PATCH, patch releases using an upgrade package typically require less than five minutes of downtime. Feature releases that include data migrations take longer depending on storage performance and the amount of data that's migrated. For more information, see "Enabling and scheduling maintenance mode."

Taking a snapshot

A snapshot is a checkpoint of a virtual machine (VM) at a point in time. We highly recommend taking a snapshot before upgrading your virtual machine so that if an upgrade fails, you can revert your VM back to the snapshot. We only recommend taking a VM snapshot when the appliance is powered down or in maintenance mode and all background jobs have finished.

If you're upgrading to a new feature release, you must take a VM snapshot. If you're upgrading to a patch release, you can attach the existing data disk.

There are two types of snapshots:

• VM snapshots save your entire VM state, including user data and configuration data. This snapshot method requires a large amount of disk space and is time consuming.

• Data disk snapshots only save your user data.

  Notes:

  • Some platforms don't allow you to take a snapshot of just your data disk. For these platforms, you'll need to take a snapshot of the entire VM.
  • If your hypervisor does not support full VM snapshots, you should take a snapshot of the root disk and data disk in quick succession.

Platform	Snapshot method	Snapshot documentation URL
Amazon AWS	Disk	https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Azure	VM	https://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-V	VM	https://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute Engine	Disk	https://cloud.google.com/compute/docs/disks/create-snapshots
VMware	VM	https://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch11_VM_Manage.13.3.html
XenServer	VM	https://docs.citrix.com/en-us/xencenter/current-release/vms-snapshots.html

Upgrading with a hotpatch

You can upgrade GitHub Enterprise Server to the latest patch release using a hotpatch.

You can use hotpatching to upgrade to a newer patch release, but not a feature release. For example, you can upgrade from 2.10.1 to 2.10.5 because they are in the same feature series, but not from 2.10.9 to 2.11.0 because they are in a different feature series.

Hotpatches do not generally require a reboot. If a hotpatch does require a reboot, the GitHub Enterprise Server release notes will indicate the requirement.

Hotpatches require a configuration run, which can cause a brief period of errors or unresponsiveness for some or all services on your GitHub Enterprise Server instance. You are not required to enable maintenance mode during installation of a hotpatch, but doing so will guarantee that users see a maintenance page instead of errors or timeouts. For more information, see "Enabling and scheduling maintenance mode."

Using the 管理控制台, you can install a hotpatch immediately or schedule it for later installation. You can use the administrative shell to install a hotpatch with the ghe-upgrade utility. For more information, see "Upgrade requirements."

Upgrading a single appliance with a hotpatch

Installing a hotpatch using the 管理控制台

You can use the 管理控制台 to upgrade with a hotpatch by enabling automatic updates. You will then be presented with the latest available version of GitHub Enterprise Server that you can upgrade to.

If the upgrade target you're presented with is a feature release instead of a patch release, you cannot use the 管理控制台 to install a hotpatch. You must install the hotpatch using the administrative shell instead. For more information, see "Installing a hotpatch using the administrative shell."

1. Enable automatic updates. For more information, see "Enabling automatic updates."

2. 从 GitHub Enterprise Server 上的管理帐户任意页面的右上角，单击 。

   

3. 如果� 尚未在“站点管理员”页上，请在左上角单击“站点管理员”。

   

4. 在左侧边� �中，单击“管理控制台”。

5. 在 管理控制台 顶部，单击“更新”。

6. When a new hotpatch has been downloaded, use the Install package drop-down menu:

   • To install immediately, select Now:
   • To install later, select a later date.

7. Click Install.

Installing a hotpatch using the administrative shell

1. SSH into your GitHub Enterprise Server instance. If your instance comprises multiple nodes, for example if high availability or geo-replication are configured, SSH into the primary node. If you use a cluster, you can SSH into any node. For more information about SSH access, see "Accessing the administrative shell (SSH)."

   $ ssh -p 122 admin@HOSTNAME

2. 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边，单击“下载”，然后单击“升级”选项卡 。 Copy the URL for the upgrade hotpackage (.hpkg file).

3. Download the upgrade package to your GitHub Enterprise Server instance using curl :

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. Run the ghe-upgrade command using the package file name:

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
   *** verifying upgrade package signature...

5. If a reboot is required for updates for kernel, MySQL, Elasticsearch or other programs, the hotpatch upgrade script notifies you.

Upgrading an appliance that has replica instances using a hotpatch

Appliances configured for high-availability and geo-replication use replica instances in addition to primary instances. To upgrade these appliances, you'll need to upgrade both the primary instance and all replica instances, one at a time.

Upgrading the primary instance

1. Upgrade the primary instance by following the instructions in "Installing a hotpatch using the administrative shell."

Upgrading a replica instance

1. Upgrade the replica instance by following the instructions in "Installing a hotpatch using the administrative shell." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。

   $ ssh -p 122 admin@replica-host

3. 运行以下命令来验证升级：

   $ ghe-version

Upgrading with an upgrade package

While you can use a hotpatch to upgrade to the latest patch release within a feature series, you must use an upgrade package to upgrade to a newer feature release. For example to upgrade from 2.11.10 to 2.12.4 you must use an upgrade package since these are in different feature series. For more information, see "Upgrade requirements."

Upgrading a single appliance with an upgrade package

1. SSH into your GitHub Enterprise Server instance. If your instance comprises multiple nodes, for example if high availability or geo-replication are configured, SSH into the primary node. If you use a cluster, you can SSH into any node. For more information about SSH access, see "Accessing the administrative shell (SSH)."

   $ ssh -p 122 admin@HOSTNAME

2. 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边，单击“下载”，然后单击“升级”选项卡 。 Select the appropriate platform and copy the URL for the upgrade package (.pkg file).

3. Download the upgrade package to your GitHub Enterprise Server instance using curl :

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. Enable maintenance mode and wait for all active processes to complete on the GitHub Enterprise Server instance. For more information, see "Enabling and scheduling maintenance mode."

   Note: When upgrading the primary appliance in a High Availability configuration, the appliance should already be in maintenance mode if you are following the instructions in "Upgrading the primary instance."

5. Run the ghe-upgrade command using the package file name:

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
   *** verifying upgrade package signature...

6. Confirm that you'd like to continue with the upgrade and restart after the package signature verifies. The new root filesystem writes to the secondary partition and the instance automatically restarts in maintenance mode:

   *** applying update...
   This package will upgrade your installation to version VERSION-NUMBER
   Current root partition: /dev/xvda1 [VERSION-NUMBER]
   Target root partition:  /dev/xvda2
   Proceed with installation? [y/N]

7. For single appliance upgrades, disable maintenance mode so users can use your GitHub Enterprise Server instance.

   Note: When upgrading appliances in a High Availability configuration you should remain in maintenance mode until you have upgraded all of the replicas and replication is current. For more information, see "Upgrading a replica instance."

Upgrading an appliance that has replica instances using an upgrade package

Appliances configured for high-availability and geo-replication use replica instances in addition to primary instances. To upgrade these appliances, you'll need to upgrade both the primary instance and all replica instances, one at a time.

Upgrading the primary instance

1. On the primary instance, enable maintenance mode and wait for all active processes to complete. For more information, see "Enabling maintenance mode."
2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。

   $ ssh -p 122 admin@replica-host

3. On the replica instance, or on all replica instances if you're running multiple replica instances as part of geo-replication, run ghe-repl-stop to stop replication.
4. Upgrade the primary instance by following the instructions in "Upgrading a single appliance with an upgrade package."

Upgrading a replica instance

1. Upgrade the replica instance by following the instructions in "Upgrading a single appliance with an upgrade package." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。

   $ ssh -p 122 admin@replica-host

3. 运行以下命令来验证升级：

   $ ghe-version

4. 在副本实例上，要启动复制，请运行 ghe-repl-start。

5. 在副本实例中，为确保复制服务正常运行，请运行 ghe-repl-status。 成功开始复制且副本已升级时，此命令将对所有服务返回 OK。 If the command returns Replication is not running, the replication may still be starting. Wait about one minute before running ghe-repl-status again.

   Note: While the resync is in progress ghe-repl-status may indicate that replication is behind. For example, you may see the following message.

   CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
   

   - If `ghe-repl-status` did not return `OK`, contact GitHub Enterprise 支持. For more information, see "[Receiving help from GitHub 支持](/admin/enterprise-support/receiving-help-from-github-support)."

6. When you have completed upgrading the last replica, and the resync is complete, disable maintenance mode so users can use your GitHub Enterprise Server instance.

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

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 instances. 回滚升级时，必须使用一个带 .pkg 扩展的升级包文件。 不支持带 .hpkg 扩展的热补丁包文件。

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

运行命令后需要重启。 回滚不会影响数据分区，� 为迁移不是在补丁版本上运行的。

Once the rollback is complete, restart replication by running ghe-repl-start on all replicas.

For more information, see "Command-line utilities."

Rolling back a feature release

To roll back from a feature release, restore from a VM snapshot to ensure that root and data partitions are in a consistent state. For more information, see "Taking a snapshot."

Further reading

• "About upgrades to new releases"