À propos du basculement vers votre cluster de réplique
Si le centre de données de votre cluster actif subit une défaillance et que vous avez configuré la haute disponibilité, vous pouvez basculer vers votre cluster réplica.
Le basculement vers votre cluster réplique fait de celui-ci votre nouveau cluster actif et dissocie le nouveau cluster actif du cluster actif précédent. Les nœuds de votre ancien groupement actif sont placés en mode maintenance s’ils sont dans un état suffisamment sain pour que cette opération soit effectuée.
Après le basculement, vous disposerez de deux clusters autonomes sans configuration de haute disponibilité. Vous pouvez reconfigurer la réplication à partir du nouveau cluster actif. Pour plus d’informations, consultez « AUTOTITLE ».
Prérequis
Pour basculer vers des nœuds réplicas, vous devez avoir configuré la réplication de haute disponibilité pour votre cluster. Pour plus d’informations, consultez « AUTOTITLE ».
Démarrer un basculement vers votre cluster de réplication
-
Accédez via SSH au nœud principal MySQL du cluster de réplica. Pour plus d’informations, consultez « AUTOTITLE ».
-
Pour commencer le basculement vers le cluster secondaire et configurer les nœuds pour répondre aux demandes, exécutez la commande suivante.
ghe-cluster-failover -
Mettez à jour l’enregistrement DNS pour qu’il pointe vers l’adresse IP de l’équilibreur de charge de votre cluster réplica. Après l'expiration de la période de validité TTL, les demandes seront dirigées vers le cluster réplique.
Une fois que GitHub Enterprise Server vous ramène au terminal et que vos mises à jour DNS se propagent, le basculement est terminé. Les utilisateurs peuvent accéder à GitHub Enterprise Server en utilisant le nom d’hôte habituel de votre cluster.