Exécution d'un cluster MariaDB Galera sans outils d'orchestration - Gestion des conteneurs DB :deuxième partie

Comme nous l'avons vu dans la première partie de ce blog, un cluster de bases de données fortement cohérent comme Galera ne fonctionne pas bien avec des outils d'orchestration de conteneurs comme Kubernetes ou Swarm. Nous vous avons montré comment déployer Galera et configurer la gestion des processus pour Docker, afin que vous gardiez le contrôle total du comportement. Ce billet de blog est la suite de celui-ci, nous allons nous pencher sur le fonctionnement et la maintenance du cluster.

Pour récapituler certains des points principaux de la partie 1 de ce blog, nous avons déployé un cluster Galera à trois nœuds, avec ProxySQL et Keepalived sur trois hôtes Docker différents, où toutes les instances MariaDB s'exécutent en tant que conteneurs Docker. Le schéma suivant illustre le déploiement final :

Arrêt progressif

Pour effectuer un arrêt progressif de MySQL, le meilleur moyen est d'envoyer SIGTERM (signal 15) au conteneur :

$ docker kill -s 15 {db_container_name}

Si vous souhaitez arrêter le cluster, répétez la commande ci-dessus sur tous les conteneurs de base de données, un nœud à la fois. Ce qui précède est similaire à l'exécution de "systemctl stop mysql" dans le service systemd pour MariaDB. L'utilisation de la commande "docker stop" est assez risquée pour le service de base de données car elle attend un délai de 10 secondes et Docker forcera SIGKILL si cette durée est dépassée (sauf si vous utilisez un --timeout approprié valeur).

Le dernier nœud qui s'arrête normalement aura le seqno différent de -1 et safe_to_bootstrap flag est défini sur 1 dans le /{datadir volume}/grastate.dat de l'hôte Docker, par exemple sur host2 :

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

Détection du nœud le plus avancé

Si le cluster ne s'est pas arrêté correctement, ou si le nœud que vous tentiez d'amorcer n'était pas le dernier nœud à quitter le cluster, vous ne seriez probablement pas en mesure d'amorcer l'un des nœuds Galera et pourriez rencontrer l'erreur suivante :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Galera honore le nœud qui a safe_to_bootstrap drapeau défini sur 1 comme premier nœud de référence. C'est le moyen le plus sûr d'éviter la perte de données et de s'assurer que le bon nœud est toujours amorcé.

Si vous avez l'erreur, nous devons d'abord trouver le nœud le plus avancé avant de choisir le nœud comme le premier à être amorcé. Créer un conteneur transitoire (avec --rm flag), mappez-le au même datadir et répertoire de configuration du conteneur de base de données réel avec deux drapeaux de commande MySQL, --wsrep_recover et --wsrep_cluster_address . Par exemple, si nous voulons connaître le dernier numéro validé de mariadb1, nous devons exécuter :

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

La dernière ligne est ce que nous recherchons. MariaDB imprime l'UUID du cluster et le numéro de séquence de la dernière transaction validée. Le nœud qui détient le numéro le plus élevé est considéré comme le nœud le plus avancé. Puisque nous avons spécifié --rm , le conteneur sera supprimé automatiquement une fois qu'il sera fermé. Répétez l'étape ci-dessus sur chaque hôte Docker en remplaçant le --volume chemin d'accès aux volumes de conteneur de base de données respectifs.

Une fois que vous avez comparé la valeur signalée par tous les conteneurs de base de données et décidé quel conteneur est le nœud le plus à jour, modifiez le safe_to_bootstrap indicateur à 1 à l'intérieur de /{datadir volume}/grastate.dat manuellement. Disons que tous les nœuds signalent le même numéro de séquence exact, nous pouvons simplement choisir mariadb3 à démarrer en changeant le safe_to_bootstrap valeur à 1 :

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

Enregistrez le fichier et démarrez l'amorçage du cluster à partir de ce nœud, comme décrit dans le chapitre suivant.

Amorcer le cluster

L'amorçage du cluster est similaire à la première commande d'exécution de docker que nous avons utilisée lors du premier démarrage du cluster. Si mariadb1 est le nœud d'amorçage choisi, nous pouvons simplement réexécuter le conteneur d'amorçage créé :

$ docker start mariadb0 # on host1

