Sådan bootstrap MySQL eller MariaDB Galera Cluster - Opdateret

I modsætning til standard MySQL-server og MySQL Cluster, er måden at starte en MySQL/MariaDB Galera Cluster på en smule anderledes. Galera kræver, at du starter en node i en klynge som et referencepunkt, før de resterende noder kan slutte sig til og danne klyngen. Denne proces er kendt som cluster bootstrap. Bootstrapping er et indledende trin for at introducere en databasenode som primær komponent, før andre ser den som et referencepunkt til at synkronisere data.

Hvordan virker det?

Når Galera starter med bootstrap-kommandoen på en node, vil den pågældende node nå Primær tilstand (tjek værdien af ​​wsrep_cluster_status). De resterende knudepunkter vil blot kræve en normal startkommando, og de vil automatisk lede efter eksisterende Primary Component (PC) i klyngen og slutte sig til en klynge. Datasynkronisering sker derefter gennem enten inkrementel tilstandsoverførsel (IST) eller snapshot-tilstandsoverførsel (SST) mellem joiner og donor.

Så dybest set bør du kun bootstrap klyngen, hvis du vil starte en ny klynge, eller når ingen andre noder i klyngen er i PRIMÆR tilstand. Der skal udvises forsigtighed, når du vælger den handling, der skal udføres, ellers kan du ende med opdelte klynger eller tab af data.

Følgende eksempelscenarier illustrerer, hvornår en tre-node klynge skal bootstrap baseret på nodetilstand (wsrep_local_state_comment) og klyngetilstand (wsrep_cluster_status):

Galera State	Bootstrap Flow
	Genstart den INITIALISEREDE node.
	Genstart den INITIALISEREDE node. Når du er færdig, skal du starte den nye node.
	Bootstrap den mest avancerede node ved hjælp af “pc.bootstrap=1”. Genstart de resterende noder, én node ad gangen.
	Start den nye node.
	Start den nye node, én node ad gangen.
	Bootstrap enhver node. Start de resterende noder, én node ad gangen.

Hvordan starter Galera Cluster?

De 3 Galera-leverandører bruger forskellige bootstrapping-kommandoer (baseret på softwarens seneste version). På den første node, kør:

• MySQL Galera Cluster (Codership):

  $ service mysql bootstrap # sysvinit
  $ galera_new_cluster # systemd
  $ mysqld_safe --wsrep-new-cluster # command line

• Percona XtraDB Cluster (Percona):

  $ service mysql bootstrap-pxc # sysvinit
  $ systemctl start [email protected] # systemd

• MariaDB Galera Cluster (MariaDB):

  $ service mysql bootstrap # sysvinit
  $ service mysql start --wsrep-new-cluster # sysvinit
  $ galera_new_cluster # systemd
  $ mysqld_safe --wsrep-new-cluster # command line

Ovenstående kommando er kun en indpakning, og hvad den faktisk gør, er at starte MySQL-instansen på den node med gcomm:// som wsrep_cluster_address-variablen. Du kan også manuelt definere variablerne inde i my.cnf og køre standard start/genstart kommandoen. Glem dog ikke at ændre wsrep_cluster_address tilbage igen for at indeholde adresserne til alle noder efter starten.

Når den første node er live, skal du køre følgende kommando på de efterfølgende noder:

$ service mysql start
$ systemctl start mysql

Den nye node forbinder til klyngemedlemmerne som defineret af parameteren wsrep_cluster_address. Det vil nu automatisk hente klyngekortet og oprette forbindelse til resten af ​​noderne og danne en klynge.

Advarsel:Bootstrap aldrig, når du vil genforbinde en node til en eksisterende klynge, og kør ALDRIG bootstrap på mere end én node.

Safe-to-Bootstrap-flag

Galera, der starter med version 3.19, kommer med et nyt flag kaldet "safe_to_bootstrap" inde i grastate.dat. Dette flag letter beslutningen og forhindrer usikre valg ved at holde styr på den rækkefølge, hvori noder lukkes ned. Den node, der blev lukket sidst, vil blive markeret som "Safe-to-Bootstrap". Alle de andre noder vil blive markeret som usikre at bootstrap fra.

Ser du på indholdet af grastate.dat (standard er under MySQL datadir), og du bør bemærke flaget på den sidste linje:

# GALERA saved state
version: 2.1
uuid:    8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno:   2575
safe_to_bootstrap: 0

Ved bootstrapping af den nye klynge, vil Galera nægte at starte den første node, der blev markeret som usikker at bootstrap fra. Du vil se følgende besked i loggene:

“Det er muligvis ikke sikkert at bootstrap klyngen fra denne node. Det var ikke den sidste, der forlod klyngen og indeholder muligvis ikke alle opdateringerne.

For at gennemtvinge cluster bootstrap med denne node skal du redigere filen grastate.dat manuelt og indstille safe_to_bootstrap til 1 ."

I tilfælde af uren nedlukning eller hårdt nedbrud vil alle noder have "safe_to_bootstrap:0", så vi er nødt til at konsultere InnoDB-lagringsmotoren for at bestemme, hvilken node der har begået den sidste transaktion i klyngen. Dette kan opnås ved at starte mysqld med variablen "--wsrep-recover" på hver af noderne, som producerer et output som dette:

$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...

Nummeret efter UUID-strengen på linjen "Recovered position" er det, du skal kigge efter. Vælg den node, der har det højeste tal, og rediger dens grastate.dat for at indstille "safe_to_bootstrap:1", som vist i eksemplet nedenfor:

# GALERA saved state
version: 2.1
uuid:    8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno:   -1
safe_to_bootstrap: 1

Du kan derefter udføre standard bootstrap-kommandoen på den valgte node.

Hvad hvis noderne er divergeret?

Under visse omstændigheder kan knudepunkter have divergeret fra hinanden. Tilstanden for alle noder kan blive til ikke-primær på grund af netværksopdeling mellem noder, klyngenedbrud, eller hvis Galera rammer en undtagelse ved bestemmelse af den primære komponent. Du skal derefter vælge en node og promovere den til at være en primær komponent.

For at bestemme, hvilken node der skal bootstrappes, skal du sammenligne wsrep_last_committed-værdien på alle DB-noder:

node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed | 10032       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed | 10348       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed |   997       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

Fra ovenstående udgange har node2 de mest opdaterede data. I dette tilfælde er alle Galera-noder allerede startet, så du behøver ikke nødvendigvis at bootstrap klyngen igen. Vi skal blot fremme node2 til at være en primær komponent:

node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";

De resterende noder vil derefter genoprette forbindelsen til den primære komponent (node2) og gensynkronisere deres data baseret på denne node.

Eller fra ClusterControl> Ydelse> DB Status side: