Skip to main content

Enterprise Server 3.15 目前作为候选发布提供。

监视高可用性配置

为 你的 GitHub Enterprise Server 实例 配置高可用性后,可以监视实例的副本节点之间的数据复制状态。

谁可以使用此功能?

Site administrators can monitor a high-availability configuration for a GitHub Enterprise Server instance.

关于高可用性的可观测性

若要支持灾难恢复计划并补充备份,或为地理位置分散的用户提高网络和写入性能,可以为 你的 GitHub Enterprise Server 实例 配置高可用性。 有关详细信息,请参阅“关于高可用性配置”。

配置高可用性后,可以通过监视复制的总体运行状况和每个实例副本节点的状态来主动确保冗余。 可以在实例、概述仪表板、实例的 REST API、或远程监视系统(如 Nagios)上使用命令行实用工具。

借助高可用性,实例使用多种方法在主节点和副本节点之间复制数据。 支持本机复制机制的数据库服务(例如 MySQL)使用服务的本机机制进行复制。 其他服务(例如 Git 存储库)使用为 GitHub Enterprise Server 开发的自定义机制或使用 rsync 等平台工具进行复制。

监视从实例进行的复制

若要监视 你的 GitHub Enterprise Server 实例 的现有副本节点的复制状态,请连接到该节点的管理控制台 (SSH) 并运行 ghe-repl-status 命令行实用工具。 有关详细信息,请参阅“命令行实用程序”。

还可以通过实例上的概述仪表板监视复制状态。 在浏览器中导航到以下 URL(将 HOSTNAME 替换为实例的主机名)。

http(s)://HOSTNAME/setup/replication

使用 GitHub CLI

监视复制

可以使用适用于 GitHub CLI 的 gh es 扩展监视实例的复制状态。 有关更多信息,请参阅“GH ES CLI 使用方法文档”和“使用 GitHub CLI 管理实例”。

使用 REST API 监视复制

可以使用 REST API 监视实例上的复制状态。 有关详细信息,请参阅 REST API 文档中的“管理 GitHub Enterprise Server”。

监视从远程系统进行的复制

ghe-repl-status 命令行实用工具的输出符合 Nagios check_by_ssh 插件的预期。 有关详细信息,请参阅“命令行实用程序”。

此外,还可以通过解析请求返回到以下 URL 的状态代码来监视实例的可用性。 例如,如果将负载均衡器部署为故障转移策略的一部分,则可以配置用于解析此输出的运行状况检查。 有关详细信息,请参阅“结合使用 GitHub Enterprise Server 和负载均衡器”。

根据配置监视的位置和方式,将 HOST 替换为实例的主机名或单个节点的 IP 地址。

http(s)://HOST/status

可响应用户请求的异地复制活动节点将返回状态代码 200(正常)。 对单个节点或实例主机名的请求可能会返回 503(服务不可用)错误,原因如下。

  • 单个节点是被动副本节点,例如双节点高可用性配置中的副本节点。
  • 单个节点是异地复制配置的一部分,但它是被动副本节点。
  • 实例处于维护模式。 有关详细信息,请参阅“启用和排定维护模式”。

若需了解有关异地复制的详细信息,请参阅“关于 Geo-replication”。

排查复制问题

若要排查实例上的复制问题,请确保复制正在运行,并且节点可以通过网络相互通信。 还可以使用命令行实用工具来调查复制不到位的情况。

复制未运行

必须使用 ghe-repl-start 命令行实用工具在每个节点上启动复制。 如果复制未运行,请使用 SSH 连接到受影响的节点,然后运行 ghe-repl-start。 有关详细信息,请参阅“命令行实用程序”。

节点之间的通信问题

复制要求主节点和所有副本节点可以通过网络相互通信。 至少请确保端口 122/TCP 和 1194/UDP 已打开,以便在实例的所有节点之间进行双向通信。 有关详细信息,请参阅“网络端口”。

主节点和副本节点之间的延迟不得超过 70 毫秒。 我们不建议在两个节点之间配置防火墙。 可以使用 ping 或其他网络管理实用工具来测试节点之间的网络连接。

复制不到位

如果在副本节点上运行 ghe-repl-status 命令行实用工具,并且 Git 存储库、存储库网络或存储对象的复制不到位,那么一个或多个副本节点会不与主节点充分同步。 如果主节点无法与副本节点通信,或者副本节点无法与主节点通信,则可能会出现复制不到位的情况。

如果最近配置了高可用性或异地复制,初始同步将需要一些时间。 初始同步的持续时间取决于存在的数据量和网络条件。

复制不到位的存储库或存储库网络

可以通过连接到节点并运行以下命令来查看特定存储库的复制状态,在使用命令时请将 OWNER 替换为存储库的所有者,并将 REPOSITORY 替换为存储库的名称。

ghe-spokesctl check OWNER/REPOSITORY
ghe-spokesctl info OWNER/REPOSITORY

或者,如果要查看存储库网络的复制状态,请将 NETWORK-ID/REPOSITORY-ID 替换为网络 ID 和存储库 ID 编号。

ghe-spokesctl check NETWORK-ID/REPOSITORY-ID
ghe-spokesctl info NETWORK-ID/REPOSITORY-ID

复制不到位的存储对象

可以通过连接到节点并运行以下命令(将 OID 替换为对象的 ID)来查看特定存储对象的状态。

ghe-storage info OID

从 GitHub

获取支持

如果已查看有关复制的故障排除建议且依然在实例上遇到问题,请收集以下信息,然后通过访问 GitHub Enterprise 支持 联系我们。

  • 在每个受影响的节点上运行 ghe-repl-status -vv,然后将输出复制到票证。 有关详细信息,请参阅“命令行实用程序”。
  • 在每个受影响的节点上,创建一个支持捆绑包以附加到票证。 有关详细信息,请参阅“向 GitHub 支持提供数据”。