Sinon, si le conteneur bootstrap n'existe pas sur le nœud choisi, disons sur host2, exécutez la commande bootstrap container et mappez les volumes de mariadb2 existants. Nous utilisons mariadb0 comme nom de conteneur sur host2 pour indiquer qu'il s'agit d'un conteneur d'amorçage :

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Vous remarquerez peut-être que cette commande est légèrement plus courte par rapport à la commande bootstrap précédente décrite dans ce guide. Puisque nous avons déjà créé l'utilisateur proxysql dans notre première commande bootstrap, nous pouvons ignorer ces deux variables d'environnement :

--env MYSQL_USER=proxysql
--env MYSQL_PASSWORD=proxysqlpassword

Ensuite, démarrez les conteneurs MariaDB restants, supprimez le conteneur d'amorçage et démarrez le conteneur MariaDB existant sur l'hôte amorcé. Fondamentalement, l'ordre des commandes serait :

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

À ce stade, le cluster est démarré et fonctionne à pleine capacité.

Contrôle des ressources

La mémoire est une ressource très importante dans MySQL. C'est là que les tampons et les caches sont stockés, et il est essentiel pour MySQL de réduire l'impact d'un accès trop fréquent au disque. D'un autre côté, l'échange est mauvais pour les performances de MySQL. Par défaut, il n'y aura pas de contraintes de ressources sur les conteneurs en cours d'exécution. Les conteneurs utilisent autant d'une ressource donnée que le noyau de l'hôte le permet. Une autre chose importante est la limite de descripteur de fichier. Vous pouvez augmenter la limite du descripteur de fichier ouvert, ou "nofile" à quelque chose de plus élevé pour répondre au nombre de fichiers que le serveur MySQL peut ouvrir simultanément. Le régler sur une valeur élevée ne fera pas de mal.

Pour limiter l'allocation de mémoire et augmenter la limite de descripteur de fichier à notre conteneur de base de données, on ajouterait --memory , --memory-swap et --ulimit paramètres dans la commande "docker run":

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Notez que si --memory-swap est défini sur la même valeur que --memory , et --mémoire est défini sur un entier positif, le conteneur n'aura pas accès au swap. Si --memory-swap n'est pas défini, l'échange de conteneurs sera par défaut --memory multiplier par 2. Si --mémoire et --memory-swap sont définis sur la même valeur, cela empêchera les conteneurs d'utiliser un swap. C'est parce que --memory-swap est la quantité combinée de mémoire et d'échange qui peut être utilisée, tandis que --memory n'est que la quantité de mémoire physique qui peut être utilisée.

Certaines des ressources du conteneur, telles que la mémoire et le processeur, peuvent être contrôlées dynamiquement via la commande "docker update", comme illustré dans l'exemple suivant pour mettre à niveau la mémoire du conteneur mariadb1 vers 32 G à la volée :

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

N'oubliez pas d'ajuster le my.cnf en conséquence pour l'adapter aux nouvelles spécifications. La gestion de la configuration est expliquée dans la section suivante.

Gestion des configurations

La plupart des paramètres de configuration MySQL/MariaDB peuvent être modifiés pendant l'exécution, ce qui signifie que vous n'avez pas besoin de redémarrer pour appliquer les modifications. Consultez la page de documentation de MariaDB pour plus de détails. Le paramètre répertorié avec "Dynamique :Oui" signifie que la variable est chargée immédiatement lors de la modification sans qu'il soit nécessaire de redémarrer le serveur MariaDB. Sinon, définissez les paramètres dans le fichier de configuration personnalisé de l'hôte Docker. Par exemple, sur mariadb3, apportez les modifications au fichier suivant :

$ vim /containers/mariadb3/conf.d/my.cnf

Et puis redémarrez le conteneur de la base de données pour appliquer la modification :

$ docker restart mariadb3

Vérifiez que le conteneur démarre le processus en consultant les journaux Docker. Effectuez cette opération sur un nœud à la fois si vous souhaitez apporter des modifications à l'échelle du cluster.

Sauvegarde

Faire une sauvegarde logique est assez simple car l'image MariaDB est également livrée avec le binaire mysqldump. Vous utilisez simplement la commande "docker exec" pour exécuter mysqldump et envoyer la sortie dans un fichier relatif au chemin de l'hôte. La commande suivante effectue une sauvegarde mysqldump sur mariadb2 et l'enregistre dans /backups/mariadb2 à l'intérieur de host2 :

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

La sauvegarde binaire comme Percona Xtrabackup ou MariaDB Backup nécessite que le processus accède directement au répertoire de données MariaDB. Vous devez soit installer cet outil à l'intérieur du conteneur, soit via l'hôte de la machine, soit utiliser une image dédiée à cet effet comme l'image "perconalab/percona-xtrabackup" pour créer la sauvegarde et la stocker dans /tmp/backup sur l'hôte Docker :

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

