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

О замене узлов кластера GitHub Enterprise Server

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

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

Вы можете заменить существующий функциональный узел в кластере. Например, может потребоваться предоставить виртуальную машину с дополнительными ресурсами ЦП, памяти или хранилища.

Чтобы заменить функциональный узел, установите (модуль) GitHub Enterprise Server на новой виртуальной машине, настройте IP-адрес, добавьте новый узел в файл конфигурации кластера, инициализируйте кластер и примените конфигурацию, а затем перейдите в автономный режим.

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

Вы можете заменить неудающийся узел в кластере. Например, проблема с программным обеспечением или оборудованием может повлиять на доступность узла.

Чтобы заменить узел в чрезвычайных ситуациях, установите GitHub Enterprise Server (модуль) на новой виртуальной машине, настройте IP-адрес, отключите неисправный узел в автономном режиме, примените конфигурацию, добавьте новый узел в файл конфигурации кластера, инициализировать кластер и применить конфигурацию, а также при необходимости эвакуируйте неисправный узел.

1. Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.

2. Используя административную оболочку или DHCP, настройте только IP-адрес заменяющего узла. Не следует настраивать другие параметры.

3. Чтобы пометить узел со сбоем в автономном режиме, измените файл конфигурации кластера (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
   

4. В административной оболочке узла, в котором вы изменили cluster.conf, выполните команду ghe-cluster-config-apply. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и отметить узел как автономный.

5. Для добавления недавно подготовленного заменяющего узла на любом узле измените файл 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
   

6. Если вы заменяете основной узел Redis, cluster.confизмените redis-master значение с именем узла замены.

   Примечание. Если основной узел Redis также является основным узлом MySQL, см. статью "Замена основного узла MySQL".

   Например, этот измененный cluster.conf файл указывает только что подготовленный узел кластера в ghe-replacement-data-node-1 качестве основного узла Redis:

   redis-master = ghe-replacement-data-node-1
   

7. В административной оболочке узла с измененным cluster.conf выполните команду ghe-cluster-config-init. Эта команда инициализирует только что добавленный узел в кластере.

8. Выполните команду ghe-cluster-config-apply из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файлом cluster.conf.

9. Если вы принимаете узел в автономном режиме, предоставляющий службы данных, например git-server, pages-serverили storage-serverэвакуировать узел. Дополнительные сведения см. в разделе Эвакуирование узла кластера с службами данных.

Замена основного узла MySQL

Для предоставления служб баз данных кластеру требуется основной узел MySQL и по крайней мере один дополнительный узел MySQL. Дополнительные сведения см. в разделе Сведения об узлах кластера.

Если вы хотите предоставить виртуальную машину для основного узла MySQL с дополнительными ресурсами или если узел завершается сбоем, можно заменить узел. Чтобы свести к минимуму время простоя, добавьте новый узел в кластер, реплика включите данные MySQL, а затем продвигайте узел. Некоторые простои требуются во время продвижения.

1. Добавьте новый заголовок узла и введите пары "ключ-значение" для конфигурации, заменив заполнители фактическими значениями.

• Убедитесь, что вы включаете mysql-server = true пару "ключ-значение".
• В следующем разделе приведен пример, а конфигурация узла может отличаться.

   ...
   [cluster "HOSTNAME"]
     hostname = HOSTNAME
     ipv4 = IPV4-ADDRESS
     # ipv6 = IPV6-ADDRESS
     consul-datacenter = PRIMARY-DATACENTER
     datacenter = DATACENTER
     mysql-server = true
     redis-server = true
     ...
   ...
   

1. Дождитесь завершения реплика mySQL. Чтобы отслеживать реплика tion MySQL из любого узла в кластере, выполните командуghe-cluster-status -v.

   Вскоре после добавления узла в кластер может появиться сообщение об ошибке для состояния реплика в то время как реплика вытягивается. Репликация может занять несколько часов в зависимости от нагрузки экземпляра и последнего создания начального значения базы данных.

2. Во время запланированного периода обслуживания включите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

3. Убедитесь, что реплика tion MySQL завершена с любого узла в кластере, выполнив команду ghe-cluster-status -v.

   Предупреждение. Если вы не ожидаете завершения реплика mySQL, вы рискуете потерей данных в вашем экземпляре.

4. Чтобы задать текущий основной узел MySQL режимом только для чтения, выполните следующую команду из узлов экземпляра.

   Shell

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

5. Подождите, пока глобальные идентификаторы транзакций (GTID) на первичных и вторичных узлах MySQL идентичны. Чтобы проверка идентификаторы GTID, выполните следующую команду из любого узла экземпляра.

   Shell

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

6. После сопоставления gtID на первичных и вторичных узлах MySQL обновите конфигурацию кластера, открыв файл /data/user/common/cluster.conf конфигурации кластера в текстовом редакторе.

   • Создайте резервную копию cluster.conf файла перед изменением файла.
   • В разделе верхнего уровня [cluster] удалите имя узла для узла, который вы заменили из mysql-master пары "ключ-значение", а затем назначьте новый узел. Если новый узел также является первичным узлом Redis, измените redis-master пару "ключ-значение".

   [cluster]
     mysql-master = NEW-NODE-HOSTNAME
     redis-master = NEW-NODE-HOSTNAME
     primary-datacenter = primary
   ...
   

7. Проверьте состояние реплика mySQL из любого узла в кластере, выполнив команду ghe-cluster-status -v. 1.Если служба MySQL реплика завершена, от любого узла в кластере отключите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.