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 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.

      Note

      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. Activer le mode maintenance sur tous les appliances de réplication actifs. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».

  3. Sur l’appliance de réplication sur laquelle vous souhaitez basculer, pour arrêter la réplication et promouvoir l’appliance de réplication à l’état principal, utilisez la commande ghe-repl-promote.

    ghe-repl-promote

    Note

    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.

  4. 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.

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

  6. 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é ».

  7. 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