Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-09-25. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Lancement d’un basculement vers votre cluster réplica

En cas de défaillance de votre cluster GitHub Enterprise Server, vous pouvez effectuer un basculement vers le réplica.

Dans cet article

À 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

Note

Sur une instance d’une configuration de cluster, les anciens nœuds principaux ont pu accéder aux nœuds nouvellement promus après le basculement. Ce problème a été corrigé dans la version corrective 3.10.10. Pour plus d’informations, consultez « Notes de publication. »

À la suite de cette correction, ghe-cluster-failover identifie les adresses IP à bloquer à partir de l’ancien cluster primaire et les écrit dans /data/user/common/cluster-ip-blocklist. Une fois le basculement terminé, la commande exécute ghe-cluster-block-ips pour bloquer les adresses IP sur le nouveau cluster actif.

En outre, les commandes ghe-cluster-block-ips, ghe-cluster-block-ip, ghe-cluster-unblock-ips et ghe-cluster-unblock-ip ont également été introduites dans ces versions correctives. Avec ces commandes, vous pouvez contrôler manuellement les adresses IP qui peuvent accéder à votre cluster nouvellement promu et éviter l’exécution de configurations potentiellement longues associées à l’exécution de toute la commande ghe-cluster-failover. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».

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.