Comment récupérer le cluster MySQL Galera à partir d'un esclave asynchrone

Présentation

Lors de l'exécution de Galera Cluster, il est courant d'ajouter un ou plusieurs esclaves asynchrones dans le même centre de données ou dans un centre de données différent. Cela nous fournit un plan d'urgence avec un faible RTO et un faible coût d'exploitation. Dans le cas d'un problème irrécupérable dans notre cluster, nous pouvons basculer rapidement vers celui-ci afin que les applications puissent continuer à avoir accès aux données.

Lorsque vous utilisez ce type de configuration, nous ne pouvons pas simplement reconstruire notre cluster à partir d'une sauvegarde précédente. Étant donné que l'esclave asynchrone est désormais la nouvelle source de vérité, nous devons reconstruire le cluster à partir de celui-ci.

Cela ne signifie pas que nous n'avons qu'une seule façon de le faire, peut-être qu'il y a même une meilleure façon ! N'hésitez pas à nous faire part de vos suggestions dans la section des commentaires à la fin de cet article.

Topologie

Ci-dessus, nous pouvons voir un exemple de topologie avec Galera Cluster et un réplica/esclave asynchrone.

Ensuite, nous verrons comment nous pouvons recréer notre cluster, à partir de l'esclave, dans le cas où nous trouverions quelque chose comme ceci :

Si nous regardons l'image précédente, nous pouvons voir que nos 3 nœuds Galera sont en panne. Notre esclave n'est pas en mesure de se connecter au maître Galera, mais il est dans un état "En service".

Promouvoir l'esclave

Comme notre esclave fonctionne correctement, nous pouvons le promouvoir en tant que maître et pointer nos applications vers lui. Pour cela, nous devons désactiver le paramètre de lecture seule dans notre esclave et réinitialiser la configuration de l'esclave.

Dans notre esclave (mysql1) :

mysql> SET GLOBAL read_only=0;
Query OK, 0 rows affected (0.00 sec)
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.18 sec)

Créer un nouveau cluster

Ensuite, pour démarrer la récupération de notre cluster défaillant, nous allons créer un nouveau cluster Galera. Cela peut être facilement fait via ClusterControl ClusterControl, veuillez faire défiler plus bas dans ce blog pour voir comment.

Une fois que nous aurons déployé notre nouveau cluster Galera, nous aurions quelque chose comme ceci :

Réplication

Nous devons nous assurer que les paramètres de réplication sont configurés.

Pour les nœuds Galera (galera1, galera2, galera3) :

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin = /var/lib/mysql-binlog/binlog
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = true
relay_log = relay-bin
expire_logs_days = 7

Pour le nœud maître (mysql1) :

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
sync_binlog=1
report_host=<HOSTNAME or IP>    # Local server

Pour que notre nouvel esclave (galera1) se connecte à notre nouveau maître (mysql1), nous devons créer un utilisateur avec des autorisations de réplication dans notre maître.

Dans notre nouveau maître (mysql1) :

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

Remarque :Nous pouvons remplacer le "%" par l'adresse IP du nœud Galera Cluster qui sera notre esclave, dans notre exemple, galera1.

Sauvegarde

Si nous ne l'avons pas, nous devons créer une sauvegarde cohérente de notre maître (mysql1) et la charger dans notre nouveau cluster Galera. Pour cela, nous pouvons utiliser l'outil XtraBackup ou mysqldump. Voyons les deux options.

Dans notre exemple, nous utilisons la base de données sakila disponible pour les tests.

Outil XtraBackup

Nous générons la sauvegarde dans le nouveau maître (mysql1). Dans notre cas, nous l'envoyons dans le répertoire local /root/backup :

$ innobackupex /root/backup/

Nous devons comprendre le message :

180705 22:08:14 completed OK!

Nous compressons la sauvegarde et l'envoyons au nœud qui sera notre esclave (galera1) :

$ cd /root/backup
$ tar zcvf 2018-07-05_22-08-07.tar.gz 2018-07-05_22-08-07
$ scp /root/backup/2018-07-05_22-08-07.tar.gz galera1:/root/backup/

Dans galera1, extrayez la sauvegarde :

$ tar zxvf /root/backup/2018-07-05_22-08-07.tar.gz

