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.

Problèmes connus avec les mises à niveau de votre instance

Consultez une vue d’ensemble des solutions de contournement pour les problèmes qui impactent le processus de mise à niveau de GitHub Enterprise Server ou qui impactent votre instance une fois que vous avez effectué une mise à niveau.

Dans cet article

À propos des problèmes connus avec les mises à niveau de GitHub Enterprise Server

GitHub a connaissance des problèmes suivants qui pourraient avoir un impact sur les mises à niveau vers les nouvelles versions de GitHub Enterprise Server. Pour plus d’informations, consultez « Problèmes connus » dans les Notes de publication de GitHub Enterprise Server.

GitHub recommande vivement de sauvegarder régulièrement la configuration et les données de votre instance. Avant de procéder à une mise à niveau, sauvegardez votre instance, puis validez la sauvegarde dans un environnement intermédiaire. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance » et « Configuration d’une instance de préproduction ».

Augmentation de l’utilisation des E/S à partir de la mise à niveau de MySQL 8 dans GitHub Enterprise Server 3.9 ou version ultérieure

Si vous effectuez une mise à niveau de GitHub Enterprise Server 3.7 ou 3.8 vers la version 3.9 ou ultérieure, une mise à niveau vers le logiciel de base de données sur votre instance augmente l’utilisation des E/S. Dans certains cas, cela peut affecter les performances de votre instance.

GitHub Enterprise Server inclut un serveur de base de données MySQL pris en charge par le moteur de stockage InnoDB. GitHub Enterprise Server 3.8 et antérieur utilise MySQL 5.7. En octobre 2023, Oracle mettra fin au support étendu de MySQL 5.7. Pour plus d’informations, consultez Oracle Lifetime Support Policy sur le site web du support Oracle.

Pour assurer la pérennisation de GitHub Enterprise Server et fournir les mises à jour de sécurité, correctifs de bogues et améliorations des performances les plus récents, GitHub Enterprise Server 3.9 et ultérieur utilise MySQL 8.0. MySQL 8.0 effectue un plus grand nombre de requêtes par seconde (QPS) en raison d’un journal REDO repensé. Pour plus d’informations, consultez MySQL Performance: 8.0 re-designed REDO log & ReadWrite Workloads Scalability sur le weblog de DimitriK (dim).

Après la mise à niveau vers GitHub Enterprise Server 3.9, si vous rencontrez une dégradation inacceptable des performances de votre instance, vous pouvez collecter des données dans le tableau de bord de surveillance de votre instance pour confirmer l’impact. Vous pouvez tenter d’atténuer le problème et fournir les données à Support GitHub pour vous aider à profiler et à communiquer l’impact réel de ce changement.

Avertissement : En raison de la nature de cette mise à niveau, sauvegardez la configuration et les données de votre instance avant de continuer. Validez la sauvegarde dans un environnement intermédiaire. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance » et « Configuration d’une instance de préproduction ».

Collecte des données d’utilisation des E/S de référence avant la mise à niveau de MySQL

Collectez les données de référence avant la mise à niveau vers GitHub Enterprise Server 3.9 ou ultérieur. Pour collecter les données de référence, GitHub vous recommande de configurer une instance intermédiaire de GitHub Enterprise Server exécutant 3.7 ou 3.8 et de restaurer les données de votre instance de production avec GitHub Enterprise Server Backup Utilities. Pour plus d’informations, consultez « Configuration d’une instance de préproduction » et « Configuration des sauvegardes sur votre instance ».

Vous ne pourrez peut-être pas simuler la charge que votre instance subit dans un environnement de production. Toutefois, cela reste utile si vous pouvez collecter les données de référence tout en simulant des modèles d’utilisation de votre environnement de production sur l’instance intermédiaire.

  1. Accédez au tableau de bord de surveillance de votre instance. Pour plus d’informations, consultez « Accès au tableau de bord moniteur ».

  2. À partir du tableau de bord de surveillance, surveillez les graphes appropriés.

    • Sous « Processus », surveillez les graphes pour « Opérations d’E/S (IOPS de lecture) » et « Opérations d’E/S (IOPS d’écriture) », en filtrant pour mysqld. Ces graphes affichent les opérations d’E/S pour tous les services du nœud.
    • Sous « Stockage », surveillez le graphe pour « Utilisation du disque (Data Device DEVICE-ID) ». Ce graphe affiche le temps passé sur toutes les opérations d’E/S du nœud.

Examen des données d’utilisation des E/S après la mise à niveau de MySQL

