Le transfert d'instantané d'état (SST) est l'un des deux moyens utilisés par Galera pour effectuer la synchronisation initiale lorsqu'un nœud rejoint un cluster, jusqu'à ce que le nœud soit déclaré synchronisé et fasse partie du « composant principal ». En fonction de la taille de l'ensemble de données et de la charge de travail, SST peut être rapide comme l'éclair ou être une opération coûteuse qui mettra votre service de base de données à genoux.
Le SST peut être effectué en utilisant 3 méthodes différentes :
- mysqldump
- rsync (ou rsync_wan)
- xtrabackup (ou xtrabackup-v2, mariabackup)
La plupart du temps, xtrabackup-v2 et mariabackup sont les options préférées. Nous voyons rarement des personnes s'exécuter sur rsync ou mysqldump dans les clusters de production.
Le problème
Lorsque SST est lancé, plusieurs processus sont déclenchés sur le nœud jointeur, qui sont exécutés par l'utilisateur "mysql" :
$ ps -fu mysql
UID PID PPID C STIME TTY TIME CMD
mysql 117814 129515 0 13:06 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.173:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir
mysql 120036 117814 15 13:06 ? 00:00:06 innobackupex --no-version-check --tmpdir=/tmp/tmp.pMmzIlZJwa --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-inf
mysql 120037 117814 19 13:06 ? 00:00:07 socat -u stdio TCP:192.168.55.173:4444
mysql 129515 1 1 Oct27 ? 01:11:46 /usr/sbin/mysqld --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:4949331Sur le nœud donneur :
mysql 43733 1 14 Oct16 ? 03:28:47 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:272891
mysql 87092 43733 0 14:53 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.172:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir /var/lib/mysql/ --gtid 7ce0e31f-aa46-11e7-abda-56d6a5318485:2883115 --gtid-domain-id 0
mysql 88826 87092 30 14:53 ? 00:00:05 innobackupex --no-version-check --tmpdir=/tmp/tmp.LDdWzbHkkW --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-info --stream=xbstream /tmp/tmp.oXDumYf392
mysql 88827 87092 30 14:53 ? 00:00:05 socat -u stdio TCP:192.168.55.172:4444SST contre un grand ensemble de données (des centaines de Go) n'est pas amusant. Selon le matériel, le réseau et la charge de travail, cela peut prendre des heures. Les ressources du serveur peuvent être saturées pendant l'opération. Bien que la limitation soit prise en charge dans SST (uniquement pour xtrabackup et mariabackup) à l'aide des options --rlimit et --use-memory, nous sommes toujours exposés à un cluster dégradé lorsque vous manquez de nœuds actifs majoritaires. Par exemple, si vous avez la malchance de vous retrouver avec un seul nœud sur trois en cours d'exécution. Par conséquent, il est conseillé d'effectuer le SST pendant les heures calmes. Vous pouvez cependant éviter SST en prenant certaines mesures manuelles, comme décrit dans cet article de blog.
Arrêter un SST
L'arrêt d'un SST doit être effectué à la fois sur les nœuds donneur et jointeur. Le menuisier déclenche SST après avoir déterminé la taille de l'écart lors de la comparaison du seqno Galera local avec le seqno du cluster. Il exécute la wsrep_sst_{wsrep_sst_method} commande. Cela sera choisi par le donateur choisi, qui commencera à diffuser des données vers le menuisier. Un nœud donneur n'a pas la capacité de refuser de servir le transfert d'instantané, une fois sélectionné par la communication de groupe Galera, ou par la valeur définie dans wsrep_sst_donor variable. Une fois que la synchronisation a commencé et que vous souhaitez annuler la décision, il n'y a pas de commande unique pour arrêter l'opération.
Le principe de base lors de l'arrêt d'un SST est de :
- Faire en sorte que le membre ait l'air mort du point de vue de la communication du groupe Galera (arrêt, clôture, blocage, réinitialisation, débranchement du câble, liste noire, etc.)
- Tuer les processus SST sur le donneur
On pourrait penser que tuer le processus innobackupex (kill -9 {innobackupex PID}) sur le donneur serait suffisant, mais ce n'est pas le cas. Si vous tuez les processus SST sur le donneur (ou le jointeur) sans clôturer le jointeur, Galera peut toujours voir le jointeur comme actif et marquera le processus SST comme incomplet, réapparaissant ainsi un nouvel ensemble de processus pour continuer ou recommencer. Vous serez de retour à la case départ. Il s'agit du comportement attendu du script /usr/bin/wsrep_sst_{method} pour protéger le fonctionnement SST qui est vulnérable aux délais d'attente (par exemple, s'il est long et gourmand en ressources).
Prenons un exemple. Nous avons un nœud de jointure en panne que nous aimerions rejoindre le cluster. Nous commencerions par exécuter la commande suivante sur le menuisier :
$ systemctl start mysql # or service mysql startUne minute plus tard, nous avons découvert que l'opération était trop lourde à ce moment précis, et avons décidé de la reporter plus tard pendant les heures de faible trafic. Le moyen le plus simple d'arrêter une méthode SST basée sur xtrabackup consiste simplement à arrêter le nœud jointeur et à tuer les processus liés à SST sur le nœud donneur. Alternativement, vous pouvez également bloquer les ports entrants sur le menuisier en exécutant la commande iptables suivante sur le menuisier :
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPEnsuite, sur le donneur, récupérez le PID des processus SST (listez les processus appartenant à l'utilisateur "mysql") :
$ ps -u mysql
PID TTY TIME CMD
117814 ? 00:00:00 wsrep_sst_xtrab
120036 ? 00:00:06 innobackupex
120037 ? 00:00:07 socat
129515 ? 01:11:47 mysqldEnfin, tuez-les tous sauf le processus mysqld (vous devez faire extrêmement attention à ne PAS tuer le processus mysqld sur le donneur !) :
$ kill -9 117814 120036 120037Ensuite, dans le journal des erreurs MySQL du donneur, vous devriez remarquer que la ligne suivante apparaît après environ 100 secondes :
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: Could not find peer: 42b85e82-bd32-11e7-87ae-eff2b8dd2ea0
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: 1.0 (192.168.55.172): State transfer to -1.-1 (left the group) failed: -32 (Broken pipe)À ce stade, le donateur doit revenir à l'état "synchronisé" comme indiqué par wsrep_local_state_comment et le processus SST est complètement arrêté. Le donateur est de retour à son état opérationnel et est en mesure de servir les clients à pleine capacité.
Pour le processus de nettoyage sur le menuisier, vous pouvez simplement vider la chaîne iptables :
$ iptables -FOu supprimez simplement les règles avec l'indicateur -D :
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPUne approche similaire peut être utilisée avec d'autres méthodes SST telles que rsync, mariabackup et mysqldump.
Limitation d'un SST (méthode xtrabackup uniquement)
En fonction de l'activité du donateur, il est judicieux de limiter le processus SST afin qu'il n'ait pas d'impact significatif sur le donateur. Nous avons vu un certain nombre de cas où, lors de pannes catastrophiques, les utilisateurs cherchaient désespérément à ramener un cluster défaillant sous la forme d'un seul nœud amorcé, et à laisser le reste des membres rattraper leur retard plus tard. Cette tentative réduit le temps d'arrêt du côté de l'application, cependant, elle crée une charge supplémentaire sur ce "cluster à un nœud", tandis que les membres restants sont toujours en panne ou en cours de récupération.
Xtrabackup peut être limité avec --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Plus de détails sur la page de documentation Percona Xtrabackup SST.
Cependant, il y a un hic. Le processus peut être si lent qu'il ne rattrapera jamais les journaux de transactions qu'InnoDB écrit, de sorte que SST peut ne jamais se terminer. Généralement, cette situation est très rare, sauf si vous avez vraiment une charge de travail très intensive en écriture ou si vous allouez des ressources très limitées à SST.
Conclusion
SST est critique mais lourd, et pourrait potentiellement être une opération de longue durée en fonction de la taille de l'ensemble de données et du débit du réseau entre les nœuds. Quelles que soient les conséquences, il existe encore des possibilités d'arrêter l'opération afin que nous puissions avoir un meilleur plan de reprise à un meilleur moment.
