Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.
All products
Administrateurs d’entreprise

Cette version de GitHub Enterprise a été abandonnée le 2023-03-15. 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 appliance réplica

Vous pouvez basculer vers une appliance réplica GitHub Enterprise Server à l’aide de la ligne de commande pour la maintenance et les tests, ou en cas de défaillance de l’appliance primaire.

La durée du basculement dépend du temps nécessaire pour promouvoir manuellement le réplica et rediriger le trafic. La durée moyenne varie entre 20 et 30 minutes.

La promotion d’un réplica ne configure pas automatiquement la réplication pour les appliances existantes. Après avoir promu un réplica, si vous le souhaitez, vous pouvez configurer la réplication à partir du nouveau réplica principal vers des appliances existantes et le réplica principal précédent.

  1. Si l’appliance principale est disponible, pour permettre à la réplication d’aboutir avant le changement d’appliance, sur l’appliance principale, faites passer celle-ci en mode maintenance.

    • Faites passer l’appliance en mode maintenance.

    • Une fois que le nombre d’opérations Git, de requêtes MySQL et de travaux Resque actifs a atteint zéro, patientez 30 secondes.

      Remarque : Vous trouverez toujours des travaux Nomad en cours d’exécution, même en mode maintenance. Vous pouvez donc les ignorer sans risque.

    • Pour vérifier que tous les canaux de réplication indique OK, utilisez la commande ghe-repl-status -vv.

      $ ghe-repl-status -vv

  2. Sur l’appliance réplica, pour arrêter la réplication et promouvoir l’appliance réplica à l’état principal, utilisez la commande ghe-repl-promote. Celle-ci fera aussi passer automatiquement le nœud principal en mode maintenance s’il est accessible.

    $ ghe-repl-promote

    Remarque : Si le nœud principal n’est pas disponible, des avertissements et des délais d’expiration peuvent se produire, mais peuvent être ignorés.

  3. Mettez à jour l’enregistrement DNS pour le faire pointer vers l’adresse IP du réplica. Le trafic est dirigé vers le réplica une fois la période TTL écoulée. Si vous utilisez un équilibreur de charge, vérifiez qu’il est configuré pour envoyer le trafic au réplica.

  4. Informez les utilisateurs qu’ils peuvent reprendre le cours normal des opérations.

  5. Si vous le souhaitez, configurez la réplication de l’appliance principale vers des appliances existantes et la précédente appliance principale. Pour plus d’informations, consultez « À propos de la configuration de la haute disponibilité ».

  6. Les appliances que vous n’avez pas l’intention de configurer pour la réplication et qui faisaient partie de la configuration à haute disponibilité avant le basculement, doivent être retirées de la configuration à haute disponibilité par UUID.

    • Sur les anciennes appliances, obtenez leur UUID via cat /data/user/common/uuid. 
      $ cat /data/user/common/uuid
    • Sur la nouvelle appliance principale, supprimez les UUID à l’aide de ghe-repl-teardown. Remplacez UUID par un UUID que vous avez récupéré à l’étape précédente. 
      $ ghe-repl-teardown -u  UUID

Pour aller plus loin