替换集群节点

关于替换 GitHub Enterprise Server 群集节点

可以替换群集中的 GitHub Enterprise Server 功能节点，也可以替换意外失败的节点。

替换节点后，你的 GitHub Enterprise Server 实例不会自动将作业分发到新节点。您可以强制让实例在不同节点之间实现作业均衡。有关详细信息，请参阅“重新均衡群集工作负荷”。

警告

为避免冲突，请勿重复使用群集中的节点曾使用过的主机名。

替换功能节点

可以替换群集中现有的功能节点。例如，需要为虚拟机 (VM) 提供额外的 CPU、内存或存储资源时。

若要替换功能节点，请在 GitHub Enterprise Server 新 VM 上安装设备、配置 IP 地址、将新节点添加到群集配置文件、初始化群集并应用配置，然后删除替换的节点。

在开始更换前，请在每个群集节点（包括替换节点）上安装适用于您的功能版本的最新补丁版本。每个节点必须运行相同的确切版本。等待任何升级或配置运行完成，然后再开始替换。

注意

如果要替换主数据库节点，请参阅替换主数据库节点。

          [在替换节点上预配并安装 GitHub Enterprise Server](/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance)，并使用唯一的主机名。

使用管理 shell 或 DHCP，仅配置替换节点的 IP 地址。不要配置任何其他设置。
若要添加新预配的替换节点，可在任何节点上修改 cluster.conf 文件以添加替换节点。请保留将在 cluster.conf 中替换的节点，直到在本过程中稍后运行 ghe-remove-node 为止。例如，此修改cluster.conf的文件添加新预配的节点： ghe-replacement-data-node-3
```
[cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
```
您可以选择延迟对新 MySQL 副本节点进行数据库初始化，从而使您的设备能够更早开始接收流量。有关详细信息，请参阅“延迟数据库初始化”。
从含有经修改 cluster.conf 的节点的管理 shell 中，运行 ghe-cluster-config-init。这将初始化集群中新增的节点。
从同一节点中运行 ghe-cluster-config-apply。这将验证配置文件、将其复制到集群中的每个节点以及根据修改的 cluster.conf 文件配置每个节点。
若要从群集的主 MySQL 节点中删除要替换的节点，请运行以下命令。
```
ghe-remove-node NODE-HOSTNAME
```
此命令从节点上运行的任何数据服务中疏散数据，清空其工作负荷，从群集配置中删除节点，应用更改，并阻止流量路由到节点。有关详细信息，请参阅“命令行实用程序”。

在紧急情况下替换节点

可以替换群集中发生故障的节点。例如，发生了可能会影响节点可用性的软件或硬件问题时。

注意

如果要替换主数据库节点，请参阅替换主数据库节点。

若要在紧急情况下替换节点，请将失败的节点设为离线，将替换节点添加到群集，然后运行命令以删除对已删除节点上数据服务的引用。

在开始替换之前，请确认集群中将保留的所有可用节点均已运行与当前功能版本对应的最新补丁版本。在替换节点上安装该确切版本。如果剩余节点尚未运行该版本，请先联系 GitHub 支持，然后再继续。等待任何正在进行的升级或配置运行任务完成。

若要从群集中删除遇到问题的节点，请从群集的主 MySQL 节点运行以下命令。将 NODE-HOSTNAME 替换为正在设为离线的节点的主机名。
```
ghe-remove-node --no-evacuate NODE-HOSTNAME
```
此命令将在配置中将节点标记为离线，并停止将流量路由到该节点。现在可以在 no-evacuate 模式下运行此命令，因为在此过程的后面，你将运行命令来指示节点上的数据服务将任何副本复制到群集中的其他可用节点上。有关详细信息，请参阅“命令行实用程序”。
将替换节点添加到群集。
1. ```
          [在替换节点上预配并安装 GitHub Enterprise Server](/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance)，并使用唯一的主机名。
```
2. 使用管理 shell 或 DHCP，仅配置替换节点的 IP 地址。不要配置任何其他设置。
3. 若要添加新预配的替换节点，可在任何节点上修改 cluster.conf 文件以添加替换节点。例如，修改后的 cluster.conf 文件会将添加新预配的节点 ghe-replacement-data-node-3：
```
[cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
```
4. 从含有经修改 cluster.conf 的节点的管理 shell 中，运行 ghe-cluster-config-init。这将初始化集群中新增的节点。
5. 从同一节点中运行 ghe-cluster-config-apply。这将验证配置文件、将其复制到集群中的每个节点以及根据修改的 cluster.conf 文件配置每个节点。
删除对已移除节点上数据服务的引用。
1. 查找已移除的节点的 UUID。若要查找 UUID，请运行以下命令，将 HOSTNAME 替换为节点的主机名。你将在下一个步骤中使用此 UUID。
```
ghe-config cluster.HOSTNAME.uuid
```
2. 若要删除对数据服务的引用，请运行以下命令。将 UUID 替换为节点的 UUID。
  
  这些命令将向每个服务指示该节点已被永久删除。这些服务将在群集内的可用节点上重新创建节点内包含的任何副本。
  
  注意
  
  在跨副本重新平衡数据时，这些命令可能会导致服务器负载增加。
  
  对于 git-server 服务（用于存储库数据）：
