Diese Version von GitHub Enterprise Server wird eingestellt am 2024-09-24. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Initiieren eines Failovers zu Ihrem Replikatcluster

Wenn bei deinem GitHub Enterprise Server-Cluster ein Fehler auftritt, können Sie Failover zum Replikat ausführen.

In diesem Artikel

Informationen zu einem Failover zu deinem Replikatcluster

Wenn das Rechenzentrum für Ihren aktiven Cluster einen Fehler verursacht und Sie hohe Verfügbarkeit konfiguriert haben, können Sie ein Failover zum Replikatcluster ausführen.

Wenn Sie ein Failover zu Ihrem Replikatcluster ausführen, wird dieser zu Ihrem neuen aktiven Cluster heraufgestuft, und der neue aktive Cluster wird vom alten aktiven Cluster entkoppelt. Die Knoten in Ihrem alten aktiven Cluster werden in den Wartungsmodus versetzt, wenn sie sich in einem ausreichend fehlerfreien Zustand befinden, um diesen Vorgang auszuführen.

Nach dem Failover verfügen Sie über zwei eigenständige Cluster, ohne dass hohe Verfügbarkeit konfiguriert ist. Sie können die Replikation von dem neuen aktiven Cluster neu konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der Hochverfügbarkeitsreplikation für einen Cluster.

Voraussetzungen

Um ein Failover zu Replikatknoten auszuführen, müssen Sie hohe Verfügbarkeit für Ihren Cluster konfiguriert haben. Weitere Informationen findest du unter Konfigurieren der Hochverfügbarkeitsreplikation für einen Cluster.

Initiieren eines Failovers zu Ihrem Replikatcluster

Note

In einer Instanz in einer Clusterkonfiguration konnten frühere primäre Knoten nach dem Failover auf die neu heraufgestuften Knoten zugreifen. Dies wurde im Patch-Release 3.10.10 behoben. Weitere Informationen finden Sie unter „Versionshinweise.“

Als Ergebnis dieser Behebung identifiziert ghe-cluster-failover die IP-Adressen, die im alten primären Cluster blockiert werden sollen, und schreibt sie in /data/user/common/cluster-ip-blocklist. Nach Abschluss des Failovers führt der Befehl ghe-cluster-block-ips aus, um die IP-Adressen im neuen aktiven Cluster zu blockieren.

Darüber hinaus wurden in diesen Patch-Releases die Befehle ghe-cluster-block-ips, ghe-cluster-block-ip, ghe-cluster-unblock-ips und ghe-cluster-unblock-ip eingeführt. Mit diesen Befehlen können Sie manuell festlegen, welche IP-Adressen auf den neu höhergestuften Cluster zugreifen können. Außerdem können Sie so die potenziell langwierige Konfiguration vermeiden, die mit dem Ausführen des gesamten Befehls ghe-cluster-failover verbunden ist. Weitere Informationen finden Sie unter „Befehlszeilenprogramme“.

  1. Verwenden Sie SSH in den primären MySQL-Knoten im Replikatcluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.

  2. Führen Sie den folgenden Befehl aus, um mit dem Failover auf den sekundären Cluster zu beginnen und die Knoten so zu konfigurieren, dass sie auf Anfragen reagieren.

    ghe-cluster-failover

  3. Nachdem die Konfigurationsausführung abgeschlossen ist, zeigt GitHub Enterprise Server die folgende Meldung an.

    Finished cluster configuration

  4. Aktualisieren Sie den DNS-Eintrag so, dass er auf die IP-Adresse des Lastenausgleichs für Ihren Replikatcluster zeigt. Nach Ablauf des TTL-Zeitraums werden Anfragen an den Replikatcluster weitergeleitet.

Nachdem Sie durch GitHub Enterprise Server Sie zur Eingabeaufforderung zurückgekehrt sind und die DNS-Updates übertragen wurden, ist das Failover abgeschlossen. Benutzer können mithilfe des üblichen Hostnamens für deinen Cluster auf GitHub Enterprise Server zugreifen.