Vous pouvez également arrêter le conteneur avec innodb_fast_shutdown défini sur 0 et copiez le volume datadir vers un autre emplacement de l'hôte physique :

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

Restaurer

La restauration est assez simple pour mysqldump. Vous pouvez simplement rediriger le stdin dans le conteneur depuis l'hôte physique :

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

Vous pouvez également utiliser la ligne de commande standard du client mysql à distance avec le nom d'hôte et la valeur de port appropriés au lieu d'utiliser cette commande "docker exec":

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

Pour Percona Xtrabackup et MariaDB Backup, nous devons préparer la sauvegarde au préalable. Cela fera avancer la sauvegarde jusqu'au moment où la sauvegarde s'est terminée. Disons que nos fichiers Xtrabackup sont situés sous /tmp/backup de l'hôte Docker, pour le préparer, simplement :

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

La sauvegarde préparée sous /tmp/backup de l'hôte Docker peut alors être utilisée comme répertoire de données MariaDB pour un nouveau conteneur ou cluster. Supposons que nous voulions simplement vérifier la restauration sur un conteneur MariaDB autonome, nous exécuterions :

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

Si vous avez effectué une sauvegarde en utilisant l'approche d'arrêt et de copie, vous pouvez simplement dupliquer le répertoire de données et utiliser le répertoire dupliqué en tant que volume mappé sur le répertoire de données MariaDB pour s'exécuter sur un autre conteneur. Supposons que la sauvegarde a été copiée sous /backups/mariadb2/datadir_copied, nous pouvons exécuter un nouveau conteneur en exécutant :

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

Le MYSQL_ROOT_PASSWORD doit correspondre au mot de passe root réel pour cette sauvegarde particulière.

Manynines MySQL sur Docker :comment conteneuriser votre base de donnéesDécouvrez tout ce que vous devez comprendre lorsque vous envisagez d'exécuter un service MySQL au-dessus de la virtualisation de conteneurs DockerTélécharger le livre blanc

Mise à jour de la version de la base de données

Il existe deux types de mise à niveau :la mise à niveau sur place ou la mise à niveau logique.

La mise à niveau sur place implique l'arrêt du serveur MariaDB, le remplacement des anciens fichiers binaires par les nouveaux, puis le démarrage du serveur sur l'ancien répertoire de données. Une fois démarré, vous devez exécuter mysql_upgrade script pour vérifier et mettre à jour toutes les tables système et également pour vérifier les tables utilisateur.

La mise à niveau logique implique l'exportation de SQL à partir de la version actuelle à l'aide d'un utilitaire de sauvegarde logique tel que mysqldump, l'exécution du nouveau conteneur avec les fichiers binaires de la version mise à niveau, puis l'application de SQL à la nouvelle version de MySQL/MariaDB. Elle est similaire à l'approche de sauvegarde et de restauration décrite dans la section précédente.

Néanmoins, c'est une bonne approche de toujours sauvegarder votre base de données avant d'effectuer des opérations destructrices. Les étapes suivantes sont requises lors de la mise à niveau de l'image actuelle, MariaDB 10.1.33 vers une autre version majeure, MariaDB 10.2.15 sur mariadb3 réside sur host3 :

Sauvegardez la base de données. Peu importe la sauvegarde physique ou logique, mais cette dernière utilisant mysqldump est recommandée.
Téléchargez la dernière image vers laquelle nous aimerions mettre à jour :
```
$ docker pull mariadb:10.2.15
```

Définissez innodb_fast_shutdown sur 0 pour notre conteneur de base de données :

$ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

Arrêt progressif du conteneur de base de données :
```
$ docker kill --signal=TERM mariadb3
```

Créez un nouveau conteneur avec la nouvelle image pour notre conteneur de base de données. Conservez le reste des paramètres intacts, sauf en utilisant le nouveau nom de conteneur (sinon cela créerait un conflit) :

$ docker run -d \
        --name mariadb3-new \
        --hostname mariadb3.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb3/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb3.weave.local

Exécutez le script mysql_upgrade :

$ docker exec -it mariadb3-new mysql_upgrade -uroot -p

Si aucune erreur ne s'est produite, supprimez l'ancien conteneur, mariadb3 (le nouveau est mariadb3-new) :
```
$ docker rm -f mariadb3
```
Sinon, si le processus de mise à niveau échoue entre-temps, nous pouvons revenir au conteneur précédent :
```
$ docker stop mariadb3-new
$ docker start mariadb3
```

