Skip to main content

Enterprise Server 3.20 ist derzeit als Release Candidate verfügbar.

Initiieren eines Failovers zu deiner Replikat-Appliance

Du kannst an der Befehlszeile zu Wartungs- und Testzwecken oder beim Fehlschlagen der primären Appliance ein Failover zu einer GitHub Enterprise Server-Replikat-Appliance durchführen.

Die für das Failover erforderliche Zeit hängt davon ab, wie lange es dauert, das Replikat manuell hochzustufen und den Traffic weiterzuleiten. Die durchschnittliche Dauer liegt zwischen 20–30 Minuten.

  1. Wenn die primäre Appliance verfügbar ist, versetze die primäre Appliance in den Wartungsmodus, damit die Replikation abgeschlossen werden kann, bevor du die Geräte wechselst.

    • Versetze die Appliance in den Wartungsmodus.

      • Weitere Informationen zum Verwenden der Verwaltungskonsole findest du unter Wartungsmodus aktivieren und planen.

      • Du kannst auch den Befehl ghe-maintenance -s verwenden.

        ghe-maintenance -s
        
    • Wenn die Anzahl der aktiven Git-Vorgänge, MySQL-Abfragen und Resque-Aufträge null erreicht, warte 30 Sekunden.

      Hinweis

      In Nomad werden immer Aufträge ausgeführt, auch im Wartungsmodus. Daher kannst du diese Aufträge gefahrlos ignorieren.

    • Um alle Replikationskanäle zu überprüfen und OK zu melden, verwende den Befehl ghe-repl-status -vv.

      ghe-repl-status -vv
      
  2. Aktivieren Sie den Wartungsmodus für alle aktiven Replikat-Appliances. Weitere Informationen finden Sie unter Wartungsmodus aktivieren und planen.

  3. Verwenden Sie auf der Replikat-Appliance, auf die Sie ein Failover ausführen möchten, zum Beenden der Replikation und zum Hochstufen der Replikat-Appliance auf den Status „primär“ den Befehl ghe-repl-promote.

    ghe-repl-promote
    

    Hinweis

    Wenn der primäre Knoten nicht verfügbar ist, können Warnungen und Timeouts auftreten, die jedoch ignoriert werden können.

  4. Aktualisiere den DNS-Eintrag so, dass er auf die IP-Adresse des Replikats verweist. Nach dem Verstreichen des TTL-Zeitraums wird der Traffic an das Replikat geleitet. Stelle bei der Verwendung eines Load-Balancers sicher, dass er so konfiguriert ist, den Traffic an das Replikat zu senden.

  5. Benachrichtige die Benutzer, dass sie die normalen Vorgänge wieder aufnehmen können.

  6. Richte bei Bedarf die Replikation von der neuen primären Instanz auf die bestehenden Appliances und die vorherige primäre Instanz ein. Weitere Informationen finden Sie unter Informationen zur Hochverfügbarkeitskonfiguration.

    Hinweis

    Wenn vor dem Failover mehrere Replikate vorhanden waren, bleiben die Replikate, die während des Failovers nicht höher gestuft wurden, Teil der Hochverfügbarkeitsgruppe, die dem vorherigen primären Replikat zugeordnet ist. Bevor du die Replikation vom neuen primären System erneut einrichtest, musst du diese Replikate aus der Hochverfügbarkeitskonfiguration des alten primären Systems entfernen. Weitere Informationen finden Sie unter Entfernen eines Hochverfügbarkeitsreplikats.

  7. Appliances, für die du keine Replikation einrichten möchtest, die aber vor dem Failover Teil der Hochverfügbarkeitskonfiguration waren, müssen anhand ihrer UUID aus der Hochverfügbarkeitskonfiguration entfernt werden.

    • Rufe die UUID auf den früheren Appliances über cat /data/user/common/uuid ab.

      cat /data/user/common/uuid
      
    • Entferne die UUIDs für das neue Primärsystem mithilfe von ghe-repl-decommission. Ersetze UUID durch die UUID, die du im vorherigen Schritt abgerufen hast.

      ghe-repl-decommission UUID
      

    Warnung

    Wenn Sie nicht beabsichtigen, die Replikation aus dem neuen Primären erneut herzustellen, müssen Sie alle Appliances, die Teil der vorherigen Hochverfügbarkeitskonfiguration waren, herunterfahren oder löschen. Wenn diese Appliances während des Failovers nicht erreichbar waren, könnten sie unbeabsichtigte Änderungen an der neuen Primären verursachen, wenn sie später erreichbar sind. Um Konfigurationskonflikte oder Datenintegritätsprobleme zu verhindern, stellen Sie immer sicher, dass nicht verwendete Appliances ordnungsgemäß außer Betrieb genommen werden.

Weiterführende Lektüre

  •         [AUTOTITLE](/admin/enterprise-management/configuring-high-availability/about-high-availability-configuration#utilities-for-replication-management)