Hur man startar upp MySQL eller MariaDB Galera Cluster - Uppdaterad

Till skillnad från standard MySQL-server och MySQL-kluster är sättet att starta ett MySQL/MariaDB Galera-kluster lite annorlunda. Galera kräver att du startar en nod i ett kluster som referenspunkt innan de återstående noderna kan gå med och bilda klustret. Denna process är känd som klusterbootstrap. Bootstrapping är ett första steg för att introducera en databasnod som primär komponent, innan andra ser den som en referenspunkt för att synkronisera data.

Hur fungerar det?

När Galera startar med bootstrap-kommandot på en nod, kommer just den noden att nå primärt tillstånd (kontrollera värdet för wsrep_cluster_status). De återstående noderna kommer bara att kräva ett normalt startkommando och de kommer automatiskt att leta efter befintlig primär komponent (PC) i klustret och gå samman för att bilda ett kluster. Datasynkronisering sker sedan genom antingen inkrementell tillståndsöverföring (IST) eller snapshot-tillståndsöverföring (SST) mellan sammanfogaren och givaren.

Så i princip bör du bara bootstrap klustret om du vill starta ett nytt kluster eller när inga andra noder i klustret är i PRIMÄR-tillstånd. Försiktighet bör iakttas när du väljer vilken åtgärd du ska vidta, annars kan du sluta med delade kluster eller förlust av data.

Följande exempelscenarier illustrerar när man ska bootstrap ett kluster med tre noder baserat på nodtillstånd (wsrep_local_state_comment) och klustertillstånd (wsrep_cluster_status):

Galera State	Bootstrap Flow
	Starta om den INITIALISERADE noden.
	Starta om den INITIALISERADE noden. När det är klart, starta den nya noden.
	Bootstrap den mest avancerade noden med “pc.bootstrap=1”. Starta om de återstående noderna, en nod i taget.
	Starta den nya noden.
	Starta den nya noden, en nod i taget.
	Bootstrap vilken nod som helst. Starta de återstående noderna, en nod i taget.

Hur startar jag Galera Cluster?

De 3 Galera-leverantörerna använder olika bootstrapping-kommandon (baserat på programvarans senaste version). På den första noden, kör:

• MySQL Galera Cluster (Codership):

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

• Percona XtraDB-kluster (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

Kommandot ovan är bara ett omslag och vad det faktiskt gör är att starta MySQL-instansen på den noden med gcomm:// som variabeln wsrep_cluster_address. Du kan också manuellt definiera variablerna inuti my.cnf och köra standardkommandot start/restart. Glöm dock inte att ändra tillbaka wsrep_cluster_address igen för att innehålla adresserna till alla noder efter starten.

När den första noden är aktiv, kör följande kommando på de efterföljande noderna:

$ service mysql start
$ systemctl start mysql

Den nya noden ansluter till klustermedlemmarna enligt definitionen av parametern wsrep_cluster_address. Den kommer nu automatiskt att hämta klusterkartan och ansluta till resten av noderna och bilda ett kluster.

Varning:Bootstrap aldrig när du vill återansluta en nod till ett befintligt kluster, och kör ALDRIG bootstrap på mer än en nod.

Safe-to-Bootstrap-flagga

Galera som börjar med version 3.19 kommer med en ny flagga som heter "safe_to_bootstrap" inuti grastate.dat. Denna flagga underlättar beslutet och förhindrar osäkra val genom att hålla reda på i vilken ordning noderna stängs av. Noden som stängdes av senast kommer att markeras som "Safe-to-Bootstrap". Alla andra noder kommer att markeras som osäkra att starta från.

Om du tittar på grastate.dat (standard är under MySQL datadir) innehåll och du bör lägga märke till flaggan på sista raden:

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

När det nya klustret startas upp, kommer Galera att vägra starta den första noden som markerades som osäker att starta upp från. Du kommer att se följande meddelande i loggarna:

"Det kanske inte är säkert att starta upp klustret från den här noden. Det var inte den sista som lämnade klustret och kanske inte innehåller alla uppdateringar.

För att tvinga klusterbootstrap med den här noden, redigera filen grastate.dat manuellt och ställ in safe_to_bootstrap till 1.”

I händelse av oren avstängning eller hård krasch kommer alla noder att ha "safe_to_bootstrap:0", så vi måste konsultera InnoDB-lagringsmotorn för att avgöra vilken nod som har begått den senaste transaktionen i klustret. Detta kan uppnås genom att starta mysqld med variabeln "--wsrep-recover" på var och en av noderna, vilket ger en utdata så här:

$ 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
...

Numret efter UUID-strängen på raden "Återställd position" är det du ska leta efter. Välj den nod som har det högsta numret och redigera dess grastate.dat för att ställa in "safe_to_bootstrap:1", som visas i exemplet nedan:

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

Du kan sedan utföra standardkommandot bootstrap på den valda noden.

Vad händer om noderna har divergerat?

Under vissa omständigheter kan noder ha divergerat från varandra. Tillståndet för alla noder kan förvandlas till icke-primär på grund av nätverksdelning mellan noder, klusterkrasch eller om Galera träffar ett undantag när den primära komponenten fastställs. Du måste sedan välja en nod och marknadsföra den till en primär komponent.

För att avgöra vilken nod som behöver bootstraps, jämför wsrep_last_committed-värdet på alla 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 |
+----------------------+-------------+

Från ovanstående utgångar har node2 de mest uppdaterade data. I det här fallet är alla Galera-noder redan startade, så du behöver inte nödvändigtvis starta upp klustret igen. Vi behöver bara marknadsföra nod2 till att vara en primär komponent:

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

De återstående noderna kommer sedan att återansluta till den primära komponenten (nod2) och synkronisera om sina data baserat på denna nod.

Eller från ClusterControl> Prestanda> DB Status sida: