注意：GitHub Actions、GitHub Packages、GitHub Mobile 和 GitHub Advanced Security 等功能在 GitHub Enterprise Server 3.0 或更高版本中可用。 我们强烈建议升级到 3.0 或更高版本，以利用关键安全更新、错误修复和功能增强。
准备升级
-
使用 GitHub Enterprise Server 备份实用程序 创建全新的主实例备份。 更多信息请参阅 GitHub Enterprise Server 备份实用程序 README.md 文件。
-
如果 您的 GitHub Enterprise Server 实例 使用临时自托管运行器进行 GitHub Actions 并且您已禁用自动更新，请将运行器升级到已升级实例将运行的运行器应用程序的版本。
-
如果您要使用升级包进行升级，请为 GitHub Enterprise Server 最终用户排定维护窗口。 如果您要使用热补丁，则不需要使用维护模式。
注：维护窗口取决于所执行升级的类型。 使用热补丁进行升级通常不需要维护窗口。 有时需要重启，不过您可以在之后的某个时间重启。 按照 MAJOR.FEATURE.PATCH 的版本控制方案，使用升级包的补丁版本通常需要不到 5 分钟的停机时间。 包含数据迁移的功能版本需要的时间更长，具体视存储性能以及迁移的数据量而定。 更多信息请参阅“启用和排定维护模式”。
About minimum requirements for GitHub Enterprise Server 3.0 and later
Before upgrading to GitHub Enterprise Server 3.0 or later, review the hardware resources you've provisioned for your instance. GitHub Enterprise Server 3.0 introduces new features such as GitHub Actions and GitHub Packages, and requires more resources than versions 2.22 and earlier. For more information, see the GitHub Enterprise Server 3.0 release notes.
Increased requirements for GitHub Enterprise Server 3.0 and later are bold in the following table.
| User licenses | vCPUs | Memory | Attached storage | Root storage |
|---|---|---|---|---|
| Trial, demo, or 10 light users | 4 Up from 2 | 32 GB Up from 16 GB | 150 GB Up from 100 GB | 200 GB |
| 10 to 3,000 | 8 Up from 4 | 48 GB Up from 32 GB | 300 GB Up from 250 GB | 200 GB |
| 3,000 to 5000 | 12 Up from 8 | 64 GB | 500 GB | 200 GB |
| 5,000 to 8000 | 16 Up from 12 | 96 GB | 750 GB | 200 GB |
| 8,000 to 10,000+ | 20 Up from 16 | 160 GB Up from 128 GB | 1000 GB | 200 GB |
For more information about hardware requirements for GitHub Actions, see "Getting started with GitHub Actions for GitHub Enterprise Server."
有关为现有实例调整资源的更多信息，请参阅“增� 存储容量”和“增� CPU 或内存资源”。
生成快照
快照是虚拟机 (VM) 在某一时间点的检查点。 强烈建议在升级虚拟机之前生成快照，这� �一来，如果升级失败，您可以将 VM 还原到快照状态。 我们仅建议在设备关闭电源或处于维护模式且所有后台作业都已完成时拍摄 VM 快照。
如果您要升级到新的功能版本，则必须生成 VM 快照。 如果您要升级到补丁版本，可以连接现有数据磁盘。
有两种类型的快照：
-
VM 快照会保存整个 VM 状态，包括用户数据和配置数据。 此快照方法需要� 用大量磁盘空间，且比较耗时。
-
数据磁盘快照仅会保存您的用户数据。
注意：
- 某些平台不允许您只生成数据磁盘的快照。 对于此类平台，您需要生成整个 VM 的快照。
- 如果您的虚拟机监控程序不支持完整的 VM 快照，您应连续、快速地生成� �磁盘和数据磁盘的快照。
使用热补丁升级
您可以使用热更新将 GitHub Enterprise Server 升级为最新的补丁版本，它不需要维护时间窗，通常不需要重启。
您可以使用热更新来升级到更新的补丁版本，但不能升级到功能版本。 例如，您可以从 2.10.1 升级到 2.10.5，� 为它们属于相同的功能系列，但不能从 2. 0.9 升级到 2.11.0，� 为它们处于不同的功能系列中。
使用 管理控制台，您可以立即安装热补丁，也可以安排以后安装。 您可以使用管理 shell 的 ghe-upgrade 实用程序安装热补丁。 更多信息请参阅“升级要求”。
注释：
-
如果 您的 GitHub Enterprise Server 实例 正在运行发布候选版本，则� 法使用热补丁升级。
-
� 法在集群环境中使用 管理控制台 安装热补丁。 要在集群环境中安装热补丁，请参阅“升级集群”。
使用热补丁升级单个设备
使用 管理控制台 安装热补丁
您可以通过启用自动更新来使用 管理控制台 通过热补丁进行升级。 然后，您将看到可升级到的最新可用 GitHub Enterprise Server 版本。
如果显示的升级目� �是功能版本而不是修补程序版本，则� 法使用 管理控制台 来安装修补程序。 您必须改为使用管理 shell 安装热补丁。 更多信息请参阅“使用管理 shell 安装热补丁”。
-
启用自动更新。 更多信息请参阅“启用自动更新”。
-
从 GitHub Enterprise Server 上的管理帐户中，在任何页面的右上角，单击 。
-
如果您尚未进入“站点管理员”页面，请在左上角单击 Site admin（站点管理员）。
-
在左侧边� �中，单击 管理控制台。
-
在 管理控制台 顶部，单击 Updates（更新）。
-
在新的热补丁下载完毕后，请使用 Install package 下拉菜单：
- 要立即安装，请选择 Now：
- 要稍后安装，请选择以后的日期。
-
单击 Install（安装）。
使用管理 shell 安装热补丁
注： 如果启用了自动更新检查，则� 需下载升级包，可使用自动下载的文件。 更多信息请参阅“启用自动更新检查”。
- SSH 连接到 您的 GitHub Enterprise Server 实例。 更多信息请参阅“访问管理 shell (SSH)。”
$ ssh -p 122 admin@HOSTNAME - 浏览到 GitHub Enterprise Server 发行版页面。 在要升级到的版本旁边，单击 Download（下载），然后单击 Upgrading（升级）选项卡。 复制升级热补丁包（.hpkg 文件）的 URL。
- 使用
curl将升级包下载到 您的 GitHub Enterprise Server 实例：admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL - 使用包文件名运行
ghe-upgrade命令：admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg *** verifying upgrade package signature... - 如果更新内� �、MySQL、Elasticsearch 或其他程序时需要重启，热补丁升级脚本会通知您。
使用热补丁升级包含副本实例的设备
注：如果要安装热补丁，则� 需进入维护模式或停止复制。
配置为高可用性和 Geo-replication 的设备除了会使用主实例之外，还会使用副本实例。 要升级此类设备，您需要逐个升级主实例和所有副本实例。
升级主实例
- 请按照“使用管理 shell 安装热补丁”中的说明升级主实例。
升级副本实例
注：如果您要将多个副本实例作为 Geo-replication 的一部分运行，请逐一为每个副本实例重复此步骤。
-
按照“使用管理 shell 安装热补丁”中的说明升级副本实例。 如果使用多个副本进行异地复制，则必须重复此过程，每次升级一个副本。
-
以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。
$ ssh -p 122 admin@replica-host -
运行以下命令来验证升级：
$ ghe-version
使用升级包升级
虽然您可以使用热补丁升级到功能系列中的最新补丁版本，但必须使用升级包升级到更新的功能版本。 例如，要从 2.11.10 升级到 2.12.4，您必须使用升级包，� 为两者在不同的功能系列中。 更多信息请参阅“升级要求”。
使用升级包升级单个设备
注： 如果启用了自动更新检查，则� 需下载升级包，可使用自动下载的文件。 更多信息请参阅“启用自动更新检查”。
-
SSH 连接到 您的 GitHub Enterprise Server 实例。 更多信息请参阅“访问管理 shell (SSH)。”
$ ssh -p 122 admin@HOSTNAME -
浏览到 GitHub Enterprise Server 发行版页面。 在要升级到的版本旁边，单击 Download（下载），然后单击 Upgrading（升级）选项卡。 选择适当的平台并复制升级包（.pkg 文件）的 URL。
-
使用
curl将升级包下载到 您的 GitHub Enterprise Server 实例：admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL -
启用维护模式并等待 GitHub Enterprise Server 实例上的所有活动进程完成。 更多信息请参阅“启用和排定维护模式”。
注：升级采用高可用性配置的主设备时，如果您按照“升级主实例”中的说明操作，设备应当已处于维护模式。
-
使用包文件名运行
ghe-upgrade命令：admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg *** verifying upgrade package signature... -
确认您要继续升级，并在包签名得到验证后重新启动。 新的� �文件系统会写入辅助分区，实例会在维护模式下自动重启：
*** 正在应用更新... 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] -
对于单个设备升级，请禁用维护模式，以便用户能够使用 您的 GitHub Enterprise Server 实例。
注：升级采用高可用性配置的主设备时，您应当一直处于维护模式，直至已升级所有副本，复制是最新版本。 更多信息请参阅“升级副本实例”。
使用升级包升级包含副本实例的设备
配置为高可用性和 Geo-replication 的设备除了会使用主实例之外，还会使用副本实例。 要升级此类设备，您需要逐个升级主实例和所有副本实例。
升级主实例
警告：复制停止时，如果主实例发生故障，副本升级和复制再次开始之前执行的任何操作都将丢失。
- 在主实例上，启用维护模式并等待所有活动进程完成。 更多信息请参阅“启用维护模式”。
- 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。
$ ssh -p 122 admin@replica-host - 在副本实例或者所有副本实例（如果您将多个副本实例作为 Geo-replication 的一部分运行）上，运行
ghe-repl-stop以停止复制。 - 按照“使用升级包升级单个设备”中的说明升级主实例。
升级副本实例
注：如果您要将多个副本实例作为 Geo-replication 的一部分运行，请逐一为每个副本实例重复此步骤。
-
按照“使用升级包升级单个设备”中的说明升级副本实例。 如果使用多个副本进行异地复制，则必须重复此过程，每次升级一个副本。
-
以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。
$ ssh -p 122 admin@replica-host -
运行以下命令来验证升级：
$ ghe-version -
在副本实例上，要开始复制，请运行
ghe-repl-start。 -
在副本实例中，为确保复制服务正常运行，请运行
ghe-repli-status。 当成功的复制正在进行中且副本已升级时，此命令将对所有服务返回OK。 如果命令返回Replication is not running，说明复制可能仍在启动。 等待 1 分钟左右，然后再次运行ghe-repl-status。注：在重新同步过程中，
ghe-repl-status可能返回预期消息，提示复制落后。 例如：CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists如果
ghe-repl-status未返回OK，请联系 GitHub Enterprise 支持。 更多信息请参阅“从 GitHub 支持 获取帮助”。 -
最后一个副本升级完毕且重新同步完成后，请禁用维护模式，以便用户能够使用 您的 GitHub Enterprise Server 实例。
从失败的升级中恢复
如果升级失败或中断，您应将实例还原为其之前的状态。 完成此操作的过程取决于升级类型。
回滚补丁版本
要回滚补丁版本，请使用带 --allow-patch-rollback 开关的 ghe-upgrade 命令。 在回滚之前，必须通过在所有副本实例上运行 ghe-repl-stop 来暂时停止复制。 回滚升级时，您必须使用一个带 .pkg 扩展的升级包文件。 不支持带 .hpkg 扩展的热补丁包文件。
ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg运行命令后需要重启。 回滚不会影响数据分区，� 为迁移不是在补丁版本上运行的。
回滚完成后，通过在所有副本上运行 ghe-repl-start 来重新启动复制。
更多信息请参阅“命令行实用程序”。
回滚功能版本
要从功能版本回滚，请从 VM 快照恢复，以确保� �分区和数据分区处于一致的状态。 更多信息请参阅“生成快照”。
延伸阅读
- "关于升级到新版本"