Замена узла кластера

Сведения о замене узлов кластера

Можно заменить функциональный узел в кластере или узел, который неожиданно завершился сбоем.

Предупреждение: Чтобы избежать конфликтов, заменяющий узел должен использовать новое имя узла, которое ранее не использовалось в кластере.

Замена функционального узла

Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле. 1. Используя административную оболочку или DHCP, настройте только IP-адрес заменяющего узла. Не следует настраивать другие параметры. 1. Для добавления недавно подготовленного заменяющего узла на любом узле измените файл cluster.conf, чтобы удалить узел со сбоем и добавить заменяющий. Например, этот измененный файл cluster.conf заменяет ghe-data-node-3 только что подготовленным узлом 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
```
1. В административной оболочке узла с измененным `cluster.conf` выполните команду `ghe-cluster-config-init`. Эта команда инициализирует только что добавленный узел в кластере. 1. Выполните команду `ghe-cluster-config-apply` из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файлом `cluster.conf`. 1. Если вы переводите узел в автономный режим, предоставляющий службы данных, такие как `git-server`, `pages-server`или `storage-server`, эвакуировать узел. Дополнительные сведения см. в разделе [AUTOTITLE](/admin/enterprise-management/configuring-clustering/evacuating-a-cluster-node-running-data-services). 1. Чтобы пометить узел со сбоем в автономном режиме, измените [файл конфигурации кластера](/admin/enterprise-management/configuring-clustering/initializing-the-cluster#about-the-cluster-configuration-file) (`cluster.conf`) в соответствующем разделе узла для включения текста `offline = true`.
Например, этот измененный cluster.conf помечает узел как автономный ghe-data-node-3:
```
  [cluster "ghe-data-node-3"]
  hostname = ghe-data-node-3
  offline = true
  ipv4 = 192.168.0.6
  # ipv6 = fd12:3456:789a:1::6
  
```
1. В административной оболочке узла, в котором вы изменили `cluster.conf`, выполните команду `ghe-cluster-config-apply`. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и отметить узел как автономный. 1. Если вы заменяете основной узел MySQL или Redis, в `cluster.conf` измените значение `mysql-master` или `redis-master` на имя узла для замены.
Например, в следующем измененном файле cluster.conf новый подготовленный узел кластера ghe-replacement-data-node-1 указан в качестве основного узла MySQL и Redis:
```
mysql-master = ghe-replacement-data-node-1
redis-master = ghe-replacement-data-node-1
```

Замена узла в экстренной ситуации

Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле. 1. Используя административную оболочку или DHCP, настройте только IP-адрес заменяющего узла. Не следует настраивать другие параметры. 1. Чтобы пометить узел со сбоем в автономном режиме, измените файл конфигурации кластера (cluster.conf) в соответствующем разделе узла для включения текста offline = true.

Например, этот измененный cluster.conf помечает узел как автономный ghe-data-node-3:
```
  [cluster "ghe-data-node-3"]
  hostname = ghe-data-node-3
  offline = true
  ipv4 = 192.168.0.6
  # ipv6 = fd12:3456:789a:1::6
  
```
1. В административной оболочке узла, в котором вы изменили `cluster.conf`, выполните команду `ghe-cluster-config-apply`. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и отметить узел как автономный. 1. Для добавления недавно подготовленного заменяющего узла на любом узле измените файл `cluster.conf`, чтобы удалить узел со сбоем и добавить заменяющий. Например, этот измененный файл `cluster.conf` заменяет `ghe-data-node-3` только что подготовленным узлом `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
```
1. Если вы заменяете основной узел MySQL или Redis, в `cluster.conf` измените значение `mysql-master` или `redis-master` на имя узла для замены.
Например, в следующем измененном файле cluster.conf новый подготовленный узел кластера ghe-replacement-data-node-1 указан в качестве основного узла MySQL и Redis:
```
mysql-master = ghe-replacement-data-node-1
redis-master = ghe-replacement-data-node-1
```
1. В административной оболочке узла с измененным `cluster.conf` выполните команду `ghe-cluster-config-init`. Эта команда инициализирует только что добавленный узел в кластере. 1. Выполните команду `ghe-cluster-config-apply` из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файлом `cluster.conf`. 1. Если вы переводите узел в автономный режим, предоставляющий службы данных, такие как `git-server`, `pages-server`или `storage-server`, эвакуировать узел. Дополнительные сведения см. в разделе [AUTOTITLE](/admin/enterprise-management/configuring-clustering/evacuating-a-cluster-node-running-data-services).

Замена узла кластера

В этой статье

Сведения о замене узлов кластера

Замена функционального узла

Замена узла в экстренной ситуации