À 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 le promeut en nouveau cluster actif et dissocie le nouveau cluster actif de l’ancien cluster actif. 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, deux clusters indépendants subsisteront 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 effectuer un basculement vers des nœuds de réplica, la réplication de haute disponibilité doit avoir été configurée 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
-
Accédez via SSH au nœud principal MySQL du cluster de 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 -
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.
Lorsque GitHub Enterprise Server vous renvoie à l’invite de commande et que les mises à jour DNS se sont propagées, le basculement est terminé. Les utilisateurs peuvent accéder à GitHub Enterprise Server en utilisant le nom d’hôte habituel de votre cluster.