Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

升级要求

对 GitHub Enterprise Server 进行升级之前,请查阅升级策略规划的建议和要求。

注意:

  • enterprise.github.com 上提供了支持版本的升级包。 验证完成升级所需的升级包的可用性。 如果升级包不可用,请联系 GitHub Enterprise Support 获得帮助。
  • 如果使用的是 GitHub Enterprise Server 群集,请参阅 GitHub Enterprise Server 群集指南中的“升级群集”,了解群集特有的特定说明。
  • GitHub Enterprise Server 版本说明提供了 GitHub Enterprise Server 每一版本的新功能一览表。 有关详细信息,请参阅发布页面

建议

  • 尽量减少升级过程中的升级次数。 例如,不要从 GitHub Enterprise 3.5 升级到 3.6 再升级到 3.7,而应从 GitHub Enterprise 3.5 升级到 3.7。 使用 Upgrade assistant 查找当前发行版本的升级路径。
  • 如果你的版本比最新版本低几个版本,请通过升级过程的每一步骤尽量将 your GitHub Enterprise Server instance升级为更高版本。 在每次升级时尽可能使用最新版本,这样一来您可以充分利用性能改进和错误修复。 例如,您可以从 GitHub Enterprise 2.7 升级到 2.8 再升级到 2.10,但从 GitHub Enterprise 2.7 升级到 2.9 再升级到 2.10 会在第二步中使用更高版本。
  • 升级时使用最新补丁版本。 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边,单击“下载”,然后单击“升级”选项卡 。
  • 使用暂存实例测试升级步骤。 有关详细信息,请参阅“设置暂存实例”。
  • 如果运行多次升级,两次功能升级之间至少应间隔 24 小时,以便使数据迁移和后台升级任务能够彻底完成。
  • 在升级虚拟机之前拍摄快照。 有关详细信息,请参阅“拍摄快照”。
  • 确保您最近成功备份了实例。 有关详细信息,请参阅 GitHub Enterprise Server Backup Utilities README.md 文件

要求

  • 必须从最近两个版本的功能版本开始升级。 例如,要升级到 GitHub Enterprise 3.7,您必须使用 GitHub Enterprise 3.6 或 3.5。
  • 使用升级包进行升级时,请为 GitHub Enterprise Server 最终用户安排维护时段。
  • 可使用热补丁将 GitHub Enterprise Server 升级到最新的补丁版本。

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

热补丁通常不要求重启。 如果热补丁确实要求重启,GitHub Enterprise Server 发行说明将说明此要求。

热补丁需要配置运行,这可能会导致 your GitHub Enterprise Server instance 上的部分或所有服务短暂出现错误或无响应。 无需在热补丁安装期间启用维护模式,但这样做将保证用户看到维护页,而不是错误或超时。 有关详细信息,请参阅“启用和安排维护模式”。

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