State Snapshot Transfer (SST) är ett av de två sätt som Galera använder för att utföra initial synkronisering när en nod går med i ett kluster, tills noden deklareras som synkroniserad och en del av den "primära komponenten". Beroende på datauppsättningens storlek och arbetsbelastning kan SST vara blixtsnabb, eller en dyr operation som kommer att få din databastjänst på knä.
SST kan utföras med tre olika metoder:
- mysqldump
- rsync (eller rsync_wan)
- xtrabackup (eller xtrabackup-v2, mariabackup)
För det mesta är xtrabackup-v2 och mariabackup de föredragna alternativen. Vi ser sällan personer som körs på rsync eller mysqldump i produktionskluster.
Problemet
När SST initieras, triggas det flera processer på joinernoden, som exekveras av "mysql"-användaren:
$ 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:4949331Medan du är på donatornoden:
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 mot en stor datamängd (hundratals GByte) är inte kul. Beroende på hårdvara, nätverk och arbetsbelastning kan det ta timmar att slutföra. Serverresurser kan vara mättade under operationen. Trots att strypning stöds i SST (endast för xtrabackup och mariabackup) med alternativen --rlimit och --use-minne, utsätts vi fortfarande för ett försämrat kluster när du får slut på majoritetsaktiva noder. Till exempel, om du har otur att hitta dig själv med endast en av tre noder igång. Därför rekommenderas du att utföra SST under tysta timmar. Du kan dock undvika SST genom att ta några manuella steg, som beskrivs i det här blogginlägget.
Avbryta en SST
Att stoppa en SST måste göras på både donator- och joinernoderna. Sammanfogaren utlöser SST efter att ha bestämt hur stort gapet är när man jämför den lokala Galera-följden med klustrets sekvensnummer. Den kör wsrep_sst_{wsrep_sst_method} kommando. Detta kommer att väljas av den valda givaren, som kommer att börja strömma ut data till ansluten. En donatornod har inga möjligheter att vägra betjäna ögonblicksbildöverföring, en gång vald av Galera-gruppkommunikation, eller av värdet som definierats i wsrep_sst_donor variabel. När synkroniseringen väl har startat och du vill återställa beslutet, finns det inget enskilt kommando för att stoppa operationen.
Grundprincipen när du stoppar en SST är att:
- Få snickaren att se död ut från en Galera-gruppkommunikationssynpunkt (avstängning, stängsel, blockera, återställa, koppla ur kabel, svartlista, etc)
- Döda SST-processerna på givaren
Man skulle kunna tro att det skulle räcka att döda innobackupex-processen (döda -9 {innobackupex PID}) på givaren, men så är inte fallet. Om du dödar SST-processerna på givaren (eller snickaren) utan att stängsla av snickaren, kan Galera fortfarande se snickaren som aktiv och kommer att markera SST-processen som ofullständig, vilket skapar en ny uppsättning processer för att fortsätta eller börja om igen. Du kommer tillbaka till ruta ett. Detta är det förväntade beteendet hos /usr/bin/wsrep_sst_{method}-skriptet för att skydda SST-drift som är sårbar för timeouts (t.ex. om det är långvarigt och resurskrävande).
Låt oss titta på ett exempel. Vi har en kraschad joiner-nod som vi skulle vilja gå med i klustret igen. Vi skulle börja med att köra följande kommando på joinern:
$ systemctl start mysql # or service mysql startEn minut senare fick vi reda på att insatsen är för tung i just det ögonblicket och beslutade att skjuta upp den senare under lågtrafiktimmar. Det enklaste sättet att stoppa en xtrabackup-baserad SST-metod är genom att helt enkelt stänga av joinernoden och döda de SST-relaterade processerna på donatornoden. Alternativt kan du också blockera de inkommande portarna på joinern genom att köra följande iptables-kommando på joinern:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPHämta sedan PID för SST-processer från givaren (lista över processerna som ägs av "mysql"-användaren):
$ 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 mysqldSlutligen, döda dem alla utom mysqld-processen (du måste vara extremt försiktig med att INTE döda mysqld-processen på givaren!):
$ kill -9 117814 120036 120037Sedan, i donatorns MySQL-fellogg, bör du märka att följande rad visas efter ~100 sekunder:
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)Vid denna tidpunkt bör givaren återgå till det "synkroniserade" tillståndet som rapporterats av wsrep_local_state_comment och SST-processen stoppas helt. Givaren är tillbaka till sitt operativa tillstånd och kan betjäna kunder i full kapacitet.
För rensningsprocessen på snickaren kan du helt enkelt spola iptables-kedjan:
$ iptables -FEller helt enkelt ta bort reglerna med -D-flaggan:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPDen liknande metoden kan användas med andra SST-metoder som rsync, mariabackup och mysqldump.
Begränsar en SST (endast xtrabackup-metoden)
Beroende på hur upptagen givaren är, är det ett bra sätt att strypa SST-processen så att den inte påverkar givaren nämnvärt. Vi har sett ett antal fall där användare under katastrofala misslyckanden var desperata efter att få tillbaka ett misslyckat kluster som en enda bootstrapped nod, och låt resten av medlemmarna komma ikapp senare. Detta försök minskar stilleståndstiden från applikationssidan, men det skapar ytterligare börda på detta "ennodskluster", medan de återstående medlemmarna fortfarande är nere eller återhämtar sig.
Xtrabackup kan strypas med --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Mer information på Percona Xtrabackup SST-dokumentationssidan.
Det finns dock en hake. Processen kan vara så långsam att den aldrig kommer ikapp transaktionsloggarna som InnoDB skriver, så SST kanske aldrig slutförs. I allmänhet är denna situation mycket ovanlig, såvida inte om du verkligen har en mycket skrivintensiv arbetsbelastning eller om du allokerar mycket begränsade resurser till SST.
Slutsatser
SST är kritisk men tung och kan potentiellt vara en långvarig operation beroende på datauppsättningsstorleken och nätverkets genomströmning mellan noderna. Oavsett konsekvenserna finns det fortfarande möjligheter att stoppa operationen så att vi kan ha en bättre återhämtningsplan vid ett bättre tillfälle.