State Snapshot Transfer (SST) ist eine der beiden Methoden, die Galera verwendet, um eine anfängliche Synchronisierung durchzuführen, wenn ein Knoten einem Cluster beitritt, bis der Knoten als synchronisiert und Teil der „primären Komponente“ deklariert wird. Abhängig von der Größe des Datensatzes und der Arbeitslast kann SST blitzschnell oder ein teurer Vorgang sein, der Ihren Datenbankdienst in die Knie zwingen wird.
SST kann mit 3 verschiedenen Methoden durchgeführt werden:
- mysqldump
- rsync (oder rsync_wan)
- xtrabackup (oder xtrabackup-v2, mariabackup)
Meistens sind xtrabackup-v2 und mariabackup die bevorzugten Optionen. Wir sehen selten Leute, die rsync oder mysqldump in Produktionsclustern ausführen.
Das Problem
Wenn SST initiiert wird, werden mehrere Prozesse auf dem Joiner-Knoten ausgelöst, die vom „mysql“-Benutzer ausgeführt werden:
$ 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:4949331Auf dem Spenderknoten:
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 gegen einen großen Datensatz (Hunderte GByte) macht keinen Spaß. Je nach Hardware, Netzwerk und Arbeitslast kann es Stunden dauern. Während des Vorgangs können Serverressourcen ausgelastet sein. Obwohl Drosselung in SST (nur für xtrabackup und mariabackup) mit den Optionen --rlimit und --use-memory unterstützt wird, sind wir immer noch einem herabgesetzten Cluster ausgesetzt, wenn Ihnen die meisten aktiven Knoten ausgehen. Zum Beispiel, wenn Sie das Pech haben, nur einen von drei Knoten laufen zu lassen. Daher wird empfohlen, den SST während ruhiger Stunden durchzuführen. Sie können SST jedoch vermeiden, indem Sie einige manuelle Schritte unternehmen, wie in diesem Blogbeitrag beschrieben.
Stoppen eines SST
Das Stoppen eines SST muss sowohl auf dem Donor- als auch auf den Joiner-Knoten erfolgen. Der Joiner löst SST aus, nachdem er bestimmt hat, wie groß die Lücke ist, wenn er die lokale Galera-Seqno mit der Seqno des Clusters vergleicht. Es führt die wsrep_sst_{wsrep_sst_method} aus Befehl. Dies wird vom ausgewählten Spender ausgewählt, der mit dem Streaming von Daten an den Joiner beginnt. Ein Spender-Knoten hat keine Möglichkeit, die Übertragung von Schnappschüssen zu verweigern, sobald er durch die Kommunikation der Galera-Gruppe oder durch den in wsrep_sst_donor definierten Wert ausgewählt wurde Variable. Sobald die Synchronisierung gestartet wurde und Sie die Entscheidung rückgängig machen möchten, gibt es keinen einzigen Befehl, um den Vorgang zu stoppen.
Das Grundprinzip beim Stoppen eines SST ist:
- Lassen Sie den Joiner aus Sicht der Galera-Gruppenkommunikation tot aussehen (Herunterfahren, Zaun, Blockieren, Zurücksetzen, Kabel abziehen, schwarze Liste usw.)
- Beenden Sie die SST-Prozesse auf dem Donor
Man könnte meinen, dass das Beenden des innobackupex-Prozesses (kill -9 {innobackupex PID}) auf dem Spender ausreichen würde, aber das ist nicht der Fall. Wenn Sie die SST-Prozesse auf dem Spender (oder Joiner) beenden, ohne den Joiner abzuzäunen, kann Galera den Joiner immer noch als aktiv sehen und markiert den SST-Prozess als unvollständig, wodurch ein neuer Satz von Prozessen neu erstellt wird, um fortzufahren oder von vorne zu beginnen. Sie werden wieder auf Platz eins sein. Dies ist das erwartete Verhalten des Skripts /usr/bin/wsrep_sst_{method}, um den SST-Betrieb zu schützen, der anfällig für Zeitüberschreitungen ist (z. B. wenn er lange läuft und ressourcenintensiv ist).
Schauen wir uns ein Beispiel an. Wir haben einen abgestürzten Joiner-Knoten, den wir dem Cluster wieder beitreten möchten. Wir würden damit beginnen, den folgenden Befehl auf dem Joiner auszuführen:
$ systemctl start mysql # or service mysql startEine Minute später stellten wir fest, dass die Operation in diesem bestimmten Moment zu schwer ist, und beschlossen, sie auf einen späteren Zeitpunkt während der verkehrsarmen Stunden zu verschieben. Der einfachste Weg, eine xtrabackup-basierte SST-Methode zu stoppen, besteht darin, einfach den Joiner-Knoten herunterzufahren und die SST-bezogenen Prozesse auf dem Donor-Knoten zu beenden. Alternativ können Sie auch die eingehenden Ports auf dem Joiner blockieren, indem Sie den folgenden iptables-Befehl auf dem Joiner ausführen:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPRufen Sie dann auf dem Donor die PID der SST-Prozesse ab (listen Sie die Prozesse auf, die dem „mysql“-Benutzer gehören):
$ 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 mysqldBeenden Sie schließlich alle außer dem mysqld-Prozess (Sie müssen äußerst vorsichtig sein, den mysqld-Prozess auf dem Donor NICHT zu beenden!):
$ kill -9 117814 120036 120037Dann sollten Sie im Donor-MySQL-Fehlerprotokoll die folgende Zeile bemerken, die nach ~100 Sekunden erscheint:
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)An diesem Punkt sollte der Spender in den "synchronisierten" Zustand zurückkehren, wie von wsrep_local_state_comment gemeldet und der SST-Prozess wird vollständig gestoppt. Der Spender befindet sich wieder im Betriebszustand und ist in der Lage, Kunden in vollem Umfang zu bedienen.
Für den Bereinigungsprozess auf dem Joiner können Sie einfach die iptables-Kette leeren:
$ iptables -FOder entfernen Sie einfach die Regeln mit -D Flag:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPDer ähnliche Ansatz kann mit anderen SST-Methoden wie rsync, mariabackup und mysqldump verwendet werden.
Drosselung eines SST (nur xtrabackup-Methode)
Je nachdem, wie beschäftigt der Spender ist, ist es ein guter Ansatz, den SST-Prozess zu drosseln, damit er den Spender nicht wesentlich beeinträchtigt. Wir haben eine Reihe von Fällen gesehen, in denen Benutzer bei katastrophalen Ausfällen verzweifelt versuchten, einen ausgefallenen Cluster als einzelnen Bootstrap-Knoten zurückzubringen und den Rest der Mitglieder später aufholen zu lassen. Dieser Versuch reduziert die Ausfallzeit auf der Anwendungsseite, verursacht jedoch eine zusätzliche Belastung für diesen „Ein-Knoten-Cluster“, während die verbleibenden Mitglieder noch ausfallen oder sich erholen.
Xtrabackup kann mit --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Weitere Einzelheiten finden Sie auf der Percona Xtrabackup SST-Dokumentationsseite.
Allerdings gibt es einen Haken. Der Prozess könnte so langsam sein, dass er niemals die Transaktionsprotokolle einholt, die InnoDB schreibt, sodass SST möglicherweise nie abgeschlossen wird. Im Allgemeinen ist diese Situation sehr ungewöhnlich, es sei denn, Sie haben wirklich eine sehr schreibintensive Arbeitslast oder Sie weisen SST nur sehr begrenzte Ressourcen zu.
Schlussfolgerungen
SST ist kritisch, aber schwer und könnte je nach Dataset-Größe und Netzwerkdurchsatz zwischen den Knoten möglicherweise ein lang andauernder Vorgang sein. Unabhängig von den Folgen gibt es immer noch Möglichkeiten, den Vorgang zu stoppen, damit wir zu einem besseren Zeitpunkt einen besseren Wiederherstellungsplan haben können.