Après la mise à niveau vers GitHub Enterprise Server 3.9, passez en revue l’utilisation des E/S de l’instance. GitHub vous recommande de mettre à niveau une instance intermédiaire de GitHub Enterprise Server exécutant 3.7 ou 3.8 qui inclut des données restaurées à partir de votre instance de production, ou de restaurer les données de votre instance de production dans une nouvelle instance intermédiaire exécutant la version 3.9. Pour plus d’informations, consultez « Configuration d’une instance de préproduction » et « Configuration des sauvegardes sur votre instance ».

  1. Accédez au tableau de bord de surveillance de votre instance. Pour plus d’informations, consultez « Accès au tableau de bord moniteur ».

  2. À partir du tableau de bord de surveillance, surveillez les graphes appropriés.

    • Sous « Processus », surveillez les graphes pour « Opérations d’E/S (IOPS de lecture) » et « Opérations d’E/S (IOPS d’écriture) », en filtrant pour mysqld. Ces graphes affichent les opérations d’E/S pour tous les services du nœud.
    • Sous « Stockage », surveillez les graphes pour « Utilisation du disque (Data Device DEVICE ID) » et « Latence du disque (Data Device DEVICE-ID) ». Ces graphes affichent le temps passé sur toutes les opérations d’E/S du nœud, ainsi que la latence globale du disque.
      • Une augmentation significative de la latence du disque peut indiquer que votre instance force les IOPS à attendre.
      • Vous pouvez corroborer une observation d’une latence accrue en examinant le graphe pour « Opérations en attente du disque (Data Device DEVICE-ID) », ce qui peut indiquer que le disque ne peut pas traiter suffisamment toutes les opérations.

Atténuation de l’impact de la mise à niveau de MySQL

Pour résoudre une dégradation inacceptable des performances, GitHub recommande les solutions suivantes.

Avant de tester une procédure d’atténuation dans un environnement de production, sauvegardez votre instance, validez la sauvegarde, puis testez la procédure dans un environnement intermédiaire. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance » et « Configuration d’une instance de préproduction ».

Ajuster la méthode de vidage d’InnoDB

Pour tenter d’atténuer l’impact sur les performances, vous pouvez ajuster la méthode de vidage d’InnoDB pour ignorer l’appel système fsync() après chaque opération d’écriture. Pour plus d’informations, consultez innodb_flush_method dans le Manuel de référence de MySQL 8.0.

Les instructions suivantes concernent uniquement GitHub Enterprise Server 3.9 et ultérieur.

Avertissement : L’ajustement de la méthode de vidage nécessite que le dispositif de stockage de votre instance dispose d’un cache sur batterie. Si le cache de l’appareil n’est pas sur batterie, vous risquez de perdre des données.

  • Si vous hébergez votre instance avec un hyperviseur de virtualisation dans un centre de données local, vérifiez vos spécifications de stockage pour être sûr.
  • Si vous hébergez votre instance dans un service de cloud public, consultez la documentation de votre fournisseur ou l’équipe de support pour confirmer.

  1. Connexion SSH à votre instance GitHub Enterprise Server. Si votre instance comprend plusieurs nœuds, par exemple si la haute disponibilité ou la géoréplication sont configurées, connectez-vous via SSH au nœud principal. Si vous utilisez un cluster, vous pouvez vous connecter via SSH à n’importe quel nœud. Remplacez HOSTNAME par le nom d’hôte de votre instance, le nom d’hôte ou l’adresse IP d’un nœud. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

    Shell
    ssh -p 122 admin@HOSTNAME

  2. Pour valider la méthode de vidage actuelle pour InnoDB, exécutez la commande suivante.

    Shell
    ghe-config mysql.innodb-flush-no-fsync

    Par défaut, la commande retourne false, ce qui indique que votre instance effectue un appel système fsync() après chaque opération d’écriture.

  3. Pour configurer InnoDB de manière à ignorer l’appel système fsync() après chaque opération d’écriture, exécutez la commande suivante.

    Shell
    ghe-config mysql.innodb-flush-no-fsync true

  4. Pour appliquer la configuration, exécutez la commande suivante.

    Remarque : Durant une exécution de configuration, les services sur votre instance GitHub Enterprise Server peuvent redémarrer, ce qui peut entraîner un bref temps d’arrêt pour les utilisateurs.

    Shell
    ghe-config-apply

  5. Attendez la fin de l’exécution de la configuration.

Mettre à niveau le stockage de votre instance

