State Snapshot Transfer (SST) to jeden z dwóch sposobów wykorzystywanych przez Galera do przeprowadzania początkowej synchronizacji, gdy węzeł dołącza do klastra, dopóki węzeł nie zostanie zadeklarowany jako zsynchronizowany i stanowi część „komponentu podstawowego”. W zależności od rozmiaru zestawu danych i obciążenia, SST może być błyskawiczne lub kosztowną operacją, która rzuci Twoją usługę bazy danych na kolana.
KST można wykonać na 3 różne metody:
- mysqldump
- rsync (lub rsync_wan)
- xtrabackup (lub xtrabackup-v2, mariabackup)
W większości przypadków preferowanymi opcjami są xtrabackup-v2 i mariabackup. Rzadko widzimy ludzi działających na rsync lub mysqldump w klastrach produkcyjnych.
Problem
Kiedy SST jest inicjowane, w węźle dołączającym uruchamianych jest kilka procesów, które są wykonywane przez użytkownika „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:4949331W węźle dawcy:
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 na duży zestaw danych (setki GB) nie jest zabawny. W zależności od sprzętu, sieci i obciążenia może to potrwać kilka godzin. Zasoby serwera mogą być nasycone podczas operacji. Pomimo tego, że ograniczanie przepustowości jest obsługiwane w SST (tylko dla xtrabackup i mariabackup) przy użyciu opcji --rlimit i --use-memory, nadal jesteśmy narażeni na zdegradowany klaster, gdy brakuje większości aktywnych węzłów. Na przykład, jeśli masz pecha i okaże się, że działa tylko jeden z trzech węzłów. Dlatego zaleca się wykonywanie KST w godzinach ciszy nocnej. Możesz jednak uniknąć KST, wykonując ręczne czynności opisane w tym poście na blogu.
Zatrzymywanie KST
Zatrzymanie KST należy wykonać zarówno na węźle dawcy, jak i węźle łączącym. Łącznik wyzwala SST po określeniu, jak duża jest luka podczas porównywania lokalnego sekwencja Galera z sekwencją klastra. Wykonuje wsrep_sst_{wsrep_sst_method} Komenda. Zostanie on wybrany przez wybranego dawcę, który rozpocznie przesyłanie danych do osoby dołączającej. Węzeł dawcy nie ma możliwości odmowy obsługi przesyłania migawek po wybraniu przez komunikację grupy Galera lub wartości określonej w wsrep_sst_donor zmienny. Po rozpoczęciu synchronizacji i zechcesz cofnąć decyzję, nie ma jednego polecenia, które zatrzymałoby operację.
Podstawowa zasada przy zatrzymywaniu KST to:
- Spraw, by osoba łącząca wyglądała na martwą z punktu widzenia komunikacji grupy Galera (zamknięcie, ogrodzenie, zablokowanie, resetowanie, odłączenie kabla, czarna lista itp.)
- Zabij procesy SST u dawcy
Można by pomyśleć, że zabicie procesu innobackupex (zabij -9 {innobackupex PID}) na dawcy wystarczy, ale tak nie jest. Jeśli zabijesz procesy SST u dawcy (lub osoby dołączającej) bez odgrodzenia osoby dołączającej, Galera nadal będzie widzieć osobę dołączającą jako aktywną i oznaczy proces SST jako nieukończony, odradzając w ten sposób nowy zestaw procesów, aby kontynuować lub zacząć od nowa. Wrócisz do punktu wyjścia. Jest to oczekiwane zachowanie skryptu /usr/bin/wsrep_sst_{method} w celu ochrony operacji SST, która jest podatna na przekroczenie limitu czasu (np. jeśli jest długotrwałe i intensywnie wykorzystuje zasoby).
Spójrzmy na przykład. Mamy uszkodzony węzeł dołączający, do którego chcielibyśmy ponownie dołączyć do klastra. Zaczęlibyśmy od uruchomienia następującego polecenia na łączniku:
$ systemctl start mysql # or service mysql startMinutę później dowiedzieliśmy się, że w tym momencie operacja jest zbyt ciężka i postanowiliśmy ją przełożyć na później, w godzinach o małym natężeniu ruchu. Najprostszym sposobem na zatrzymanie metody SST opartej na xtrabackup jest po prostu zamknięcie węzła łączącego i zabicie procesów związanych z SST w węźle dawcy. Alternatywnie możesz również zablokować porty przychodzące na łączniku, uruchamiając następujące polecenie iptables na łączniku:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPNastępnie na dawcy pobierz PID procesów SST (wymień procesy należące do użytkownika „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 mysqldNa koniec zabij je wszystkie z wyjątkiem procesu mysqld (musisz być bardzo ostrożny, aby NIE zabić procesu mysqld na dawcy!):
$ kill -9 117814 120036 120037Następnie w dzienniku błędów MySQL dawcy powinieneś zauważyć następujący wiersz pojawiający się po ~100 sekundach:
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)W tym momencie dawca powinien powrócić do stanu „zsynchronizowanego” zgłoszonego przez wsrep_local_state_comment a proces KST zostaje całkowicie zatrzymany. Darczyńca powrócił do stanu operacyjnego i jest w stanie w pełni obsługiwać klientów.
Aby przeprowadzić proces czyszczenia na łączniku, możesz po prostu opróżnić łańcuch iptables:
$ iptables -FLub po prostu usuń reguły za pomocą flagi -D:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPPodobne podejście można zastosować z innymi metodami SST, takimi jak rsync, mariabackup i mysqldump.
Ograniczanie SST (tylko metoda xtrabackup)
W zależności od tego, jak zajęty jest dawca, dobrym podejściem jest ograniczenie procesu KST, aby nie wpłynął znacząco na dawcę. Widzieliśmy wiele przypadków, w których podczas katastrofalnych awarii użytkownicy desperacko chcieli przywrócić nieudany klaster jako pojedynczy węzeł z ładowaniem początkowym i pozwolić pozostałym członkom na nadrobienie zaległości później. Ta próba skraca czas przestoju po stronie aplikacji, jednak tworzy dodatkowe obciążenie dla tego „klastra z jednym węzłem”, podczas gdy pozostałe elementy nadal nie działają lub się odzyskują.
Xtrabackup można ograniczyć za pomocą opcji --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Więcej szczegółów na stronie dokumentacji Percona Xtrabackup SST.
Jest jednak pewien haczyk. Proces może być tak powolny, że nigdy nie dogoni dzienników transakcji pisanych przez InnoDB, więc SST może nigdy się nie zakończyć. Ogólnie rzecz biorąc, taka sytuacja jest bardzo rzadka, chyba że masz naprawdę duże obciążenie związane z zapisem lub przeznaczasz bardzo ograniczone zasoby na SST.
Wnioski
SST jest krytyczny, ale ciężki i potencjalnie może być długotrwałą operacją w zależności od rozmiaru zestawu danych i przepustowości sieci między węzłami. Niezależnie od konsekwencji, nadal istnieją możliwości przerwania operacji, abyśmy mogli mieć lepszy plan naprawy w lepszym czasie.
