Échelonnage de l’attribution de cote de base de données

Vous pouvez accélérer le processus d’ajout d’un nouveau nœud de réplica MySQL à votre groupement en choisissant d’échelonner l’attribution de cote de 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

Informations sur l’échelonnage de l’attribution de cote de base de données d’un nœud de réplica MySQL

Note

La possibilité d’échelonner l’attribution de cote de base de données a été ajoutée dans la version corrective 3.9.13 et est disponible en version bêta publique.

L’ajout d’un nouveau nœud de réplica MySQL à votre groupement lorsque votre nœud principal dispose de plus de sept jours de données déclenche normalement l’attribution de cote de la base de données, ce qui peut prendre plusieurs heures en fonction de la quantité de données. Vous pouvez choisir d’échelonner l’attribution de cote de base de données, ce qui permet à la configuration d’appliquer l’exécution plus tôt, et donc d’ouvrir votre appliance au trafic plus tôt.

Vous ne devez échelonner l’attribution de cote de 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 échelonnez l’attribution de cote de base de données, le nouveau réplica MySQL ne sera pas configurée pour la réplication et ne disposera pas d’une copie des données sur votre nœud principal MySQL jusqu’à ce que l’attribution de cote soit effectuée manuellement par la suite.

Configuration de l’échelonnage de l’attribution de cote MySQL lors de l’ajout d’un nouveau nœud MySQL

Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.
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.
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
 ...
 
```
Pour initialiser le nouveau nœud dans le cluster, exécutez ghe-cluster-config-init à partir du shell d’administration du nœud avec le cluster.conf modifié.
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.

Attribution de cote manuelle des données

Une fois que vous avez exécuté ghe-cluster-config-apply, le service MySQL s’exécute sur votre nouveau nœud, mais ne sera pas configuré en tant que réplica, ni ne sera alloué avec des données du nœud principal MySQL. Pour allouer des données à partir du nœud principal MySQL, vous devez configurer la réplication manuellement.

À 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’attribution de cote de 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.