```
ghe-spokesctl server destroy git-server-UUID
```
  对于 pages-server 服务（用于 GitHub Pages 站点生成）：
```
ghe-dpages remove pages-server-UUID
```
  对于 storage-server 服务（用于 Git LFS 数据、虚拟形象图像、文件附件和发布存档）：
```
ghe-storage destroy-host storage-server-UUID --force
```
（可选）删除 cluster.conf 文件中已移除节点的项。这样做可以使 cluster.conf 文件井井有条，并在以后 config-apply 运行中节省时间。
1. 若要从文件中删除该条目，请运行以下命令，并将 HOSTNAME 替换为已移除节点的主机名。
```
ghe-config --remove-section "cluster.HOSTNAME"
```
2. 若要将配置复制到群集中的其他节点，请从修改 cluster.conf 的节点的管理 shell 运行 ghe-cluster-config-apply。

替换主数据库节点（MySQL 或 MySQL 和 MSSQL）

若要提供数据库服务，群集需要主 MySQL 节点和至少一个副本 MySQL 节点。有关详细信息，请参阅“关于集群节点”。

如果群集已启用 GitHub Actions，则还需要在以下步骤中考虑 MSSQL。

如果需要将更多资源分配给主 MySQL（或 MySQL 和 MSSQL）节点或替换失败的节点，则可以向群集添加新节点。若要最大程度地减少停机时间，请添加新节点、复制 MySQL（或 MySQL 和 MSSQL）数据，然后将其提升到主节点。升级期间需要停机一段时间。

          [在替换节点上预配并安装 GitHub Enterprise Server](/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance)，并使用唯一的主机名。

使用管理 shell 或 DHCP，仅配置替换节点的 IP 地址。不要配置任何其他设置。
若要连接到你的 GitHub Enterprise Server 实例，请通过 SSH 连接到群集的任何节点。在工作站中运行以下命令。将 HOSTNAME 替换为节点的主机名。有关详细信息，请参阅“访问管理 shell (SSH)”。
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
在文本编辑器中，打开位于 /data/user/common/cluster.conf 的群集配置文件。例如，您可以使用 Vim。在编辑文件之前创建 cluster.conf 文件的备份。
Shell
```
sudo vim /data/user/common/cluster.conf
```
```
sudo vim /data/user/common/cluster.conf
```
群集配置文件在 [cluster "HOSTNAME"] 标题下列出每个节点。为节点添加新标题并输入配置的键值对，并将占位符替换为实际值。
- 确保包含了 mysql-server = true 键值对。
- 如果在群集中启用了GitHub Actions，则必须同时包含mssql-server = true键值对。
- 以下部分是一个示例，且节点的配置可能有所不同。
```
...
[cluster "HOSTNAME"]
  hostname = HOSTNAME
  ipv4 = IPV4-ADDRESS
  # ipv6 = IPV6-ADDRESS
  consul-datacenter = PRIMARY-DATACENTER
  datacenter = DATACENTER
  mysql-server = true
  redis-server = true
  ...
...
```
从含有经修改 cluster.conf 的节点的管理 shell 中，运行 ghe-cluster-config-init。这将初始化集群中新增的节点。
从修改 cluster.conf 的节点的管理 shell 中，运行 ghe-cluster-config-apply。新添加的节点将成为副本 MySQL 节点，配置的任何其他服务都将在那里运行。

注意

前面的代码片段不假定 GitHub Actions 在群集中已启用。
等待 MySQL 复制完成。若要从群集中的任何节点监视 MySQL 复制，请运行 ghe-cluster-status -v。

如果在 GitHub Actions 群集中启用，则必须等待 MSSQL 复制完成。

将节点添加到群集后不久，可能会在复制恢复时看到复制状态错误。复制可能需要几个小时，具体取决于实例的负载、数据库数据量以及实例上次生成数据库种子的时间。
在计划性维护时段内，启用维护模式。有关详细信息，请参阅“启用和排定维护模式”。
通过运行 ghe-cluster-status -v，确保从群集中的任意节点完成 MySQL（或 MySQL 和 MSSQL）的复制。

警告

如果不等待 MySQL（或 MySQL 和 MSSQL）复制完成，则实例上可能会丢失数据。

要将当前 MySQL 主节点设置为只读模式，请从 MySQL 主节点运行以下命令。

Shell

echo "SET GLOBAL super_read_only = 1;" | sudo mysql

echo "SET GLOBAL super_read_only = 1;" | sudo mysql

等待直至在主要和副本 MySQL 节点上设置的全局事务标识符 (GTID) 相同。若要检查 GTID，请从任何群集节点运行以下命令。