La mise à niveau de la version majeure peut être effectuée de la même manière que la mise à niveau de la version mineure, sauf que vous devez garder à l'esprit que MySQL/MariaDB ne prend en charge que la mise à niveau majeure de la version précédente. Si vous utilisez MariaDB 10.0 et que vous souhaitez effectuer une mise à niveau vers 10.2, vous devez d'abord effectuer une mise à niveau vers MariaDB 10.1, suivie d'une autre étape de mise à niveau vers MariaDB 10.2.

Prenez note des changements de configuration introduits et obsolètes entre les versions majeures.

Basculement

Dans Galera, tous les nœuds sont maîtres et ont le même rôle. Avec ProxySQL dans l'image, les connexions qui passent par cette passerelle seront automatiquement basculées tant qu'un composant principal s'exécute pour Galera Cluster (c'est-à-dire que la majorité des nœuds sont actifs). L'application ne remarquera aucune différence si un nœud de base de données tombe en panne, car ProxySQL redirigera simplement les connexions vers les autres nœuds disponibles.

Si l'application se connecte directement à MariaDB en contournant ProxySQL, le basculement doit être effectué côté application en pointant vers le prochain nœud disponible, à condition que le nœud de la base de données remplisse les conditions suivantes :

Statut wsrep_local_state_comment est Synced (L'état "Desynced/Donor" est également possible, uniquement si wsrep_sst_method est xtrabackup, xtrabackup-v2 ou mariabackup).
État wsrep_cluster_status est principal.

Dans Galera, un nœud disponible ne signifie pas qu'il est sain tant que l'état ci-dessus n'a pas été vérifié.

Évolution horizontale

Pour évoluer, nous pouvons créer un nouveau conteneur dans le même réseau et utiliser le même fichier de configuration personnalisé pour le conteneur existant sur cet hôte particulier. Par exemple, disons que nous voulons ajouter le quatrième conteneur MariaDB sur host3, nous pouvons utiliser le même fichier de configuration monté pour mariadb3, comme illustré dans le schéma suivant :

Exécutez la commande suivante sur host3 pour effectuer un scale-out :

$ docker run -d \
        --name mariadb4 \
        --hostname mariadb4.weave.local \
        --net weave \
        --publish "3306:3307" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb4/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local,mariadb4.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb4.weave.local

Une fois le conteneur créé, il rejoindra le cluster et effectuera SST. Il est accessible sur le port 3307 en externe ou en dehors du réseau Weave, ou sur le port 3306 au sein de l'hôte ou du réseau Weave. Il n'est plus nécessaire d'inclure mariadb0.weave.local dans l'adresse du cluster. Une fois le cluster mis à l'échelle, nous devons ajouter le nouveau conteneur MariaDB dans l'ensemble d'équilibrage de charge ProxySQL via la console d'administration :

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Répétez les commandes ci-dessus sur la deuxième instance ProxySQL.

Enfin, pour la dernière étape (vous pouvez ignorer cette partie si vous avez déjà exécuté l'instruction "SAVE .. TO DISK" dans ProxySQL), ajoutez la ligne suivante dans proxysql.cnf pour la rendre persistante lors du redémarrage du conteneur sur host1 et host2 :

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

Et ajoutez les lignes liées à mariadb4 sous la directive mysql_server :

mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

Enregistrez le fichier et nous devrions être bons au prochain redémarrage du conteneur.

Réduction

Pour réduire l'échelle, fermez simplement le conteneur avec élégance. La meilleure commande serait :

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

N'oubliez pas que si le nœud de la base de données quittait le cluster sans grâce, cela ne faisait pas partie de la réduction et affecterait le calcul du quorum.

Pour supprimer le conteneur de ProxySQL, exécutez les commandes suivantes sur les deux conteneurs ProxySQL. Par exemple, sur proxysql1 :

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Vous pouvez ensuite supprimer l'entrée correspondante dans proxysql.cnf ou simplement la laisser comme ça. Il sera de toute façon détecté comme HORS LIGNE du point de vue de ProxySQL.

Résumé

Avec Docker, les choses deviennent un peu différentes de la manière conventionnelle de gérer les serveurs MySQL ou MariaDB. La gestion de services avec état comme Galera Cluster n'est pas aussi simple que les applications sans état, et nécessite des tests et une planification appropriés.

Dans notre prochain blog sur ce sujet, nous évaluerons les avantages et les inconvénients de l'exécution de Galera Cluster sur Docker sans aucun outil d'orchestration.