State Snapshot Transfer (SST) is een van de twee manieren die door Galera worden gebruikt om initiële synchronisatie uit te voeren wanneer een knooppunt lid wordt van een cluster, totdat het knooppunt wordt verklaard als gesynchroniseerd en deel uitmaakt van de "primaire component". Afhankelijk van de grootte van de dataset en de werkbelasting, kan SST razendsnel zijn, of een dure operatie die uw databaseservice op de knieën zal brengen.
SST kan worden uitgevoerd met behulp van 3 verschillende methoden:
- mysqldump
- rsync (of rsync_wan)
- xtrabackup (of xtrabackup-v2, mariabackup)
Meestal zijn xtrabackup-v2 en mariabackup de voorkeursopties. We zien zelden mensen draaien op rsync of mysqldump in productieclusters.
Het probleem
Wanneer SST wordt gestart, worden er verschillende processen geactiveerd op de joiner-node, die worden uitgevoerd door de "mysql"-gebruiker:
$ 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:4949331Terwijl op het donorknooppunt:
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 tegen een grote dataset (honderden GBytes) is geen pretje. Afhankelijk van de hardware, het netwerk en de werkbelasting kan het uren duren voordat het voltooid is. Serverbronnen kunnen tijdens de bewerking verzadigd raken. Ondanks dat beperking wordt ondersteund in SST (alleen voor xtrabackup en mariabackup) met behulp van --rlimit en --use-memory opties, worden we nog steeds blootgesteld aan een verslechterd cluster wanneer u bijna geen actieve meerderheidsknooppunten meer heeft. Als u bijvoorbeeld de pech heeft dat er slechts één op de drie knooppunten actief is. Daarom wordt u geadviseerd om SST tijdens stille uren uit te voeren. U kunt SST echter vermijden door enkele handmatige stappen te nemen, zoals beschreven in deze blogpost.
Een SST stoppen
Het stoppen van een SST moet worden gedaan op zowel de donor- als de joiner-knooppunten. De joiner activeert SST nadat hij heeft bepaald hoe groot de kloof is bij het vergelijken van de lokale Galera-seqno met de seqno van het cluster. Het voert de wsrep_sst_{wsrep_sst_method} uit opdracht. Dit wordt gekozen door de gekozen donor, die gegevens naar de schrijnwerker begint te streamen. Een donorknooppunt kan niet weigeren om snapshot-overdracht uit te voeren, eenmaal geselecteerd door Galera-groepscommunicatie, of door de waarde gedefinieerd in wsrep_sst_donor variabel. Als de synchronisatie eenmaal is gestart en u de beslissing wilt terugdraaien, is er geen enkele opdracht om de bewerking te stoppen.
Het basisprincipe bij het stoppen van een SST is:
- Laat de schrijnwerker er dood uitzien vanuit een Galera-groepscommunicatiestandpunt (afsluiten, afschermen, blokkeren, resetten, kabel loskoppelen, zwarte lijst, enz.)
- Dood de SST-processen op de donor
Je zou denken dat het doden van het innobackupex-proces (kill -9 {innobackupex PID}) op de donor voldoende zou zijn, maar dat is niet het geval. Als u de SST-processen op donor (of schrijnwerker) beëindigt zonder de schrijnwerker af te schermen, kan Galera de schrijnwerker nog steeds als actief zien en zal het SST-proces als onvolledig markeren, waardoor een nieuwe reeks processen wordt geactiveerd om door te gaan of opnieuw te beginnen. Je komt terug bij af. Dit is het verwachte gedrag van het /usr/bin/wsrep_sst_{method}-script om de SST-bewerking te beveiligen, die kwetsbaar is voor time-outs (bijv. als het langdurig is en veel resources nodig heeft).
Laten we een voorbeeld bekijken. We hebben een gecrasht joiner-knooppunt dat we opnieuw willen toevoegen aan het cluster. We zouden beginnen met het uitvoeren van de volgende opdracht op de schrijnwerker:
$ systemctl start mysql # or service mysql startEen minuut later kwamen we erachter dat de operatie op dat moment te zwaar is en hebben we besloten om deze later uit te stellen tijdens de drukke uren. De eenvoudigste manier om een op xtrabackup gebaseerde SST-methode te stoppen, is door simpelweg het joiner-knooppunt af te sluiten en de SST-gerelateerde processen op het donorknooppunt te beëindigen. Als alternatief kunt u ook de inkomende poorten op de joiner blokkeren door het volgende iptables-commando op de joiner uit te voeren:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPHaal vervolgens bij de donor de PID van SST-processen op (lijst de processen op die eigendom zijn van de "mysql" -gebruiker):
$ 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 mysqldTen slotte, dood ze allemaal behalve het mysqld-proces (je moet uiterst voorzichtig zijn om het mysqld-proces NIET op de donor te doden!):
$ kill -9 117814 120036 120037Vervolgens zou u in het MySQL-foutlogboek van de donor de volgende regel moeten zien verschijnen na ~ 100 seconden:
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)Op dit punt moet de donor terugkeren naar de "gesynchroniseerde" status zoals gerapporteerd door wsrep_local_state_comment en het SST-proces is volledig gestopt. De donor is terug in zijn operationele staat en kan klanten in volle capaciteit van dienst zijn.
Voor het opruimproces op de schrijnwerker, kunt u eenvoudig de iptables-keten doorspoelen:
$ iptables -FOf verwijder eenvoudig de regels met -D flag:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPDe vergelijkbare aanpak kan worden gebruikt met andere SST-methoden zoals rsync, mariabackup en mysqldump.
Een SST beperken (alleen xtrabackup-methode)
Afhankelijk van hoe druk de donor is, is het een goede manier om het SST-proces te vertragen, zodat het geen significante impact heeft op de donor. We hebben een aantal gevallen gezien waarin gebruikers tijdens catastrofale mislukkingen wanhopig probeerden een mislukte cluster terug te brengen als een enkele bootstrap-node, en de rest van de leden het later te laten inhalen. Deze poging vermindert de downtime vanaf de applicatiekant, maar veroorzaakt een extra belasting voor dit "cluster met één knooppunt", terwijl de overige leden nog steeds niet actief zijn of herstellen.
Xtrabackup kan worden gesmoord met --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Meer details op de Percona Xtrabackup SST-documentatiepagina.
Er is echter een vangst. Het proces kan zo traag zijn dat het nooit de transactielogboeken zal inhalen die InnoDB aan het schrijven is, dus SST kan nooit worden voltooid. Over het algemeen is deze situatie zeer ongebruikelijk, tenzij u echt een zeer schrijfintensieve werklast heeft of zeer beperkte middelen toewijst aan SST.
Conclusies
SST is cruciaal maar zwaar en kan mogelijk een langdurige operatie zijn, afhankelijk van de gegevenssetgrootte en de netwerkdoorvoer tussen de knooppunten. Ongeacht de gevolgen zijn er nog steeds mogelijkheden om de operatie te stoppen, zodat we op een beter moment een beter herstelplan kunnen hebben.