Shell

ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'

ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'

要检查是否已成功设置全局 MySQL 变量，请运行以下命令。

Shell

 echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql

 echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql

如果在群集中已启用 GitHub Actions，请使用 SSH 登录到计划成为新的主 MSSQL 节点的节点。
Shell
```
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
```
```
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
```
- 在 screen 会话中运行以下命令，将 MSSQL 提升到新节点。
Shell
```
/usr/local/share/enterprise/ghe-mssql-repl-promote
```
```
/usr/local/share/enterprise/ghe-mssql-repl-promote
```
这会尝试访问当前主 MSSQL 节点并执行正常故障转移。
如果新节点也将成为主 Redis 节点，请在继续之前确认新节点是正常的已捕获 Redis 副本。从群集中的任何节点运行以下命令。
Shell
```
ghe-cluster-status-redis -v
```
```
ghe-cluster-status-redis -v
```
确认新节点的条目报告 ok ，并且 Redis replication is in sync当前主 Redis 节点的条目也报告 ok。

警告

不要设置为 redis-master 不是捕获副本的节点。如果这样做，群集可以将当前主 Redis 节点重新配置为新节点的副本，并放弃尚未复制的任何数据。

ghe-cluster-status-redis 报告同步新鲜度，而不是确切的复制偏移量。在下一步中编辑 redis-master 之前，立即查找当前主 Redis 节点的主机名。由于 mysql-master 已 redis-master 独立配置，因此当前主 Redis 节点不一定是要替换的数据库节点。

Shell

ghe-config cluster.redis-master

ghe-config cluster.redis-master

然后直接比较偏移量，替换为 NEW-NODE-HOSTNAME 新节点的主机名以及 CURRENT-REDIS-MASTER-HOSTNAME 上一命令中的值。首先检查新节点，然后检查当前主 Redis 节点，以便匹配反映主节点的最新状态。

Shell

ghe-redis-cli --remote -h NEW-NODE-HOSTNAME INFO replication
ghe-redis-cli --remote -h CURRENT-REDIS-MASTER-HOSTNAME INFO replication

ghe-redis-cli --remote -h NEW-NODE-HOSTNAME INFO replication
ghe-redis-cli --remote -h CURRENT-REDIS-MASTER-HOSTNAME INFO replication

确认新节点 slave_repl_offset 的值与当前主 Redis 节点 master_repl_offset 的值匹配。如果值不匹配，请等待并再次检查。在偏移量匹配之前不要继续。

当主节点和副本 MySQL 节点上的 GTID 匹配后，通过在文本编辑器中的 /data/user/common/cluster.conf 处打开群集配置文件来更新群集配置。
- 在编辑文件之前创建 cluster.conf 文件的备份。
- 在顶级 [cluster] 部分中，从 mysql-master 键值对中删除已替换节点的主机名，然后为新节点分配主机名。如果新节点也是主 Redis 节点，则仅在上一步骤中的复制检查确认偏移匹配后调整 redis-master 键值对。
- 如果在群集中启用了GitHub Actions，则必须同时包含mssql-server = true键值对。
```
[cluster]
  mysql-master = NEW-NODE-HOSTNAME
  redis-master = NEW-NODE-HOSTNAME
  primary-datacenter = primary
...
```
从修改了 cluster.conf 的节点的管理 shell 中，启动一个 screen 会话并运行 ghe-cluster-config-apply。此命令将重新配置群集，将新添加的节点提升到主 MySQL 节点，并将原始主 MySQL 节点转换为副本。

注意

前面的代码片段不假定 GitHub Actions 在群集中已启用。

如果在 GitHub Actions 群集中启用，请从新的 MySQL 和 MSSQL 节点运行以下命令。

Shell

/usr/local/share/enterprise/ghe-repl-post-failover-mssql

/usr/local/share/enterprise/ghe-repl-post-failover-mssql

如果已更改 redis-master，请确认新的主 Redis 节点正在为流量提供服务，并且以前的主 Redis 节点已重新配置为正常运行的副本。运行以下命令。
Shell
```
ghe-redis-cli PING
ghe-cluster-status-redis -v
```
```
ghe-redis-cli PING
ghe-cluster-status-redis -v
```
确认ghe-redis-cli PING``PONG通过默认 HAProxy Redis 终结点、新节点的条目报告ok以及以前的主 Redis 节点的条目报告ok以及返回Redis replication is in sync。
通过运行 ghe-cluster-status -v，检查群集中任何节点的 MySQL（或 MySQL 和 MSSQL）复制的状态。
完成 MySQL（或 MySQL 和 MSSQL）复制后，从群集中的任何节点禁用维护模式。请参阅“启用和排定维护模式”。

谁可以使用此功能？

在本文中

关于替换 GitHub Enterprise Server 群集节点

替换功能节点

在紧急情况下替换节点

替换主数据库节点（MySQL 或 MySQL 和 MSSQL）