State Snapshot Transfer (SST) je jedním ze dvou způsobů, které Galera používá k provedení počáteční synchronizace, když se uzel připojuje ke clusteru, dokud není uzel deklarován jako synchronizovaný a není součástí „primární komponenty“. V závislosti na velikosti datové sady a pracovní zátěži může být SST bleskově rychlý nebo nákladná operace, která vaši databázovou službu srazí na kolena.
SST lze provést pomocí 3 různých metod:
- mysqldump
- rsync (nebo rsync_wan)
- xtrabackup (nebo xtrabackup-v2, mariabackup)
Většinu času jsou preferovanými možnostmi xtrabackup-v2 a mariabackup. Zřídka vidíme lidi, kteří běží na rsync nebo mysqldump v produkčních clusterech.
Problém
Když je spuštěn SST, je spuštěno několik procesů na spojovacím uzlu, které jsou spuštěny uživatelem "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:4949331Na dárcovském uzlu:
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 proti velkému datovému souboru (stovky GB) není žádná legrace. V závislosti na hardwaru, síti a zátěži může dokončení trvat hodiny. Prostředky serveru mohou být během operace přesyceny. Přestože je v SST podporováno omezení (pouze pro xtrabackup a mariabackup) pomocí voleb --rlimit a --use-memory, stále jsme vystaveni degradovanému clusteru, když vám dochází většina aktivních uzlů. Například pokud máte tu smůlu a zjistíte, že běží pouze jeden ze tří uzlů. Proto se doporučuje provádět SST během klidových hodin. SST se však můžete vyhnout provedením několika ručních kroků, jak je popsáno v tomto příspěvku na blogu.
Zastavení testu SST
Zastavení SST je třeba provést na dárcovských i spojovacích uzlech. Spojovač spustí SST poté, co určí, jak velká je mezera při porovnání místního seqno Galery se seqno clusteru. Provádí wsrep_sst_{wsrep_sst_method} příkaz. To bude vybráno vybraným dárcem, který začne vysílat data spojovateli. Dárcovský uzel nemá žádnou možnost odmítnout poskytnout přenos snímku, jakmile je vybrán komunikací skupiny Galera nebo hodnotou definovanou v wsrep_sst_donor variabilní. Jakmile začne synchronizace a vy chcete vrátit rozhodnutí, neexistuje jediný příkaz k zastavení operace.
Základní princip při zastavení SST je:
- Z komunikačního hlediska skupiny Galera (vypnutí, plot, blokování, resetování, odpojení kabelu, černá listina atd.) bude truhlář vypadat jako mrtvý.
- Zabijte procesy SST na dárci
Člověk by si myslel, že by stačilo zabít proces innobackupex (kill -9 {innobackupex PID}) na dárci, ale není tomu tak. Pokud zabijete procesy SST na dárci (nebo spojovateli), aniž byste se odpojili od spojovatele, Galera stále vidí spojovatele jako aktivního a označí proces SST jako nedokončený, čímž se obnoví nová sada procesů, které budou pokračovat nebo začít znovu. Vrátíte se na začátek. Toto je očekávané chování skriptu /usr/bin/wsrep_sst_{method} k zabezpečení provozu SST, který je zranitelný vůči časovým limitům (např. pokud je dlouhodobý a náročný na zdroje).
Podívejme se na příklad. Máme zhroucený spojovací uzel, který bychom chtěli znovu připojit ke clusteru. Začali bychom spuštěním následujícího příkazu na spojovacím prvku:
$ systemctl start mysql # or service mysql startO minutu později jsme zjistili, že provoz je v danou chvíli příliš těžký, a rozhodli jsme se jej odložit na později v době nízkého provozu. Nejpřímější způsob, jak zastavit metodu SST založenou na xtrabackup, je jednoduše vypnout spojovací uzel a zabít procesy související s SST na donorovém uzlu. Případně můžete také zablokovat příchozí porty na spojovači spuštěním následujícího příkazu iptables na spojovači:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPPoté na dárci získejte PID procesů SST (vypište procesy vlastněné uživatelem "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 mysqldNakonec je zabijte všechny kromě procesu mysqld (musíte být extrémně opatrní, abyste NEZABILI proces mysqld na dárci!):
$ kill -9 117814 120036 120037Potom byste si v protokolu chyb MySQL dárce měli všimnout následujícího řádku, který se objeví po ~100 sekundách:
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)V tomto okamžiku by se měl dárce vrátit do „synchronizovaného“ stavu, jak uvádí wsrep_local_state_comment a proces SST je zcela zastaven. Dárce je zpět ve svém provozním stavu a je schopen obsluhovat klienty v plné kapacitě.
Pro proces čištění na spojce můžete jednoduše propláchnout řetězec iptables:
$ iptables -FNebo jednoduše odstraňte pravidla pomocí parametru -D:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPPodobný přístup lze použít s dalšími metodami SST, jako je rsync, mariabackup a mysqldump.
Omezení SST (pouze metoda xtrabackup)
V závislosti na tom, jak je dárce zaneprázdněn, je to dobrý přístup k omezení procesu SST tak, aby dárce výrazně neovlivnil. Viděli jsme řadu případů, kdy se během katastrofických selhání uživatelé zoufale snažili přivést zpět neúspěšný cluster jako jediný uzel s bootstrapy a nechat zbytek členů dohnat později. Tento pokus snižuje prostoje ze strany aplikace, ale vytváří další zátěž pro tento „jednouzelový cluster“, zatímco zbývající členové jsou stále mimo provoz nebo se zotavují.
Xtrabackup lze omezit pomocí --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Více podrobností na stránce dokumentace Percona Xtrabackup SST.
Má to však háček. Proces může být tak pomalý, že nikdy nedožene transakční protokoly, které InnoDB zapisuje, takže SST nemusí být nikdy dokončeno. Obecně je tato situace velmi neobvyklá, ledaže máte skutečně velmi náročné pracovní vytížení nebo pokud SST nepřidělujete velmi omezené zdroje.
Závěry
SST je kritický, ale těžký a může být potenciálně dlouhotrvající operací v závislosti na velikosti datové sady a propustnosti sítě mezi uzly. Bez ohledu na důsledky stále existují možnosti zastavit operaci, abychom mohli mít lepší plán obnovy v lepší čas.