升级要求

建议

• 尽量减少升级过程中的升级次数。 例如，不要从 GitHub Enterprise 2.21 升级到 2.22 再升级到 3.0，而应从 GitHub Enterprise 2.21 升级到 3.0。
• 如果您的版本比最新版本低几个版本，请通过升级过程的每一步骤尽量将 您的 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 3.0，您必须使用 GitHub Enterprise 2.22 或 2.21。
• 您可以使用热更新将 GitHub Enterprise Server 升级为最新的补丁版本，它不需要维护时间窗，通常不需要重启。 您可以使用热更新来升级到更新的补丁版本，但不能升级到功能版本。 例如，您可以从 2.10.1 升级到 2.10.5，因为它们属于相同的功能系列，但不能从 2. 0.9 升级到 2.11.0，因为它们处于不同的功能系列中。
• 如果受影响的服务（例如内核、MySQL 或 Elasticsearch）需要重启 VM 或服务，热补丁可能需要停机一段时间。 需要重启时，系统会通知您。 您可以在稍后完成重启。
• 通过热补丁升级时，必须提供额外的根存储，因为热补丁会安装某些服务的多个版本，直至升级完成。 如果根磁盘存储空间不足，运行前检查将发出通知。
• 通过热补丁进行升级时，您的实例负荷不能过大，否则可能影响热补丁过程。 运行前检查将考虑平均负载，如果平均负载过高，升级将失败。- 升级至 GitHub Enterprise Server 2.17 可将您的审核日志从 Elasticsearch 迁移到 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”。