使用升级包升级

了解如何使用升级包将 GitHub Enterprise Server 升级到更新的功能版本。

本文内容

通过管理外壳，可以使用 ghe-upgrade 实用工具安装升级包。

如果正在运行连续功能版本升级，则必须确保后台作业完成，然后再继续下列升级到功能版。 GitHub 建议等待任何后台升级任务完成，然后再进行第二次升级。 请参阅“升级过程概述”和“升级要求”。

虽然你可以使用热补丁升级到功能系列中的最新补丁版本，但必须使用升级包升级到更新的功能版本。 例如，要从 2.11.10 升级到 2.12.4，必须使用升级包，因为它们属于不同的功能系列。

使用升级包升级独立实例

注意

如果启用了自动更新检查，则无需下载升级包，可以使用自动下载的文件。 有关详细信息，请参阅“启用自动更新检查”。

  1. 通过 SSH 连接到 你的 GitHub Enterprise Server 实例。 如果实例包含多个节点，例如，如果配置了高可用性或异地复制，则通过 SSH 连接到主节点。 如果使用群集，则可以通过 SSH 连接到任何节点。 将 HOSTNAME 替换为实例的主机名，或节点的主机名或 IP 地址。 有关详细信息，请参阅“访问管理 shell (SSH)”。

    Shell
    ssh -p 122 admin@HOSTNAME

  2. 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边，单击“下载”，然后单击“升级”选项卡 。 选择相应的平台并复制升级包（.pkg 文件）的 URL。

  3. 使用 curl 将升级包下载到 你的 GitHub Enterprise Server 实例：

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

  4. 启用维护模式并等待 GitHub Enterprise Server 实例上的所有活动进程完成。 请参阅“启用和排定维护模式”。

    注意

    在高可用性配置中升级主节点时，如果按照使用升级包升级主节点中的说明操作，该实例应已处于维护模式。

  5. 使用包文件名运行 ghe-upgrade 命令：

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
*** verifying upgrade package signature...

  6. 确认你要继续升级，并在包签名得到验证后重新启动。 新的根文件系统会写入辅助分区，实例会在维护模式下自动重启：

    *** applying update...
This package will upgrade your installation to version VERSION-NUMBER
Current root partition: /dev/xvda1 [VERSION-NUMBER]
Target root partition:  /dev/xvda2
Proceed with installation? [y/N]

  7. （可选）在升级到功能版的过程中，可以使用 ghe-migrations 实用工具监视数据库迁移的状态。 请参阅“命令行实用程序”。

  8. 实例重启后，升级将在后台继续。 在过程完成后，才能取消设置维护模式。

    要检查后台作业的状态，请使用 ghe-check-background-upgrade-jobs 实用工具。 如果正在运行连续升级，则必须确保后台作业完成，然后再继续下列升级到功能版。

    请参阅“命令行实用程序”。

    要监视配置运行的进度，请读取 /data/user/common/ghe-config.log 中的输出。 例如，可以通过运行以下命令来跟踪日志：

    tail -f /data/user/common/ghe-config.log

    配置在后台运行，无需显式运行 ghe-config-apply ，除非遇到问题。

    警告

    如果您在多节点群集中升级一个节点，如果并非所有节点都升级到相同的版本，那么在命令行中运行 ghe-config-apply 或在 管理控制台 中保存设置可能会失败，导致升级不完整。 请改用 ghe-single-config-apply。

  9. （可选）升级之后，通过配置 IP 例外列表以允许访问指定 IP 地址列表来验证升级。 请参阅“启用和排定维护模式”。

  10. 对于单节点升级，请执行所有升级后任务，包括禁用维护模式，以便用户可以使用 你的 GitHub Enterprise Server 实例。

    注意

    在高可用性配置中升级实例后，应保持维护模式，直至升级所有副本节点且复制处于最新状态。 请参阅使用升级包升级其他节点。

使用升级包升级具有多个节点的实例

要使用升级包升级多节点 GitHub Enterprise Server 环境，必须首先升级主节点并等待其配置运行成功完成。 只有在主节点完全升级和配置后，才能继续升级任何副本或其他节点。 在主节点的升级完成之前，若尝试升级其他节点，将会导致升级失败。

  •           [使用升级包升级主节点](#upgrading-the-primary-node-with-an-upgrade-package)

  •           [使用升级包升级其他节点](#upgrading-additional-nodes-with-an-upgrade-package)

使用升级包升级主节点

警告

停止复制后，如果主节点发生故障，副本升级前和复制重新开始前的所有工作都将丢失。

  1. 在主节点上，启用维护模式并等待所有活动进程完成。 请参阅“启用和排定维护模式”。

  2. 以 admin 用户身份在端口 122 上通过 SSH 连接到副本节点：

    ssh -p 122 admin@REPLICA_HOST

  3. 要停止所有节点上的复制，请在每个节点上运行 ghe-repl-stop。 或者，如果有多个副本，请改为在主节点上运行 ghe-repl-stop-all ，这会在单个运行中停止复制。

  4. 要升级主节点，请按照“使用升级包升级独立实例”中的说明进行操作。

使用升级包升级其他节点

  1. 按照“使用升级包升级独立实例”中的说明升级节点。

  2. 以 admin 用户身份在端口 122 上通过 SSH 连接到副本节点：

    ssh -p 122 admin@REPLICA_HOST

  3. 运行以下命令来验证升级：

    ghe-version

  4. 在副本节点上，要启动复制，请运行 ghe-repl-start。 或者，如果有多个副本，请改为在主节点上运行 ghe-repl-start-all ，这将在单个运行中启动复制。

  5. 在副本节点上，为确保复制服务正常运行，请运行 ghe-repl-status。 成功开始复制且副本已升级时，此命令将对所有服务返回 OK。 如果命令返回 Replication is not running，则复制可能仍在启动。 等待 1 分钟左右，然后再次运行 ghe-repl-status。

注意

  • 当正在进行重新同步时，ghe-repl-status 可能指示复制进程落后。 例如，你可能会看到以下消息。

    CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists

  • 如果在 你的 GitHub Enterprise Server 实例 上启用了 GitHub Actions，你可能会看到如下所示的消息。 当复制由于在主设备上设置维护模式而暂停时，预计会出现此消息。 一旦取消设置维护模式，此消息应会得到解决。

    CRITICAL: mssql replication is down, didn't find Token_Configuration!

如果未 ghe-repl-status 返回 OK，并且上述笔记中未列出说明，请联系 GitHub Enterprise 支持。 有关详细信息，请参阅“联系 GitHub 支持”。

  1. 对其他每个节点重复上述步骤。
  2. 最后一个副本节点升级完成且重新同步完成后，请禁用维护模式，以便用户能够使用 你的 GitHub Enterprise Server 实例。