Hoe MySQL of MariaDB Galera Cluster te Bootstrap - Bijgewerkt

In tegenstelling tot de standaard MySQL-server en MySQL-cluster, is de manier om een ​​MySQL/MariaDB Galera-cluster te starten een beetje anders. Galera vereist dat u een knooppunt in een cluster als referentiepunt start, voordat de resterende knooppunten zich kunnen aansluiten en het cluster kunnen vormen. Dit proces staat bekend als clusterbootstrap. Bootstrapping is een eerste stap om een ​​databaseknooppunt als primaire component te introduceren, voordat anderen het als een referentiepunt zien om gegevens te synchroniseren.

Hoe werkt het?

Wanneer Galera begint met het bootstrap-commando op een knooppunt, zal dat specifieke knooppunt de primaire status bereiken (controleer de waarde van wsrep_cluster_status). De overige knooppunten hebben alleen een normaal startcommando nodig en ze zoeken automatisch naar een bestaande primaire component (pc) in het cluster en voegen zich bij elkaar om een ​​cluster te vormen. Gegevenssynchronisatie vindt vervolgens plaats via incrementele statusoverdracht (IST) of snapshotstatusoverdracht (SST) tussen de deelnemer en de donor.

Dus eigenlijk moet u het cluster alleen opstarten als u een nieuw cluster wilt starten of als er geen andere knooppunten in het cluster in de PRIMARY-status zijn. Wees voorzichtig bij het kiezen van de te ondernemen actie, anders kunt u eindigen met gesplitste clusters of gegevensverlies.

De volgende voorbeeldscenario's illustreren wanneer een cluster met drie knooppunten moet worden opgestart op basis van de knooppuntstatus (wsrep_local_state_comment) en de clusterstatus (wsrep_cluster_status):

Galera State	Bootstrap-stroom
	Herstart de geïnitialiseerde node.
	Herstart de geïnitialiseerde node. Als u klaar bent, start u het nieuwe knooppunt.
	Bootstrap het meest geavanceerde knooppunt met "pc.bootstrap=1". Herstart de resterende knooppunten, één knooppunt tegelijk.
	Start het nieuwe knooppunt.
	Start het nieuwe knooppunt, één knooppunt tegelijk.
	Bootstrap elk knooppunt. Start de resterende knooppunten, één knooppunt tegelijk.

Hoe Galera Cluster starten?

De 3 Galera-leveranciers gebruiken verschillende bootstrapping-commando's (gebaseerd op de nieuwste versie van de software). Voer op het eerste knooppunt uit:

• MySQL Galera-cluster (coderschap):

  $ 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

De bovenstaande opdracht is slechts een wrapper en wat het eigenlijk doet, is de MySQL-instantie op dat knooppunt starten met gcomm:// als de variabele wsrep_cluster_address. U kunt de variabelen binnen my.cnf ook handmatig definiëren en het standaard start/restart-commando uitvoeren. Vergeet echter niet om wsrep_cluster_address weer terug te veranderen om de adressen naar alle knooppunten na de start te bevatten.

Wanneer het eerste knooppunt live is, voert u het volgende commando uit op de volgende knooppunten:

$ service mysql start
$ systemctl start mysql

Het nieuwe knooppunt maakt verbinding met de clusterleden zoals gedefinieerd door de parameter wsrep_cluster_address. Het haalt nu automatisch de clusterkaart op en maakt verbinding met de rest van de knooppunten en vormt een cluster.

Waarschuwing:Bootstrap nooit als u een knooppunt opnieuw wilt verbinden met een bestaand cluster, en voer NOOIT bootstrap uit op meer dan één knooppunt.

Vlag veilig te gebruiken

Galera die begint met versie 3.19 wordt geleverd met een nieuwe vlag genaamd "safe_to_bootstrap" in grastate.dat. Deze vlag faciliteert de beslissing en voorkomt onveilige keuzes door bij te houden in welke volgorde knooppunten worden afgesloten. Het knooppunt dat het laatst is afgesloten, wordt gemarkeerd als "Safe-to-Bootstrap". Alle andere nodes worden gemarkeerd als onveilig om vanaf te bootstrappen.

Kijkend naar grastate.dat (standaard is onder MySQL datadir) inhoud en je zou de vlag op de laatste regel moeten zien:

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

Bij het bootstrappen van het nieuwe cluster, zal Galera weigeren het eerste knooppunt te starten dat als onveilig was gemarkeerd om vanaf te bootstrappen. U ziet het volgende bericht in de logboeken:

“Het is mogelijk niet veilig om het cluster vanaf dit knooppunt te bootstrappen. Het was niet de laatste die het cluster verliet en bevat mogelijk niet alle updates.

Als u clusterbootstrap met dit knooppunt wilt forceren, bewerkt u het bestand grastate.dat handmatig en stelt u safe_to_bootstrap in op 1 .”

In het geval van onreine afsluiting of harde crash, hebben alle knooppunten "safe_to_bootstrap:0", dus we moeten de InnoDB-opslagengine raadplegen om te bepalen welk knooppunt de laatste transactie in het cluster heeft uitgevoerd. Dit kan worden bereikt door mysqld te starten met de variabele "--wsrep-recover" op elk van de knooppunten, wat een uitvoer als volgt oplevert:

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

Het nummer na de UUID-reeks op de regel "Herstelde positie" is het nummer waarnaar u moet zoeken. Kies het knooppunt met het hoogste nummer en bewerk zijn grastate.dat om "safe_to_bootstrap:1" in te stellen, zoals weergegeven in het onderstaande voorbeeld:

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

U kunt dan het standaard bootstrap-commando uitvoeren op het gekozen knooppunt.

Wat als de knooppunten zijn gedivergeerd?

In bepaalde omstandigheden kunnen knooppunten van elkaar zijn afgeweken. De status van alle knooppunten kan veranderen in niet-primair vanwege een netwerksplitsing tussen knooppunten, een clustercrash of als Galera een uitzondering maakt bij het bepalen van de primaire component. U moet dan een node selecteren en deze promoten als een primaire component.

Om te bepalen welk knooppunt moet worden opgestart, vergelijkt u de wsrep_last_committed waarde op alle DB-knooppunten:

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 |
+----------------------+-------------+

Van bovenstaande uitgangen heeft node2 de meest up-to-date gegevens. In dit geval zijn alle Galera-knooppunten al gestart, dus u hoeft het cluster niet per se opnieuw op te starten. We hoeven alleen node2 te promoten als een primaire component:

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

De overige nodes zullen dan opnieuw verbinding maken met de primaire component (node2) en hun gegevens opnieuw synchroniseren op basis van deze node.

Of via ClusterControl> Prestaties> DB-status pagina: