使用升级包升级

了解如何使用升级包将 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 环境，必须首先升级主节点并等待其配置运行成功完成。 只有在主节点完全升级和配置后，才能继续升级任何副本或其他节点。 在主节点的升级完成之前，若尝试升级其他节点，将会导致升级失败。

使用升级包升级主节点

警告

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

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

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

如果未 ghe-repl-status 返回 OK，并且上述笔记中未列出说明，请联系 GitHub Enterprise 支持。 有关详细信息，请参阅“联系 GitHub 支持团队”。1. 对其他每个节点重复上述步骤。1. 最后一个副本节点升级完成且重新同步完成后，请禁用维护模式，以便用户能够使用 你的 GitHub Enterprise Server 实例。