Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2026-04-09. 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.

Report du remplissage de la base de données

Vous pouvez accélérer le processus d'ajout d'un nouveau nœud réplique MySQL à votre cluster en choisissant de différer l'initialisation de la base de données.

Qui peut utiliser cette fonctionnalité ?

GitHub détermine l’éligibilité au clustering et doit activer la configuration de la licence de votre instance. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

Dans cet article

À propos du report du remplissage de la base de données d’un nœud de réplica MySQL

Remarque

La possibilité de différer l’amorçage de la base de données est disponible sous forme de bêta.

L’ajout d’un nouveau nœud de réplica MySQL à votre cluster lorsque votre nœud principal dispose de plus de sept jours de données déclenche normalement l'initialisation de la base de données, ce qui peut prendre plusieurs heures en fonction de la quantité de données. Vous pouvez décider de différer le remplissage de la base de données, ce qui accélère l’exécution de la configuration et permet d’ouvrir plus rapidement votre appliance au trafic.

Vous ne devez retarder l'amorçage de la base de données que si vous avez déjà configuré au moins un réplica MySQL et que vous ajoutez un réplica MySQL supplémentaire. Dans le cas contraire, il n’y a pas de redondance MySQL tant que l’attribution de cote n’est pas terminée.

Lorsque vous reportez l'initialisation de la base de données, le nouveau réplica MySQL ne sera pas configuré pour la réplication et ne disposera pas d’une copie des données sur votre nœud principal MySQL jusqu’à ce que l'initialisation soit effectuée manuellement plus tard.

Configuration du report de l'amorçage MySQL lors de l’ajout d’un nouveau nœud MySQL

  1. Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.

  2. En utilisant l’interpréteur de commandes d’administration ou DHCP, configurez uniquement l’adresse IP du nœud de remplacement. Ne configurez pas d’autres paramètres.

  3. Créez l’entrée cluster.conf pour le nouveau nœud MySQL et incluez le champ skip-data-setup = true. L’exemple ci-dessous ajoute un nouveau nœud avec le nom d’hôte ghe-data-node-3 et le rôle mysql-server.

     ...
 [cluster "ghe-data-node-3"]
   hostname = ghe-data-node-3
   ipv4 = 192.168.0.9
   # ipv6 = fd12:3456:789a:1::7
   mysql-server = true
   skip-data-setup = true
 ...

  4. Pour initialiser le nouveau nœud dans le cluster, à partir du shell d’administration du nœud avec le cluster.conf modifié, exécutez ghe-cluster-config-init.

  5. Pour valider le fichier de configuration, ainsi que pour copier et configurer chaque nœud conformément au fichier cluster.conf modifié, exécutez ghe-cluster-config-apply.

Initialisation manuelle des données

Une fois que vous avez exécuté ghe-cluster-config-apply, le service MySQL s’exécutera sur votre nouveau nœud, mais il ne sera pas configuré en tant que réplique et ne sera pas initialisé avec des données du nœud principal MySQL. Pour initialiser les données à partir du nœud maître MySQL, vous devez configurer la réplication manuellement.

  1. À partir du nouveau nœud, pour démarrer la réplication manuelle des données du nœud principal MySQL, exécutez la commande suivante, en remplaçant PRIMARY_IP par l’adresse IP du nœud exécutant le nœud principal MySQL.

    /usr/local/share/enterprise/ghe-mysql-repl-start PRIMARY_IP

Le temps nécessaire pour l'initialisation de la base de données dépend de la taille des données. Pour les jeux de données volumineux, nous recommandons d’exécuter la commande ci-dessus dans une session screen pour s’assurer qu’elle survit aux déconnexions SSH.