升级集群

若要将 GitHub Enterprise Server 群集升级到最新版本，请使用管理 shell (SSH)。

谁可以使用此功能？

GitHub 确定聚类分析的资格，并且必须为实例的许可证启用配置。 聚类分析需要仔细规划和额外的管理开销。 有关详细信息，请参阅“关于集群”。

本文内容

关于 GitHub Enterprise Server 群集的升级

GitHub Enterprise Server 在不断改进，通过功能和修补程序版本引入了新功能和缺陷修复。你负责升级到实例。 有关详细信息，请参阅“关于升级到新版本”。

要升级实例，必须计划并沟通升级事宜，选择适当的包，备份数据，然后执行升级。

使用热补丁升级

可使用热补丁将 GitHub Enterprise Server 升级到最新的补丁版本。

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

热补丁并不总是需要重新启动。 安装热补丁时，如果任一包需要重新启动才能完成更新，你将在终端中看到一条消息。 可以安排在方便的时候进行重新启动，但我们建议尽快重新启动，特别是在有任何安全修复的情况下。

热补丁需要配置运行，这可能会导致 你的 GitHub Enterprise Server 实例 上的部分或所有服务短暂出现错误或无响应。 无需在热补丁安装期间启用维护模式，但这样做将保证用户看到维护页，而不是错误或超时。 请参阅“启用和排定维护模式”。 热补丁安装脚本可在集群中的每个节点上安装热补丁，并按正确顺序重新启动服务以避免停机。

  1. 使用 GitHub Enterprise Server Backup Utilities 备份数据。

  2. 在任何节点的管理 shell 中，使用 ghe-cluster-hotpatch 命令安装最新的热补丁。 您可以为热补丁提供 URL，也可以手动下载该热补丁并指定本地文件名。

    ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg

使用升级包升级

使用升级包将 GitHub Enterprise Server 集群升级到最新功能版本。 例如，可从 2.11 升级到 2.13。

准备升级

  1. 查看要升级到的版本的“群集网络配置”，并根据需要更新配置。

  2. 使用 GitHub Enterprise Server Backup Utilities 备份数据。

  3. 为 GitHub Enterprise Server 集群的最终用户排定维护窗口，因为它在升级期间无法正常使用。 在群集群升级过程中，维护模式会阻止用户访问并防止数据更改。

  4. 在 GitHub Enterprise Server 下载页面上，将 .pkg 升级文件的 URL 复制到剪贴板。

  5. 在任何节点的管理 shell 中，将 ghe-cluster-each 命令与 curl 结合使用，只需一步即可将发布包下载到每个节点。 使用您在上一步中复制的 URL 作为参数。

    $ ghe-cluster-each -- "cd /home/admin && curl -L -O  https://PACKAGE-URL.pkg"
> ghe-app-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  24.2M      0  0:00:20  0:00:20 --:--:-- 27.4M
> ghe-data-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  21.3M      0  0:00:23  0:00:23 --:--:-- 25.8M
> ghe-data-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.6M
> ghe-app-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.8M      0  0:00:25  0:00:25 --:--:-- 17.6M
> ghe-data-node-3:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-3:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.5M

  6. 确定主 MySQL 节点，此节点在 cluster.conf 中定义为 mysql-master = <hostname>。 此节点将最后升级。

升级集群节点

  1. 通过连接到任何集群节点的管理 shell 并运行 ghe-cluster-maintenance -s，根据排定的窗口启用维护模式。

  2. 如果从版本 3.11 或 3.12 升级到版本 3.13 或更高版本，则 Elasticsearch 将作为升级到群集的一部分进行升级。 有关详细信息，请参阅“准备 GitHub Enterprise Server 3.13 中的 Elasticsearch 升级”。

    在升级之前，需要运行一个脚本来准备群集，以便升级到 3.13 或 3.14。

    1. 确保为当前版本运行所需的修补程序版本：3.11.9 或更高版本（对于 3.11），或 3.12.3 或更高版本（对于 3.12）。
    2. 在任何 elasticsearch-server 节点上，运行 /usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance。

  3. 除了主 MySQL 节点之外，连接到每个 GitHub Enterprise Server 节点的管理 shell。 运行 ghe-upgrade 命令，提供在准备升级的步骤 4 中下载的包文件名：

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

  4. 升级过程将在完成后重启节点。 验证是否可在每个节点重启后对其执行 ping 操作。

  5. 连接到主 MySQL 节点的管理 shell。 运行 ghe-upgrade 命令，提供在准备升级的步骤 4 中下载的包文件名：

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

  6. 升级过程将在完成后重启主 MySQL 节点。 验证是否可在每个节点重启后对其执行 ping 操作

    Important

    继续下一步之前，必须等待升级后配置完成。 要监视配置运行的进度，请读取 /data/user/common/ghe-config.log 中的输出。 例如，可以通过运行以下命令来跟踪日志：

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

  7. 连接到主 MySQL 节点的管理 shell 并运行 ghe-cluster-config-apply 命令。

  8. 当 ghe-cluster-config-apply 完成时，通过运行 ghe-cluster-status 来检查服务是否处于正常状态。

  9. 通过运行 ghe-cluster-maintenance -u，从任何节点的管理 shell 退出维护模式。