升级要求

建议

• 尽量减少升级过程中的升级次数。 例如，不要从 GitHub Enterprise 2.15 升级到 2.16 再升级到 2.17，而应从 GitHub Enterprise 2.15 升级到 2.17。
• 如果您的版本比最新版本低几个版本，请通过升级过程的每一步骤尽量将 您的 GitHub Enterprise Server 实例 升级为更高版本。 在每次升级时尽可能使用最新版本，这样一来您可以充分利用性能改进和错误修复。 例如，您可以从 GitHub Enterprise 2.7 升级到 2.8 再升级到 2.10，但从 GitHub Enterprise 2.7 升级到 2.9 再升级到 2.10 会在第二步中使用更高版本。
• 升级时使用最新补丁版本。 浏览到 GitHub Enterprise Server 版本页面。在要升级到的版本旁边，单击 Download（下载），然后单击 Upgrading（升级）选项卡。
• 使用暂存实例测试升级步骤。 更多信息请参阅“设置暂存实例”。
• 如果运行多次升级，两次功能升级之间至少应间隔 24 小时，以便使数据迁移和后台升级任务能够彻底完成。

要求

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

• 您可以使用热补丁将 GitHub Enterprise Server 升级到最新的补丁版本，不需要维护窗口，并且一般不需要重启。使用热补丁可以升级到较新的补丁版本，但不能升级功能版本。例如，可以从 2.10.1 升级到 2.10.5，因为它们在相同的功能系列中，但不是从 2.10.9 升级到 2.11.0，因为它们在不同的功能系列中。

• 如果受影响的服务（例如内核、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”。