升级要求

建议

• 尽量减少升级过程中的升级次数。 例如，不要从 GitHub Enterprise 2.16 升级到 2.17 再升级到 2.18，而应从 GitHub Enterprise 2.16 升级到 2.18。
• 如果您的版本比最新版本低几个版本，请通过升级过程的每一步骤尽量将 您的 GitHub Enterprise Server 实例 升级为更高版本。 在每次升级时尽可能使用最新版本，这样一来您可以充分利用性能改进和错误修复。 例如，您可以从 GitHub Enterprise 2.7 升级到 2.8 再升级到 2.10，但从 GitHub Enterprise 2.7 升级到 2.9 再升级到 2.10 会在第二步中使用更高版本。
• 升级时使用最新补丁版本。 Browse to the GitHub Enterprise Server Releases page. Next to the release you are upgrading to, click Download, then click the Upgrading tab.
• 使用暂存实例测试升级步骤。 更多信息请参阅“设置暂存实例”。
• 如果运行多次升级，两次功能升级之间至少应间隔 24 小时，以便使数据迁移和后台升级任务能够彻底完成。

要求

• 您必须从最近两个版本的功能版本开始升级。 例如，要升级到 GitHub Enterprise 2.18，您必须使用 GitHub Enterprise 2.17 或 2.16。

• You can upgrade GitHub Enterprise Server to the latest patch release using a hotpatch, which does not require a maintenance window and usually does not require a reboot. 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.

• 如果受影响的服务（例如内核、MySQL 或 Elasticsearch）需要重启 VM 或服务，热补丁可能需要停机一段时间。 需要重启时，系统会通知您。 您可以在稍后完成重启。

• 通过热补丁升级时，必须提供额外的根存储，因为热补丁会安装某些服务的多个版本，直至升级完成。 如果根磁盘存储空间不足，运行前检查将发出通知。

• 通过热补丁进行升级时，您的实例负荷不能过大，否则可能影响热补丁过程。 运行前检查将考虑平均负载，如果平均负载过高，升级将失败。

• 升级到 GitHub Enterprise Server 2.17 会将您的审核日志从 ElasticSearchElasticSearch 迁移到 MySQL。 这种迁移还会增加恢复快照所需的时长和磁盘空间大小。 迁移之前，请使用此命令检查 ElasticSearch 审核日志索引中的字节数：

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

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

查看这些建议和要求后，您可以对 GitHub Enterprise Server 进行升级。 更多信息请参阅“升级 GitHub Enterprise Server”。