Vous pouvez réduire les opérations en attente, augmenter les IOPS et améliorer les performances en provisionnant plus rapidement le stockage pour les nœuds de votre instance. Pour mettre à niveau le stockage de votre instance, sauvegardez votre instance et restaurez la sauvegarde dans une nouvelle instance de remplacement. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance ».

Partage de données avec GitHub

Enfin, si vous êtes prêt à aider GitHub à comprendre l’impact réel de la mise à niveau vers MySQL 8, vous pouvez fournir les données que vous avez collectées à Support GitHub. Fournissez les observations de référence et post-mise à niveau du tableau de bord de surveillance, ainsi qu’un bundle de support qui couvre la période pendant laquelle vous avez collecté les données. Pour plus d’informations, consultez « À propos du support GitHub » et « Fournir des données au support GitHub ».

Les données que vous envoyez aident GitHub à continuer à fournir un produit performant, mais GitHub ne garantit aucune autre étape d’atténuation ni aucun changement dans le produit faisant suite à l’envoi de vos données.

MySQL ne démarre pas après la mise à niveau vers GitHub Enterprise Server 3.9 ou 3.10

Lors d’une mise à niveau vers GitHub Enterprise Server 3.9 (depuis 3.7 ou 3.8) ou 3.10 (depuis 3.8 uniquement), si MySQL ne s’est pas correctement arrêté lors de l’arrêt des instances GitHub Enterprise Server 3.7 ou 3.8, MySQL tente de passer par une récupération sur incident lorsque l’instance GitHub Enterprise Server 3.9 ou 3.10 démarre. Étant donné que GitHub Enterprise Server 3.7 et 3.8 utilisent MySQL 5.7 et que GitHub Enterprise Server 3.9 et 3.10 ont été mis à niveau vers MySQL 8.0, MySQL ne pourra pas terminer la récupération sur incident.

Si vous effectuez une mise à niveau depuis GitHub Enterprise Server 3.9 vers 3.10, vous ne serez pas affecté par ce problème, car MySQL a déjà été mis à niveau de 5.7 à 8.0 sur votre instance.

Si vous rencontrez ce problème, l’erreur suivante se trouve dans le journal des erreurs mysql (/var/log/mysql/mysql.err) :

Shell
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported. This redo log was created with MySQL 5.7.40. Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/upgrading.html

Éviter ce problème

Nous vous recommandons vivement de mettre à niveau votre instance GitHub Enterprise Server vers la dernière version patch (3.7.14 ou ultérieure ou 3.8.7 ou ultérieure) avant de procéder à la mise à niveau vers la version 3.9 ou 3.10. Ces versions contiennent un correctif pour le problème de mise à niveau.

Si vous ne pouvez pas mettre à niveau votre instance GitHub Enterprise Server, vous pouvez éviter le problème en mettant à jour le délai d’expiration de Nomad pour MySQL avant de commencer une mise à niveau vers GitHub Enterprise Server 3.9 (depuis 3.7 ou 3.8) ou 3.10 (depuis 3.8 uniquement).

  1. Placez votre instance en mode maintenance :

    Shell
    ghe-maintenance -s

  2. Mettez à jour le modèle consul pour Nomad :

    Shell
    sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl

  3. Afficher le modèle consul pour Nomad :

    Shell
    sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl

  4. Vérifier le paramètre kill_timeout actuel :

    Shell
    nomad job inspect mysql | grep KillTimeout

    La réponse attendue est :

    Shell
    "KillTimeout": 5000000000

  5. Arrêter MySQL :

    Shell
    nomad job stop mysql

  6. Exécuter la nouvelle tâche MySQL :

    Shell
    nomad job run /etc/nomad-jobs/mysql/mysql.hcl

  7. Vérifiez la mise à jour récente de kill_timeout :

    Shell
    nomad job inspect mysql | grep KillTimeout

    La réponse attendue est :

    Shell
    "KillTimeout": 600000000000,

  8. Sortez l’instance du mode maintenance :

    Shell
    ghe-maintenance -u

Maintenant que le délai d’expiration de Nomad pour MySQL a été mis à jour, vous pouvez mettre à niveau votre instance GitHub Enterprise Server vers la version 3.9.

Atténuation d’un échec de redémarrage de MySQL

Si vous êtes affecté par ce problème, restaurez votre instance GitHub Enterprise Server à l’état dans lequel elle se trouvait avant la tentative de mise à niveau, puis suivez les étapes de la section précédente.

Pour plus d’informations sur la restauration à partir d’un échec de mise à niveau, consultez « Restauration à partir d’une mise à niveau avortée ».