À propos du basculement vers votre cluster réplica
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éplica fait de celui-ci votre nouveau cluster actif et dissocie le nouveau cluster actif de l’ancien. 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 « Configuration de la réplication à haute disponibilité pour un cluster ».
Prérequis
Pour basculer vers des nœuds réplicas, vous devez avoir configuré la haute disponibilité pour votre cluster. Pour plus d’informations, consultez « Configuration de la réplication à haute disponibilité pour un cluster ».
Lancement d’un basculement vers votre cluster réplica
-
SSH dans le nœud MySQL principal dans le cluster réplica. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».
-
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 -
Une fois l’exécution de la configuration terminée, GitHub Enterprise Server affiche le message suivant.
Finished cluster configuration -
Mettez à jour l’enregistrement DNS pour qu’il pointe vers l’adresse IP de l’équilibreur de charge de votre cluster réplica. Une fois la durée de vie terminée, les demandes sont dirigées vers le cluster réplica.
Une fois que GitHub Enterprise Server vous renvoie à l’invite 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.