О замене узлов кластера GitHub Enterprise Server
Можно заменить функциональный узел в кластере GitHub Enterprise Server или заменить узел, который произошел сбой.
После замены узла ваш экземпляр GitHub Enterprise Server не автоматически распределяет задания на новый узел. Вы можете принудительно выполнить балансировку заданий экземпляра между узлами. Дополнительные сведения см. в разделе Перебалансирование рабочих нагрузок кластера.
Предупреждение. Чтобы избежать конфликтов, не используйте имя узла, которое ранее было назначено узлу в кластере.
Замена функционального узла
Вы можете заменить существующий функциональный узел в кластере. Например, может потребоваться предоставить виртуальную машину с дополнительными ресурсами ЦП, памяти или хранилища.
Чтобы заменить функциональный узел, установите (модуль) GitHub Enterprise Server на новой виртуальной машине, настройте IP-адрес, добавьте новый узел в файл конфигурации кластера, инициализируйте кластер и примените конфигурацию, а затем перейдите в автономный режим.
Примечание. Если вы заменяете основной узел MySQL, см. статью "Замена основного узла MySQL".
-
Чтобы перевести узел, который вы заменяете в автономном режиме, из основного узла MySQL кластера выполните следующую команду.
ghe-remove-node NODE-HOSTNAME
Эта команда будет эвакуировать данные из всех служб данных, работающих на узле, пометить узел как автономный в конфигурации и остановить маршрутизацию трафика на узел. Дополнительные сведения см. в разделе Служебные программы командной строки.
Замена узла в экстренной ситуации
Вы можете заменить неудающийся узел в кластере. Например, проблема с программным обеспечением или оборудованием может повлиять на доступность узла.
Примечание. Если вы заменяете основной узел MySQL, см. статью "Замена основного узла MySQL".
Чтобы заменить узел в чрезвычайной ситуации, вы будете использовать неработоспособный узел в автономном режиме, добавьте в кластер замены узел, а затем выполните команды, чтобы удалить ссылки на службы данных на удаленном узле.
-
Чтобы удалить узел, который сталкивается с проблемами из кластера, из основного узла MySQL кластера выполните следующую команду. Замените NODE-HOSTNAME именем узла, который вы принимаете в автономном режиме.
ghe-remove-node --no-evacuate NODE-HOSTNAME
Эта команда помечает узел как автономный в конфигурации и остановит трафик, который направляется на узел. Эту команду можно запустить в
no-evacuate
режиме, так как далее в этой процедуре вы запустите команды, которые указывают службам данных на узле копировать все реплика на другие доступные узлы в кластере. Дополнительные сведения см. в разделе Служебные программы командной строки. -
Добавьте узел замены в кластер.
-
Чтобы добавить недавно подготовленный узел замены на любом узле, измените
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
-
-
Удалите ссылки на службы данных на удаленном узле.
-
Найдите UUID удаленного узла. Чтобы найти идентификатор UUID, выполните следующую команду, заменив
HOSTNAME
имя узла узла. Этот идентификатор UUID будет использоваться на следующем шаге.ghe-config cluster.HOSTNAME.uuid
-
Чтобы удалить ссылки на службы данных, выполните следующие команды. Замените
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
запусков.-
Чтобы удалить запись из файла, выполните следующую команду, заменив
HOSTNAME
имя узла удаленного узла.ghe-config --remove-section "cluster.HOSTNAME"
-
Чтобы скопировать конфигурацию на другие узлы в кластере, из административной оболочки узла, в котором вы изменили,
cluster.conf
выполните командуghe-cluster-config-apply
.
-
Замена основного узла MySQL
Для предоставления служб баз данных кластеру требуется основной узел MySQL и по крайней мере один дополнительный узел MySQL. Дополнительные сведения см. в разделе Сведения об узлах кластера.
Если вы хотите предоставить виртуальную машину для основного узла MySQL с дополнительными ресурсами или если узел завершается сбоем, можно заменить узел. Чтобы свести к минимуму время простоя, добавьте новый узел в кластер, реплика включите данные MySQL, а затем продвигайте узел. Некоторые простои требуются во время продвижения.
- Добавьте новый заголовок узла и введите пары "ключ-значение" для конфигурации, заменив заполнители фактическими значениями.
- Убедитесь, что вы включаете
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 ... ...
-
Дождитесь завершения реплика mySQL. Чтобы отслеживать реплика tion MySQL из любого узла в кластере, выполните команду
ghe-cluster-status -v
.Вскоре после добавления узла в кластер может появиться сообщение об ошибке для состояния реплика в то время как реплика вытягивается. Репликация может занять несколько часов в зависимости от нагрузки экземпляра и последнего создания начального значения базы данных.
-
Во время запланированного периода обслуживания включите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
-
Убедитесь, что реплика tion MySQL завершена с любого узла в кластере, выполнив команду
ghe-cluster-status -v
.Предупреждение. Если вы не ожидаете завершения реплика 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'
-
После сопоставления 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 ...
- Создайте резервную копию
-
Проверьте состояние реплика mySQL из любого узла в кластере, выполнив команду
ghe-cluster-status -v
. 1.Если служба MySQL реплика завершена, от любого узла в кластере отключите режим обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.