О замене узлов кластера GitHub Enterprise Server
Можно заменить функциональный узел в кластере GitHub Enterprise Server или заменить узел, который произошел сбой.
После замены узла ваш экземпляр GitHub Enterprise Server не автоматически распределяет задания на новый узел. Вы можете принудительно выполнить балансировку заданий экземпляра между узлами. Дополнительные сведения см. в разделе Перебалансирование рабочих нагрузок кластера.
Warning
Чтобы избежать конфликтов, не используйте имя узла, которое ранее было назначено узлу в кластере.
Замена функционального узла
Вы можете заменить существующий функциональный узел в кластере. Например, может потребоваться предоставить виртуальную машину с дополнительными ресурсами ЦП, памяти или хранилища.
Чтобы заменить функциональный узел, установите устройство GitHub Enterprise Server на новой виртуальной машине, настройте IP-адрес, добавьте новый узел в файл конфигурации кластера, инициализируйте кластер и примените конфигурацию, а затем перейдите в автономный режим.
Note
Если вы заменяете узел базы данных-источника, см . раздел "Замена узла базы данных-источника".
- Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.
- Для добавления недавно подготовленного заменяющего узла на любом узле измените файл
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 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
выполните командуghe-cluster-config-init
. Эта команда инициализирует только что добавленный узел в кластере. -
Выполните команду
ghe-cluster-config-apply
из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файломcluster.conf
.
Замена узла в экстренной ситуации
Вы можете заменить неудающийся узел в кластере. Например, проблема с программным обеспечением или оборудованием может повлиять на доступность узла.
Note
Если вы заменяете узел базы данных-источника, см . раздел "Замена узла базы данных-источника".
Чтобы заменить узел в чрезвычайной ситуации, установите устройство GitHub Enterprise Server на новой виртуальной машине, настройте IP-адрес, отключите неисправный узел, примените конфигурацию, добавьте новый узел в файл конфигурации кластера, инициализируйте кластер и примените конфигурацию, а также при необходимости эвакуируйте неисправный узел.
-
Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.
-
Используя административную оболочку или DHCP, настройте только IP-адрес заменяющего узла. Не следует настраивать другие параметры.
-
Чтобы пометить узел со сбоем в автономном режиме, измените файл конфигурации кластера (
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
-
В административной оболочке узла, в котором вы изменили
cluster.conf
, выполните командуghe-cluster-config-apply
. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и отметить узел как автономный. -
Для добавления недавно подготовленного заменяющего узла на любом узле измените файл
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 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, что приведет к тому, что устройство будет открываться для трафика раньше. Дополнительные сведения см. в разделе Отсрочка заполнения базы данных.
-
Если вы заменяете основной узел Redis,
cluster.conf
изменитеredis-master
значение с именем узла замены.Note
Если основной узел Redis также является основным узлом MySQL, см. раздел "Замена узла базы данных-источника".
Например, этот измененный
cluster.conf
файл указывает только что подготовленный узел кластера вghe-replacement-data-node-1
качестве основного узла Redis:redis-master = ghe-replacement-data-node-1
-
В административной оболочке узла с измененным
cluster.conf
выполните командуghe-cluster-config-init
. Эта команда инициализирует только что добавленный узел в кластере. -
Выполните команду
ghe-cluster-config-apply
из того же узла. Это позволит проверить файл конфигурации, скопировать его на каждый узел в кластере и настроить каждый узел в соответствии с измененным файломcluster.conf
. -
Если вы принимаете узел в автономном режиме, предоставляющий службы данных, например
git-server
,pages-server
илиstorage-server
эвакуировать узел. Дополнительные сведения см. в разделе Эвакуирование узла кластера с службами данных.
Замена узла базы данных-источника (MySQL или MySQL и MSSQL)
Для предоставления служб базы данных кластеру требуется основной узел MySQL и по крайней мере один узел MySQL. Дополнительные сведения см. в разделе Сведения об узлах кластера.
Если в кластере включен GitHub Actions, необходимо также учесть MSSQL на следующих шагах.
Если вам нужно выделить дополнительные ресурсы для основного узла MySQL (или MySQL и MSSQL) или заменить неработоспособный узел, можно добавить новый узел в кластер. Чтобы свести к минимуму время простоя, добавьте новый узел, реплицируйте данные MySQL (или MySQL и MSSQL), а затем добавьте его в основной узел. Некоторые простои требуются во время процесса продвижения.
- Подготовьте и установите GitHub Enterprise Server с уникальным именем узла на заменяемом узле.
- Откройте файл
/data/user/common/cluster.conf
конфигурации кластера в текстовом редакторе. Например, можно использовать редактор Vim. Создайте резервную копиюcluster.conf
файла перед изменением файла.
sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
- Добавьте новый заголовок узла и введите пары "ключ-значение" для конфигурации, заменив заполнители фактическими значениями.
- Убедитесь, что вы включаете
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
выполните командуghe-cluster-config-init
. Эта команда инициализирует только что добавленный узел в кластере. -
В административной оболочке узла, в котором вы изменили
cluster.conf
, выполните командуghe-cluster-config-apply
. Недавно добавленный узел станет репликой узла MySQL, и все другие настроенные службы будут запускаться там.Note
В предыдущем фрагменте не предполагается, что в кластере включен GitHub Actions.
-
Дождитесь завершения репликации MySQL. Чтобы отслеживать репликацию MySQL с любого узла в кластере, выполните команду
ghe-cluster-status -v
.Если в кластере включена GitHub Actions, вам придется ждать завершения репликации MSSQL.
Вскоре после добавления узла в кластер может появиться ошибка состояния репликации во время перехвата репликации. Репликация может занять несколько часов в зависимости от нагрузки экземпляра, объема данных базы данных и последнего создания начального значения базы данных.
-
Во время запланированного периода обслуживания включите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
-
Убедитесь, что репликация MySQL (или MySQL и MSSQL) завершена с любого узла в кластере, выполнив команду
ghe-cluster-status -v
.Warning
Если репликация MySQL (или MySQL и MSSQL) не завершится, вы рискуете потерей данных в экземпляре.
-
Чтобы задать текущий основной узел MySQL режимом только для чтения, выполните следующую команду из первичного узла MySQL.
Shell echo "SET GLOBAL super_read_only = 1;" | sudo mysql
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
-
Подождите, пока глобальные идентификаторы транзакций (GTID) на первичных узлах MySQL и реплики идентичны. Чтобы проверить идентификаторы 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 и выполнить правильную отработку отказа
- В сеансе
-
После сопоставления GTID на первичных и репликах узлов MySQL обновите конфигурацию кластера, открыв файл
/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
, запуститеscreen
сеанс и запустите егоghe-cluster-config-apply
. Эта команда перенастраивает кластер, повышая только что добавленный узел к основному узлу MySQL и преобразуя исходный первичный узел MySQL в реплику.Note
В предыдущем фрагменте не предполагается, что в кластере включен GitHub Actions.
-
Проверьте состояние репликации MySQL (или MySQL и MSSQL) с любого узла в кластере, выполнив команду
ghe-cluster-status -v
. -
Если GitHub Actions включен в кластере, выполните следующую команду из нового узла MySQL и MSSQL.
Shell /usr/local/share/enterprise/ghe-repl-post-failover-mssql
/usr/local/share/enterprise/ghe-repl-post-failover-mssql
-
После завершения репликации MySQL (или MySQL и MSSQL) от любого узла в кластере отключите режим обслуживания. См . раздел AUTOTITLE.