Diese Version von GitHub Enterprise Server wird eingestellt am 2024-06-29. 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

About failover to your replica cluster

If the datacenter for your active cluster experiences a failure and you've configured high availability, you can fail over to your replica cluster.

Failing over to your replica cluster promotes it to be your new active cluster, and decouples the new active cluster from the old active cluster. The nodes in your old active cluster are placed in maintenance mode if they are in a healthy enough state for this operation to be performed.

After failover, you will have two standalone clusters without high availability configured. You can reconfigure replication from the new active cluster. For more information, see "Configuring high availability replication for a cluster."

Prerequisites

To fail over to replica nodes, you must have configured high availability replication for your cluster. For more information, see "Configuring high availability replication for a cluster."

Note: High availability replication is available on GitHub Enterprise Server version 3.9.1 and later.

Initiating a failover to your replica cluster

  1. SSH into the primary MySQL node in the replica cluster. For more information, see "Accessing the administrative shell (SSH)."

  2. To begin the failover to the secondary cluster and configure the nodes to respond to requests, run the following command.

    ghe-cluster-failover

  3. After the configuration run finishes, GitHub Enterprise Server displays the following message.

    Finished cluster configuration

  4. Update the DNS record to point to the IP address of the load balancer for your replica cluster. After the TTL period expires, requests will be directed to the replica cluster.

After GitHub Enterprise Server returns you to the prompt and your DNS updates propagate, you've finished failing over. Users can access GitHub Enterprise Server using the usual hostname for your cluster.