Informationen zum Ersetzen von GitHub Enterprise Server-Clusterknoten
Du kannst in einem GitHub Enterprise Server-Cluster sowohl einen funktionierenden Knoten als auch einen Knoten ersetzen, der unerwartet ausgefallen ist.
Nachdem du einen Knoten ersetzt hast, verteilt Ihre GitHub Enterprise Server-Instance Aufträge nicht automatisch an den neuen Knoten. Du kannst erzwingen, dass deine Instanz Aufträge zwischen den Knoten ausgleicht. Weitere Informationen finden Sie unter Erneutes Ausgleichen von Clusterworkloads.
Warning
Verwende zum Vermeiden von Konflikten keinen Hostnamen erneut, der zuvor einem Knoten im Cluster zugewiesen wurde.
Funktionierenden Knoten ersetzen
Du kannst einen vorhandenen funktionalen Knoten in deinem Cluster ersetzen. Beispielsweise solltest du einen virtuellen Computer (VM) mit zusätzlichen CPU-, Arbeitsspeicher- oder Speicherressourcen bereitstellen.
Um einen funktionalen Knoten zu ersetzen, installiere die GitHub Enterprise Server-Anwendung auf einem neuen virtuellen Computer, konfiguriere eine IP-Adresse, füge den neuen Knoten der Clusterkonfigurationsdatei hinzu, initialisiere den Cluster, und wende die Konfiguration an. Schalte anschließend den ersetzten Knoten offline.
Note
Weitere Informationen zum Ersetzen des primären Datenbankknotens findest du unter Ersetzen des primären Datenbankknotens.
-
Bereitstellen und Installieren von GitHub Enterprise Server mit einem eindeutigen Hostnamen auf dem Ersetzungsknoten.
-
Konfiguriere mithilfe der Verwaltungsshell oder DHCP nur die IP-Adresse des Ersatzknotens. Konfiguriere keine anderen Einstellungen.
-
Um den neu verteilten Ersatzknoten hinzuzufügen, entferne auf einem beliebigen Knoten in der Datei
cluster.conf
den ausgefallenen Knoten, und füge den neuen Ersatzknoten hinzu. Diese geändertecluster.conf
-Datei ersetzt z. B.ghe-data-node-3
durch den neu bereitgestellten Knotenghe-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
Sie können das Datenbank-Seeding eines neuen MySQL-Replikationsknotens aufschieben, so dass Sie Ihre Anwendung früher für den Datenverkehr öffnen können. Weitere Informationen finden Sie unter Aufschieben des Datenbank-Seeding.
-
Führe aus der administrativen Shell des Knotens mit der geänderten
cluster.conf
ghe-cluster-config-init
aus. Dadurch wird der neu hinzugefügte Knoten im Cluster initialisiert. -
Führe auf demselben Knoten
ghe-cluster-config-apply
aus. Dadurch wird die Konfigurationsdatei validiert und auf jeden Knoten im Cluster kopiert. Außerdem wird jeder Knoten entsprechend der geänderten Dateicluster.conf
konfiguriert. -
Wenn du einen Knoten offline nimmst, der Datendienste wie
git-server
,pages-server
oderstorage-server
bereitstellt, evakuiere den Knoten. Weitere Informationen finden Sie unter Evakuieren eines Clusterknotens, auf dem Datendienste ausgeführt werden. -
Um den fehlgeschlagenen Knoten offline auf einem beliebigen Knoten zu markieren, ändere die Clusterkonfigurationsdatei (
cluster.conf
) im relevanten Knotenabschnitt, sodass der Textoffline = true
enthalten ist.Diese geänderte Datei
cluster.conf
markiert beispielsweise denghe-data-node-3
-Knoten als offline:[cluster "ghe-data-node-3"] hostname = ghe-data-node-3 offline = true ipv4 = 192.168.0.6 # ipv6 = fd12:3456:789a:1::6
-
Führe aus der administrativen Shell des Knotens, wo du
cluster.conf
geändert hast,ghe-cluster-config-apply
aus. Dadurch wird die Konfigurationsdatei validiert, auf jeden Knoten im Cluster kopiert und der Knoten als offline markiert.
Knoten in einem Notfall ersetzen
Du kannst einen fehlerhaften Knoten in deinem Cluster ersetzen. Beispielsweise kann sich ein Software- oder Hardwareproblem auf die Verfügbarkeit eines Knotens auswirken.
Note
Weitere Informationen zum Ersetzen des primären Datenbankknotens findest du unter Ersetzen des primären Datenbankknotens.
Um einen Knoten im Notfall zu ersetzen, installiere die GitHub Enterprise Server-Anwendung auf einer neuen VM, konfiguriere eine IP-Adresse, schalte den fehlerhaften Knoten offline, wende die Konfiguration an, füge den neuen Knoten der Clusterkonfigurationsdatei hinzu, initialisiere den Cluster, und wende die Konfiguration an. Evakuiere dann den fehlerhaften Knoten.
-
Bereitstellen und Installieren von GitHub Enterprise Server mit einem eindeutigen Hostnamen auf dem Ersetzungsknoten.
-
Konfiguriere mithilfe der Verwaltungsshell oder DHCP nur die IP-Adresse des Ersatzknotens. Konfiguriere keine anderen Einstellungen.
-
Um den fehlgeschlagenen Knoten offline auf einem beliebigen Knoten zu markieren, ändere die Clusterkonfigurationsdatei (
cluster.conf
) im relevanten Knotenabschnitt, sodass der Textoffline = true
enthalten ist.Diese geänderte Datei
cluster.conf
markiert beispielsweise denghe-data-node-3
-Knoten als offline:[cluster "ghe-data-node-3"] hostname = ghe-data-node-3 offline = true ipv4 = 192.168.0.6 # ipv6 = fd12:3456:789a:1::6
-
Führe aus der administrativen Shell des Knotens, wo du
cluster.conf
geändert hast,ghe-cluster-config-apply
aus. Dadurch wird die Konfigurationsdatei validiert, auf jeden Knoten im Cluster kopiert und der Knoten als offline markiert. -
Um den neu verteilten Ersatzknoten hinzuzufügen, entferne auf einem beliebigen Knoten in der Datei
cluster.conf
den ausgefallenen Knoten, und füge den neuen Ersatzknoten hinzu. Diese geändertecluster.conf
-Datei ersetzt z. B.ghe-data-node-3
durch den neu bereitgestellten Knotenghe-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
Sie können das Datenbank-Seeding eines neuen MySQL-Replikationsknotens aufschieben, so dass Sie Ihre Anwendung früher für den Datenverkehr öffnen können. Weitere Informationen finden Sie unter Aufschieben des Datenbank-Seeding.
-
Wenn du den primären Redis-Knoten ersetzt, ändere in
cluster.conf
denredis-master
-Wert in den Namen des Ersatzknotens.Note
Wenn dein primärer Redis-Knoten auch dein primärer MySQL-Knoten ist, findest du weitere Informationen unter Ersetzen des primären Datenbankknotens.
In dieser geänderten
cluster.conf
-Datei wird beispielsweise ein neu bereitgestellter Clusterknotenghe-replacement-data-node-1
als primärer Redis-Knoten angegeben:redis-master = ghe-replacement-data-node-1
-
Führe aus der administrativen Shell des Knotens mit der geänderten
cluster.conf
ghe-cluster-config-init
aus. Dadurch wird der neu hinzugefügte Knoten im Cluster initialisiert. -
Führe auf demselben Knoten
ghe-cluster-config-apply
aus. Dadurch wird die Konfigurationsdatei validiert und auf jeden Knoten im Cluster kopiert. Außerdem wird jeder Knoten entsprechend der geänderten Dateicluster.conf
konfiguriert. -
Wenn du einen Knoten offline nimmst, der Datendienste wie
git-server
,pages-server
oderstorage-server
bereitstellt, evakuiere den Knoten. Weitere Informationen finden Sie unter Evakuieren eines Clusterknotens, auf dem Datendienste ausgeführt werden.
Ersetzen des primären Datenbankknotens (MySQL bzw. MySQL und MSSQL)
Zum Bereitstellen von Datenbankdiensten braucht Ihr Cluster einen primären MySQL-Knoten und mindestens einen Replikat-MySQL-Knoten. Weitere Informationen finden Sie unter Informationen zu Clusterknoten.
Wenn für deinen Cluster GitHub Actions aktiviert ist, musst du in den folgenden Schritten auch die Angaben für MSSQL berücksichtigen.
Wenn du deinem primären MySQL-Knoten (bzw. MySQL- und MSSQL-Knoten) weitere Ressourcen zuweisen oder einen fehlerhaften Knoten ersetzen musst, kannst du deinem Cluster einen neuen Knoten hinzufügen. Füge zum Minimieren von Downtimes den neuen Cluster hinzu, repliziere die MySQL-Daten (bzw. MySQL- und MSSQL-Daten), und stufe ihn dann höher zum primären Knoten. Eine gewisse Downtime ist während des Höherstufungsvorgangs erforderlich.
-
Bereitstellen und Installieren von GitHub Enterprise Server mit einem eindeutigen Hostnamen auf dem Ersetzungsknoten.
-
Konfiguriere mithilfe der Verwaltungsshell oder DHCP nur die IP-Adresse des Ersatzknotens. Konfiguriere keine anderen Einstellungen.
-
Um eine Verbindung mit Ihre GitHub Enterprise Server-Instance herzustellen, stelle eine SSH-Verbindung mit einem beliebigen Knoten deines Clusters her. Führe auf deiner Arbeitsstation den folgenden Befehl aus. Ersetze HOSTNAME durch den Hostnamen des Knotens. Weitere Informationen finden Sie unter Auf die Verwaltungsshell (SSH) zugreifen.
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
Öffne die Cluster-Konfigurationsdatei aus
/data/user/common/cluster.conf
in einem Text-Editor. Beispielsweise kannst du Vim verwenden. Erstelle eine Sicherung der Dateicluster.conf
, bevor du die Datei bearbeitest.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
Die Clusterkonfigurationsdatei listet jeden Knoten unter einer
[cluster "HOSTNAME"]
-Überschrift auf. Fügen Sie eine neue Überschrift für den Knoten hinzu, geben Sie die Schlüssel-Wert-Paare für die Konfiguration ein und ersetzen Sie die Platzhalter durch tatsächliche Werte.- Stellen Sie sicher, dass das Schlüssel-Wert-Paar
mysql-server = true
enthalten ist. - Wenn GitHub Actions im Cluster aktiviert ist, musst du auch das Schlüssel-Wert-Paar
mssql-server = true
einschließen. - Der folgende Abschnitt ist ein Beispiel. Die Konfiguration Ihres Knotens kann anders aussehen.
... [cluster "HOSTNAME"] hostname = HOSTNAME ipv4 = IPV4-ADDRESS # ipv6 = IPV6-ADDRESS consul-datacenter = PRIMARY-DATACENTER datacenter = DATACENTER mysql-server = true redis-server = true ... ...
- Stellen Sie sicher, dass das Schlüssel-Wert-Paar
-
Führe aus der administrativen Shell des Knotens mit der geänderten
cluster.conf
ghe-cluster-config-init
aus. Dadurch wird der neu hinzugefügte Knoten im Cluster initialisiert. -
Führe aus der administrativen Shell des Knotens, wo du
cluster.conf
geändert hast,ghe-cluster-config-apply
aus. Der neu hinzugefügte Knoten wird zu einem MySQL-Replikatknoten, und alle anderen konfigurierten Dienste werden dort ausgeführt.Note
Beim vorherigen Ausschnitt wird nicht davon ausgegangen, dass GitHub Actions im Cluster aktiviert ist.
-
Warten Sie, bis die MySQL-Replikation abgeschlossen ist. Führen Sie
ghe-cluster-status -v
aus, um die MySQL-Replikation von einem beliebigen Knoten im Cluster zu überwachen.Wenn GitHub Actions im Cluster aktiviert ist, musst du warten, bis die MSSQL-Replikation abgeschlossen ist.
Kurz nach dem Hinzufügen des Knotens zum Cluster wird während des Abgleichs der Replikation möglicherweise ein Fehler für den Replikationsstatus angezeigt. Die Replikation kann Stunden dauern, je nach Auslastung der Instanz, der Menge der Datenbankdaten und dem Zeitpunkt, an dem die Instanz das letzte Mal einen Datenbank-Seed erzeugt hat.
-
Aktivieren Sie während des Zeitfensters für die geplante Wartung den Wartungsmodus. Weitere Informationen finden Sie unter Wartungsmodus aktivieren und planen.
-
Führe
ghe-cluster-status -v
aus, um sicherzustellen, dass die MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) von allen Knoten im Cluster abgeschlossen ist.Warning
Wenn du nicht wartest, bis die MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) abgeschlossen ist, riskierst du Datenverluste in deiner Instanz.
-
Führe den folgenden Befehl im primären MySQL-Knoten aus, um diesen in den schreibgeschützten Modus zu versetzen.
Shell echo "SET GLOBAL super_read_only = 1;" | sudo mysql
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
-
Warten Sie, bis die Global Transaction Identifiers (GTIDs) für den primären und Replikat-MySQL-Knoten identisch sind. Führe den folgenden Befehl in einem beliebigen Clusterknoten aus, um die GTIDs zu überprüfen.
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'
- Führe den folgenden Befehl aus, um zu überprüfen, ob die globale MySQL-Variable erfolgreich festgelegt wurde.
Shell echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
-
Wenn GitHub Actions im Cluster aktiviert ist, stelle eine SSH-Verbindung mit dem Knoten her, der zum neuen primären MSSQL-Knoten wird.
Shell ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
- Führe in einer
screen
-Sitzung den folgenden Code aus, um den MSSQL-Knoten zum neuen Knoten höherzustufen.
Shell /usr/local/share/enterprise/ghe-mssql-repl-promote
/usr/local/share/enterprise/ghe-mssql-repl-promote
Dadurch wird versucht, auf den aktuellen primären MSSQL-Knoten zuzugreifen und ein ordnungsgemäßes Failover auszuführen.
- Führe in einer
-
Nachdem die GTIDs des primären und Replikat-MySQL-Knotens übereinstimmen, aktualisieren Sie die Clusterkonfiguration, indem Sie die Clusterkonfigurationsdatei in
/data/user/common/cluster.conf
in einem Text-Editor öffnen.- Erstelle eine Sicherung der Datei
cluster.conf
, bevor du die Datei bearbeitest. - Entfernen Sie im Abschnitt
[cluster]
der obersten Ebene den Hostnamen für den ersetzten Knoten aus dem Schlüssel-Wert-Paarmysql-master
und weisen Sie stattdessen den neuen Knoten zu. Wenn der neue Knoten auch ein primärer Redis-Knoten ist, passen Sie das Schlüssel-Wert-Paarredis-master
an. - Wenn GitHub Actions im Cluster aktiviert ist, musst du auch das Schlüssel-Wert-Paar
mssql-server = true
einschließen.
[cluster] mysql-master = NEW-NODE-HOSTNAME redis-master = NEW-NODE-HOSTNAME primary-datacenter = primary ...
- Erstelle eine Sicherung der Datei
-
Starte eine
screen
-Sitzung in der Verwaltungsshell des Knotens, in der ducluster.conf
geändert hast, und führeghe-cluster-config-apply
aus. Durch diesen Befehl wird der Cluster neu konfiguriert, der neu hinzugefügte Knoten wird zum primären MySQL-Knoten höhergestuft, und der ursprüngliche primäre MySQL-Knoten wird in ein Replikat konvertiert.Note
Beim vorherigen Ausschnitt wird nicht davon ausgegangen, dass GitHub Actions im Cluster aktiviert ist.
-
Überprüfe den Status der MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) über einen beliebigen Knoten im Cluster, indem du
ghe-cluster-status -v
ausführst. -
Wenn GitHub Actions im Cluster aktiviert ist, führe den folgenden Befehl über den neuen MySQL- und MSSQL-Knoten aus.
Shell /usr/local/share/enterprise/ghe-repl-post-failover-mssql
/usr/local/share/enterprise/ghe-repl-post-failover-mssql
-
Wenn die MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) abgeschlossen ist, deaktiviere den Wartungsmodus über einen beliebigen Knoten im Cluster. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.