Migration réseau sans temps d'arrêt avec MySQL Galera Cluster utilisant un nœud de relais

Le provisionnement automatique des nœuds de Galera Cluster simplifie la complexité de la mise à l'échelle d'un cluster de bases de données avec une cohérence des données garantie. SST et IST améliorent la convivialité de la synchronisation initiale des données sans qu'il soit nécessaire de sauvegarder manuellement la base de données et de la copier sur le nouveau nœud. Combinez cela avec la capacité de Galera à tolérer différentes configurations de réseau (par exemple, la réplication WAN), nous pouvons désormais migrer la base de données entre différents réseaux isolés sans aucune interruption de service.

Dans cet article de blog, nous allons voir comment migrer notre cluster MySQL Galera sans temps d'arrêt. Nous allons déplacer la base de données d'Amazon Web Service (AWS) EC2 vers Google Cloud Platform (GCP) Compute Engine, à l'aide d'un nœud relais. Notez que nous avions un article de blog similaire dans le passé, mais celui-ci utilise une approche différente.

Le schéma suivant simplifie notre plan de migration :

Préparation de l'ancien site

Étant donné que les deux sites ne peuvent pas communiquer entre eux en raison du groupe de sécurité ou de l'isolement du VPC, nous avons besoin d'un nœud relais pour relier ces deux sites. Ce nœud peut être situé sur l'un ou l'autre site, mais doit pouvoir se connecter à un ou plusieurs nœuds de l'autre côté sur les ports 3306 (MySQL), 4444 (SST), 4567 (gcomm) et 4568 (IST). Voici ce que nous avons déjà, et comment nous allons faire évoluer l'ancien site :

Vous pouvez également utiliser un nœud Galera existant (par exemple, le troisième nœud) comme nœud relais, tant qu'il a une connectivité avec l'autre côté. L'inconvénient est que la capacité du cluster sera réduite à deux, car un nœud sera utilisé pour SST et relayera le flux de réplication Galera entre les sites. Selon la taille de l'ensemble de données et la connexion entre les sites, cela peut introduire des problèmes de fiabilité de la base de données sur le cluster actuel.

Nous allons donc utiliser un quatrième nœud pour réduire le risque sur le cluster de production actuel lors de la synchronisation avec l'autre côté. Tout d'abord, créez une nouvelle instance dans le tableau de bord AWS avec une adresse IP publique (afin qu'elle puisse communiquer avec le monde extérieur) et autorisez les ports de communication Galera requis (TCP 3306, 4444, 4567-4568).

Déployez le quatrième nœud (nœud relais) sur l'ancien site. Si vous utilisez ClusterControl, vous pouvez simplement utiliser la fonctionnalité "Ajouter un nœud" pour faire évoluer le cluster (n'oubliez pas de configurer au préalable SSH sans mot de passe du nœud ClusterControl à ce quatrième hôte) :

Assurez-vous que le nœud de relais est synchronisé avec le cluster actuel et qu'il est capable de communiquer avec l'autre côté.

Depuis le nouveau site, nous allons nous connecter au nœud relais puisque c'est le seul nœud qui a une connectivité avec le monde extérieur.

Déploiement d'un nouveau site

Sur le nouveau site, nous déploierons une configuration similaire avec un nœud ClusterControl et un cluster Galera à trois nœuds. Les deux sites doivent utiliser la même version de MySQL. Voici notre architecture sur le nouveau site :

Avec ClusterControl, le déploiement du nouveau cluster n'est qu'à quelques clics et une fonctionnalité gratuite dans l'édition communautaire. Allez dans ClusterControl -> Deploy Database Cluster -> MySQL Galera et suivez l'assistant de déploiement :

Cliquez sur Déployer et surveillez la progression sous Activité -> Travaux -> Créer un cluster. Une fois cela fait, vous devriez avoir les éléments suivants sur le tableau de bord :

À ce stade, vous avez deux clusters Galera distincts :4 nœuds sur l'ancien site et 3 nœuds sur le nouveau site.

Connexion des deux sites

Sur le nouveau site (GCP), choisissez un nœud pour communiquer avec le nœud relais sur l'ancien site. Nous allons choisir galera-gcp1 comme connecteur vers le nœud relais (galera-aws4). Le schéma suivant illustre notre plan de transition :

Les éléments importants à configurer sont les paramètres suivants :

wsrep_sst_donor :Le wsrep_node_name du nœud donneur. Sur galera-gcp1, définissez le donateur sur galera-aws4.
wsrep_sst_auth :Les informations d'identification de l'utilisateur SST au format nom d'utilisateur :mot de passe doivent suivre l'ancien site (AWS).
wsrep_sst_receive_address :L'adresse IP qui recevra SST sur le nœud jointeur. Sur galera-gcp1, définissez ceci sur l'adresse IP publique de ce nœud.
wsrep_cluster_address :chaîne de connexion Galera. Sur galera-gcp1, ajoutez l'adresse IP publique de galera-aws4.
wsrep_provider_options :
- gmcast.segment :la valeur par défaut est 0. Définissez un nombre entier différent sur tous les nœuds dans GCP.