On arrête le cluster (s'il est démarré). Pour cela on stoppe les services mysql des 3 nœuds :

$ service mysql stop

Dans galera1, on renomme le répertoire data de mysql et on charge la sauvegarde :

$ mv /var/lib/mysql /var/lib/mysql.bak
$ innobackupex --copy-back /root/backup/2018-07-05_22-08-07

Nous devons comprendre le message :

180705 23:00:01 completed OK!

Nous attribuons les autorisations correctes sur le répertoire de données :

$ chown -R mysql.mysql /var/lib/mysql

Ensuite, nous devons initialiser le cluster.

Une fois le premier nœud initialisé, nous devons démarrer le service MySQL pour les nœuds restants, en éliminant toute copie précédente du fichier grastate.dat, puis vérifier que nos données sont mises à jour.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Remarque :Vérifiez que l'utilisateur utilisé par XtraBackup est créé dans notre nœud initialisé et qu'il est le même dans chaque nœud.

mysqldump

En général, nous vous déconseillons de le faire avec mysqldump, car cela peut être assez lent avec un gros volume de données. Mais c'est une alternative pour effectuer la tâche.

Nous générons la sauvegarde dans le nouveau maître (mysql1) :

$ mysqldump -uroot -p --single-transaction --skip-add-locks --triggers --routines --events --databases sakila > /root/backup/sakila_dump.sql

Nous le compressons et l'envoyons à notre nœud esclave (galera1) :

$ gzip /root/backup/sakila_dump.sql
$ scp /root/backup/sakila_dump.sql.gz galera1:/root/backup/

Nous chargeons le dump dans galera1.

$ gunzip /root/backup/sakila_dump.sql.gz
$ mysql -p < /root/backup/sakila_dump.sql

Lorsque le vidage est chargé dans galera1, nous devons redémarrer le service MySQL sur les nœuds restants, supprimer le fichier grastate.dat et vérifier que nos données sont mises à jour.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Démarrer l'esclave de réplication

Quelle que soit l'option que nous choisissons, XtraBackup ou mysqldump, si tout s'est bien passé, dans cette étape, nous pouvons déjà activer la réplication dans le nœud qui sera notre esclave (galera1).

$ mysql> CHANGE MASTER TO MASTER_HOST = 'mysql1', MASTER_PORT = 3306, MASTER_USER = 'slave_user', MASTER_PASSWORD = 'slave_password', MASTER_AUTO_POSITION = 1;
$ mysql> START SLAVE;

Nous vérifions que l'esclave fonctionne :

mysql> SHOW SLAVE STATUS\G
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes

À ce stade, nous avons quelque chose comme ceci :

Une fois que NewGalera1 est à jour, nous pouvons rediriger l'application vers notre nouveau cluster galera et reconfigurer la réplication asynchrone.

ClusterControl

Comme nous l'avons mentionné précédemment, avec ClusterControl, nous pouvons effectuer plusieurs des tâches mentionnées ci-dessus en quelques clics simples. Il dispose également d'options de récupération automatique, à la fois pour les nœuds et le cluster. Voyons quelques tâches auxquelles il peut vous aider.

Pour effectuer un déploiement, sélectionnez simplement l'option "Déployer le cluster de bases de données" et suivez les instructions qui s'affichent.

Nous pouvons choisir entre différents types de technologies et de fournisseurs. Nous devons spécifier l'utilisateur, la clé ou le mot de passe et le port pour se connecter par SSH à nos serveurs. Nous avons également besoin du nom de notre nouveau cluster et si nous voulons que ClusterControl installe le logiciel et les configurations correspondants pour nous.

Après avoir configuré les informations d'accès SSH, nous devons définir les nœuds de notre cluster. Nous pouvons également spécifier quel référentiel utiliser. Nous devons ajouter nos serveurs au cluster que nous allons créer.

Nous pouvons surveiller l'état de la création de notre nouveau cluster à partir du moniteur d'activité ClusterControl.

De plus, nous pouvons effectuer une importation de notre cluster ou base de données actuel en suivant les mêmes étapes. Dans ce cas, ClusterControl n'installera pas le logiciel de base de données, car une base de données est déjà en cours d'exécution.

Pour ajouter un esclave de réplication, vous devez cliquer sur Actions de cluster, sélectionner Ajouter un esclave de réplication et ajouter les informations d'accès SSH du nouveau serveur. ClusterControl se connectera au serveur pour effectuer les configurations nécessaires à cette action.

Pour transformer un ou plusieurs nœuds Galera en serveurs maîtres (comme dans le sens de produire des binlogs), vous pouvez aller dans Node Actions et sélectionner Enable Binary Logging.

Les sauvegardes peuvent être configurées avec XtraBackup (complète ou incrémentielle) et mysqldump, et vous avez d'autres options comme le téléchargement de la sauvegarde sur le cloud, le chiffrement, la compression, la planification et plus encore.

Pour restaurer la sauvegarde, accédez à l'onglet Sauvegarde et choisissez l'option Restaurer, puis vous sélectionnez sur quel serveur vous souhaitez restaurer.

Si vous avez un esclave et que vous souhaitez changer de maître ou reconstruire la réplication, vous pouvez accéder à Actions de nœud et sélectionner l'option.

Conclusion

Comme nous avons pu le voir, nous avons plusieurs façons d'atteindre notre objectif, certaines plus complexes, d'autres plus conviviales, mais avec n'importe laquelle d'entre elles, vous pouvez recréer un cluster à partir d'un esclave asynchrone. Xtrabackup restaure plus rapidement les gros volumes de données. Pour vous prémunir contre les erreurs de l'opérateur (par exemple, un DROP TABLE erroné), vous pouvez également utiliser un esclave retardé afin d'avoir le temps, espérons-le, d'arrêter la propagation de l'instruction.

Nous espérons que ces informations vous seront utiles, et que vous n'aurez jamais à les utiliser en production;)