# 升级要求

在升级 GitHub Enterprise Server之前，请查看这些建议和要求来规划升级策略。

> \[!NOTE]
> \*
> [enterprise.github.com](https://enterprise.github.com/releases) 上提供了支持版本的升级包。 验证完成升级所需的升级包的可用性。 如果无法获取该软件包，请访问 [GitHub Enterprise 支持](https://support.github.com) 并联系我们获取帮助。
>
> * 如果使用GitHub Enterprise Server聚类分析，请参阅群集指南中的 [](/zh/enterprise-server@3.22/admin/monitoring-and-managing-your-instance/configuring-clustering/upgrading-a-cluster)GitHub Enterprise Server，了解聚类分析特有的特定说明。
> *

GitHub Enterprise Server发行说明提供了GitHub Enterprise Server每个版本新功能的完整列表。 有关详细信息，请参阅[发布页面](https://enterprise.github.com/releases)。

## 建议

* 尽量减少升级过程中的升级次数。 例如，你可以从 GitHub Enterprise3.20 升级到 3.21，而不是从 3.22GitHub Enterprise 升级到 3.20 到 3.22。 使用  [升级助手](https://support.github.com/enterprise/server-upgrade) 查找当前版本中的升级路径。
* 如果你当前版本落后了好几个版本，请在升级过程的每一步中尽可能将 你的 GitHub Enterprise Server 实例 升级到更高版本。 在每次升级时尽可能使用最新版本，这样一来你可以充分利用性能改进和错误修复。 例如，可以将 GitHub Enterprise 2.7 升级到 2.8 到 2.10，但从 GitHub Enterprise 2.7 升级到 2.9 到 2.10 的第二步使用更高版本。
* 升级时使用最新补丁版本。 浏览到 [GitHub Enterprise Server 版本页](https://enterprise.github.com/releases)。 在要升级到的版本旁边，单击“下载”，然后单击“升级”选项卡 。
* 使用暂存实例测试升级步骤。 有关详细信息，请参阅“[设置暂存实例](/zh/enterprise-server@3.22/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance)”。
* 运行多个升级时，请确保在后台运行的数据迁移和升级任务完全完成，然后再继续下一个功能升级。 要检查这些流程的状态，可以使用 `ghe-migrations` 和 `ghe-check-background-upgrade-jobs` 命令行实用程序。 有关详细信息，请参阅“[命令行实用程序](/zh/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#upgrading-github-enterprise-server)”。
* 在升级虚拟机之前拍摄快照。 有关详细信息，请参阅“[生成快照](/zh/enterprise-server@3.22/admin/upgrading-your-instance/preparing-to-upgrade/taking-a-snapshot)”。 创建快照后，关闭自动快照，以避免在升级期间产生可能的性能影响。
* 确保你最近成功备份了实例。 有关详细信息，请参阅 [GitHub Enterprise Server Backup Utilities README.md 文件](https://github.com/github/backup-utils#readme)。

## 要求

* 必须执行容量检查。 有关详细信息，请参阅“[升级前检查系统容量](/zh/enterprise-server@3.22/admin/upgrading-your-instance/preparing-to-upgrade/check-system-capacity-before-upgrading)”。
* 必须从**最近**两个版本的功能版本开始升级。 例如，若要升级到GitHub Enterprise3.22，您必须当前处于GitHub Enterprise3.21或3.20。
* 使用升级包进行升级时，请为 GitHub Enterprise Server 最终用户计划维护时段。
* 可以使用热修补将 GitHub Enterprise Server 升级到最新的补丁版本。

您可以使用热更新来升级到更新的补丁版本，但不能升级到功能版本。 例如，你可从 2.10.1 升级到 2.10.5，因为它们位于同一功能系列中，但不能从 2.10.9 升级到 2.11.0，因为它们位于不同的功能系列中。

热补丁并不总是需要重新启动。 安装热补丁时，如果任一包需要重新启动才能完成更新，你将在终端中看到一条消息。 可以安排在方便的时候进行重新启动，但我们建议尽快重新启动，特别是在有任何安全修复的情况下。

热补丁需要运行配置，这可能会导致 你的 GitHub Enterprise Server 实例 上的部分或全部服务在短时间内出现错误或无响应。 无需在热补丁安装期间启用维护模式，但这样做将保证用户看到维护页，而不是错误或超时。 请参阅“[启用和排定维护模式](/zh/enterprise-server@3.22/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode)”。

* 如果受影响的服务（例如内核、MySQL 或 Elasticsearch）需要重启 VM 或服务，热补丁可能需要停机一段时间。 需要重启时，系统会通知你。 你可以在稍后完成重启或重新启动。
* 通过热补丁升级时，必须提供额外的根存储，因为热补丁会安装某些服务的多个版本，直至升级完成。 如果根磁盘存储空间不足，运行前检查将发出通知。
* 通过热补丁进行升级时，你的实例负荷不能过大，否则可能影响热补丁过程。
* 升级到 GitHub Enterprise Server 2.17 会将审核日志从 Elasticsearch 迁移到 MySQL。 这种迁移还会增加恢复快照所需的时长和磁盘空间大小。 迁移之前，请使用此命令检查 ElasticSearch 审核日志索引中的字节数：

```shell
curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes
```

使用此数字估算 MySQL 审核日志将需要的磁盘空间大小。 该脚本还会在导入过程中监视可用磁盘空间大小。 当可用磁盘空间接近迁移所需的磁盘空间时，监视此数字尤为重要。

升级时，通过预外部测试检查来评估实例是否满足有关系统硬件资源（例如内存、CPU 核心和用户和根磁盘存储）的最低要求。 如果预外部测试检查确定资源不足，或者因其他原因未通过检查，则系统会通知你并中止升级。

## 后续步骤

在审阅这些建议和要求后，您可以升级 GitHub Enterprise Server。 有关详细信息，请参阅“[升级过程概述](/zh/enterprise-server@3.22/admin/upgrading-your-instance/preparing-to-upgrade/overview-of-the-upgrade-process)”。