Sur le nœud relais (galera-aws4), récupérez le wsrep_node_name :

$ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
Enter password:
+-------------------+
| @@wsrep_node_name |
+-------------------+
| 10.0.0.13         |
+-------------------+

Sur my.cnf de galera-gcp1, définissez wsrep_sst_donor valeur au wsrep_node_name du nœud relais et wsrep_sst_receive_address à l'adresse IP publique de galera-gcp1 :
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
Sur tous les nœuds de GCP, assurez-vous que wsrep_sst_auth la valeur est identique suivant l'ancien site (AWS) et changez le segment Galera en 1 (pour que Galera sache que les deux sites sont dans des réseaux différents) :
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
Sur galera-gcp1, définissez wsrep_cluster_address pour inclure l'adresse IP publique du nœud relais :
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Modifiez uniquement wsrep_cluster_address sur galera-gcp1. Ne modifiez pas ce paramètre sur galera-gcp2 et galera-gcp3.
Arrêtez tous les nœuds sur GCP. Si vous utilisez ClusterControl, accédez à la liste déroulante Actions de cluster -> Arrêter le cluster. Vous devez également désactiver la récupération automatique au niveau du cluster et du nœud, afin que ClusterControl n'essaie pas de récupérer les nœuds défaillants.

Maintenant la partie synchronisation. Démarrez galera-gcp1. Vous pouvez voir dans le journal des erreurs MySQL sur le nœud donneur que SST est lancé entre le nœud relais (10.0.0.13) à l'aide d'une adresse publique sur galera-gcp1 (35.197.136.232) :

2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
        2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

Notez qu'à ce stade, galera-gcp1 sera inondé des lignes suivantes :

2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

Vous pouvez ignorer cet avertissement en toute sécurité car galera-gcp1 continue d'essayer de voir les nœuds restants au-delà du nœud relais sur AWS.

Une fois SST sur galera-gcp1 terminé, ClusterControl sur GCE ne pourra pas connecter les nœuds de base de données, en raison de GRANT manquants (les GRANT existants ont été remplacés après la synchronisation à partir d'AWS). Voici donc ce que nous devons faire après la fin de SST sur galera-gcp1 :
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Une fois cela fait, ClusterControl signalera correctement l'état de galera-gcp1 comme indiqué ci-dessous :
La dernière partie consiste à démarrer les galera-gcp2 et galera-gcp3 restants, un nœud à la fois. Accédez à ClusterControl -> Nodes -> choisissez le nœud -> Start Node. Une fois tous les nœuds synchronisés, vous devriez obtenir 7 comme taille de cluster :

Le cluster fonctionne maintenant sur les deux sites et la mise à l'échelle est terminée.

Déclassement

Une fois la migration terminée et tous les nœuds synchronisés, vous pouvez commencer à basculer votre application vers le nouveau cluster sur GCP :

À ce stade, les données MySQL sont répliquées sur tous les nœuds jusqu'à la mise hors service. Les performances de réplication seront aussi bonnes que le permet le nœud le plus éloigné du cluster. Le nœud de relais est essentiel, car il diffuse des jeux d'écriture à l'autre côté. Du point de vue de l'application, il est recommandé d'écrire sur un seul site à la fois, ce qui signifie que vous devrez commencer à rediriger les lectures/écritures depuis AWS et les servir à partir du cluster GCP à la place.

Pour mettre hors service les anciens nœuds de base de données et passer au cluster sur GCP, nous devons effectuer un arrêt progressif (un nœud à la fois) sur AWS. Il est important d'arrêter les nœuds avec élégance, car le site AWS détient le nombre majoritaire de nœuds (4/7) pour ce cluster. Si vous les arrêtez tous en même temps, le cluster sur GCP passera à l'état non principal, forçant le cluster à refuser l'opération. Assurez-vous que le dernier nœud à arrêter côté AWS est le nœud relais.

N'oubliez pas de mettre à jour les paramètres suivants sur galera-gcp1 en conséquence :

wsrep_cluster_address - Supprimer l'adresse IP publique du nœud de relais.
wsrep_sst_donor - Commentez cette ligne. Laissez Galera choisir automatiquement le donateur.
wsrep_sst_receive_address - Commentez cette ligne. Laissez Galera sélectionner automatiquement l'interface de réception.

Votre cluster Galera fonctionne désormais sur une plate-forme, des hôtes et un réseau entièrement nouveaux sans une seconde d'indisponibilité de votre service de base de données pendant la migration. C'est cool ?