关于 GitHub Enterprise Server 群集的升级
GitHub Enterprise Server 在不断改进，通过功能和修补程序版本引入了新功能和缺陷修复。你负责升级到实例。 有关详细信息，请参阅“关于升级到新版本”。
要升级实例，必须计划并沟通升级事宜，选择适当的包，备份数据，然后执行升级。
使用热补丁升级
可使用热补丁将 GitHub Enterprise Server 升级到最新的补丁版本。
您可以使用热更新来升级到更新的补丁版本，但不能升级到功能版本。 例如，你可从 2.10.1 升级到 2.10.5，因为它们位于同一功能系列中，但不能从 2.10.9 升级到 2.11.0，因为它们位于不同的功能系列中。
热补丁并不总是需要重新启动。 安装热补丁时，如果任一包需要重新启动才能完成更新，你将在终端中看到一条消息。 可以安排在方便的时候进行重新启动，但我们建议尽快重新启动，特别是在有任何安全修复的情况下。
热补丁需要配置运行，这可能会导致 你的 GitHub Enterprise Server 实例 上的部分或所有服务短暂出现错误或无响应。 无需在热补丁安装期间启用维护模式，但这样做将保证用户看到维护页，而不是错误或超时。 请参阅“启用和排定维护模式”。 热补丁安装脚本可在集群中的每个节点上安装热补丁，并按正确顺序重新启动服务以避免停机。
-
在任何节点的管理 shell 中，使用
ghe-cluster-hotpatch命令安装最新的热补丁。 您可以为热补丁提供 URL，也可以手动下载该热补丁并指定本地文件名。ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg
使用升级包升级
使用升级包将 GitHub Enterprise Server 集群升级到最新功能版本。 例如，可从 2.11 升级到 2.13。
准备升级
-
查看要升级到的版本的“群集网络配置”，并根据需要更新配置。
-
为 GitHub Enterprise Server 集群的最终用户排定维护窗口，因为它在升级期间无法正常使用。 在群集群升级过程中，维护模式会阻止用户访问并防止数据更改。
-
在 GitHub Enterprise Server 下载页面上，将 .pkg 升级文件的 URL 复制到剪贴板。
-
在任何节点的管理 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 -
确定主 MySQL 节点，此节点在
cluster.conf中定义为mysql-master = <hostname>。 此节点将最后升级。
升级集群节点
-
通过连接到任何集群节点的管理 shell 并运行
ghe-cluster-maintenance -s，根据排定的窗口启用维护模式。 -
除了主 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>" -
升级过程将在完成后重启节点。 验证是否可在每个节点重启后对其执行
ping操作。 -
连接到主 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>" -
升级过程将在完成后重启主 MySQL 节点。 验证是否可在每个节点重启后对其执行
ping操作Important
继续下一步之前，必须等待升级后配置完成。 要监视配置运行的进度，请读取
/data/user/common/ghe-config.log中的输出。 例如，可以通过运行以下命令来跟踪日志：tail -f /data/user/common/ghe-config.log -
连接到主 MySQL 节点的管理 shell 并运行
ghe-cluster-config-apply命令。 -
当
ghe-cluster-config-apply完成时，通过运行ghe-cluster-status来检查服务是否处于正常状态。 -
通过运行
ghe-cluster-maintenance -u，从任何节点的管理 shell 退出维护模式。