State Snapshot Transfer (SST) è uno dei due modi utilizzati da Galera per eseguire la sincronizzazione iniziale quando un nodo si unisce a un cluster, finché il nodo non viene dichiarato sincronizzato e parte del "componente principale". A seconda delle dimensioni del set di dati e del carico di lavoro, SST potrebbe essere velocissimo o un'operazione costosa che metterà in ginocchio il servizio di database.
L'SST può essere eseguito utilizzando 3 diversi metodi:
- mysqldump
- rsync (o rsync_wan)
- xtrabackup (o xtrabackup-v2, mariabackup)
Il più delle volte, xtrabackup-v2 e mariabackup sono le opzioni preferite. Raramente vediamo persone in esecuzione su rsync o mysqldump nei cluster di produzione.
Il problema
Quando viene avviato SST, ci sono diversi processi attivati sul nodo joiner, che vengono eseguiti dall'utente "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:4949331Mentre sul nodo donatore:
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 contro un set di dati di grandi dimensioni (centinaia di GByte) non è divertente. A seconda dell'hardware, della rete e del carico di lavoro, il completamento potrebbe richiedere ore. Le risorse del server potrebbero essere saturate durante l'operazione. Nonostante la limitazione sia supportata in SST (solo per xtrabackup e mariabackup) utilizzando le opzioni --rlimit e --use-memory, siamo ancora esposti a un cluster degradato quando si esauriscono la maggior parte dei nodi attivi. Ad esempio, se sei abbastanza sfortunato da ritrovarti con un solo nodo su tre in esecuzione. Pertanto, si consiglia di eseguire SST durante le ore di silenzio. Tuttavia, puoi evitare l'SST eseguendo alcuni passaggi manuali, come descritto in questo post del blog.
Interruzione di un SST
L'arresto di un SST deve essere eseguito sia sul nodo donatore che su quello joiner. Il joiner attiva l'SST dopo aver determinato quanto è grande il divario quando si confronta il seqno Galera locale con il seqno del cluster. Esegue il wsrep_sst_{wsrep_sst_method} comando. Questo sarà scelto dal donatore scelto, che inizierà a trasmettere i dati al falegname. Un nodo donatore non ha la capacità di rifiutarsi di servire il trasferimento di istantanee, una volta selezionato dalla comunicazione del gruppo Galera, o dal valore definito in wsrep_sst_donor variabile. Una volta avviata la sincronizzazione e si desidera annullare la decisione, non esiste un unico comando per interrompere l'operazione.
Il principio di base quando si interrompe un SST è:
- Fai sembrare il falegname morto da un punto di vista della comunicazione del gruppo Galera (arresto, recinzione, blocco, ripristino, scollegamento del cavo, lista nera, ecc.)
- Uccidi i processi SST sul donatore
Si potrebbe pensare che uccidere il processo innobackupex (kill -9 {innobackupex PID}) sul donatore sia sufficiente, ma non è così. Se interrompi i processi SST sul donatore (o sul joiner) senza recintare il joiner, Galera può ancora vedere il joiner come attivo e contrassegnerà il processo SST come incompleto, generando così un nuovo set di processi per continuare o ricominciare da capo. Tornerai al punto di partenza. Questo è il comportamento previsto dello script /usr/bin/wsrep_sst_{method} per salvaguardare l'operazione SST che è vulnerabile ai timeout (ad esempio, se è di lunga durata e richiede molte risorse).
Diamo un'occhiata a un esempio. Abbiamo un nodo di joiner bloccato che vorremmo ricongiungere al cluster. Inizieremo eseguendo il seguente comando sul joiner:
$ systemctl start mysql # or service mysql startUn minuto dopo, abbiamo scoperto che l'operazione è troppo pesante in quel particolare momento e abbiamo deciso di rimandarla più tardi nelle ore di basso traffico. Il modo più semplice per interrompere un metodo SST basato su xtrabackup è semplicemente arrestare il nodo di join e terminare i processi relativi a SST sul nodo donatore. In alternativa, puoi anche bloccare le porte in entrata sul joiner eseguendo il seguente comando iptables sul joiner:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPQuindi sul donatore, recupera il PID dei processi SST (elenca i processi di proprietà dell'utente "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 mysqldInfine, uccidili tutti tranne il processo mysqld (devi stare estremamente attento a NON uccidere il processo mysqld sul donatore!):
$ kill -9 117814 120036 120037Quindi, nel registro degli errori MySQL del donatore, dovresti notare la seguente riga che appare dopo circa 100 secondi:
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)A questo punto, il donatore dovrebbe tornare allo stato "sincronizzato" come riportato da wsrep_local_state_comment e il processo SST è completamente interrotto. Il donatore è tornato al suo stato operativo ed è in grado di servire i clienti a pieno regime.
Per il processo di pulizia sul joiner, puoi semplicemente svuotare la catena di iptables:
$ iptables -FO semplicemente rimuovi le regole con -D flag:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPL'approccio simile può essere utilizzato con altri metodi SST come rsync, mariabackup e mysqldump.
Regolazione di un SST (solo metodo xtrabackup)
A seconda di quanto è impegnato il donatore, è un buon approccio per limitare il processo SST in modo che non influisca in modo significativo sul donatore. Abbiamo visto una serie di casi in cui, durante errori catastrofici, gli utenti desideravano disperatamente ripristinare un cluster guasto come un singolo nodo di bootstrap e lasciare che il resto dei membri recuperasse il ritardo in un secondo momento. Questo tentativo riduce i tempi di inattività dal lato dell'applicazione, tuttavia, crea un carico aggiuntivo su questo "cluster a un nodo", mentre i membri rimanenti sono ancora inattivi o in fase di ripristino.
Xtrabackup può essere limitato con --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Maggiori dettagli nella pagina della documentazione di Percona Xtrabackup SST.
Tuttavia, c'è un problema. Il processo potrebbe essere così lento da non raggiungere mai i registri delle transazioni che InnoDB sta scrivendo, quindi SST potrebbe non essere mai completato. In genere, questa situazione è molto rara, a meno che non si disponga di un carico di lavoro molto intenso in scrittura o si allochino risorse molto limitate a SST.
Conclusioni
SST è fondamentale ma pesante e potrebbe potenzialmente essere un'operazione di lunga durata a seconda delle dimensioni del set di dati e del throughput della rete tra i nodi. Indipendentemente dalle conseguenze, ci sono ancora possibilità di interrompere l'operazione in modo da poter avere un piano di recupero migliore in un momento migliore.
