Hallo, Entdecker! An dieser Seite wird aktiv gearbeitet, oder sie wird noch übersetzt. Die neuesten und genauesten Informationen findest Du in unserer englischsprachigen Dokumentation.
Deutsch
No results found.

Nach Produkt erkunden

Enterprise administrators
  • Get started
  • Account and profile
  • Authentication
  • Repositories
  • GitHub
  • Enterprise administrators
  • Billing and payments
  • Organizations
  • Code security
  • GitHub Issues
  • GitHub Actions
  • GitHub Codespaces
  • GitHub Packages
  • Search on GitHub
  • Developers
  • REST API
  • GraphQL API
  • GitHub CLI
  • GitHub Discussions
  • GitHub Sponsors
  • Building communities
  • GitHub Pages
  • Education
  • GitHub Desktop
  • Atom
  • Electron
  • CodeQL
  • npm
    • Deutsch
  • English
  • 简体中文 (Simplified Chinese)
  • 日本語 (Japanese)
  • Español (Spanish)
  • Português do Brasil (Portuguese)

    • Diese Version von GitHub Enterprise wurde eingestellt am 2021-09-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

    Artikelversion

    Hochverfügbarkeitskonfiguration wiederherstellen

    Nachdem Sie ein Failover zur GitHub Enterprise Server-Appliance durchgeführt haben, sollten Sie schnellstmöglich die Redundanz zurückerlangen, anstatt sich auf eine einzelne Appliance zu verlassen.

    Sie können die vorherige primäre Appliance als neue Replikat-Appliance verwenden, sofern das Failover geplant war oder nicht mit dem Appliance-Zustand in Zusammenhang stand. Wenn das Failover mit einem Problem an der primären Appliance zusammenhing, sollten Sie ggf. eine neue Replikat-Appliance erstellen. Weitere Informationen finden Sie unter „Hochverfügbarkeitsreplikat erstellen“.

    Vorherige primäre Appliance als neues Replikat konfigurieren

    1. Stellen Sie mittels SSH eine Verbindung zur IP-Adresse der vorherigen primären Appliance her.

      $ ssh -p 122 admin@FORMER PRIMARY IP

    2. Führen Sie auf der vorherigen primären Appliance den Befehl ghe-repl-setup mit der IP-Adresse des vorherigen Replikats aus.

      $ ghe-repl-setup FORMER REPLICA IP

    3. Um der Liste der autorisierten Schlüssel auf der primären Appliance den öffentlichen Schlüssel hinzuzufügen, navigiere zu https://PRIMARY-HOSTNAME/setup/settings, und füge den Schlüssel, den Du vom Replikat kopiert hast, zur Liste hinzu.

    4. Führen Sie den Befehl ghe-repl-setup erneut aus, um die Verbindung zur neuen primären Instanz zu verifizieren und um den Replikatmodus für das neue Replikat zu aktivieren.

      $ ghe-repl-setup FORMER REPLICA IP

    5. Führe den Befehl ghe-repl-start aus, um mit der Replikation der Datenspeicher zu beginnen.

      $ ghe-repl-start

      Warnung: ghe-repl-start verursacht einen kurzen Ausfall auf dem primären Server, während dessen Benutzer interne Serverfehler sehen können. Um eine freundlichere Nachricht bereitzustellen, führe ghe-maintenance -s auf dem primären Knoten aus, bevor Du ghe-repl-start auf dem Replikatknoten ausführst, um die Appliance in den Wartungsmodus zu versetzen. Sobald die Replikation gestartet ist, deaktiviere den Wartungsmodus mit ghe-maintenance -u. Git replication will not progress while the primary node is in maintenance mode.