Comment démarrer MySQL ou MariaDB Galera Cluster - Mise à jour

Contrairement au serveur MySQL standard et au cluster MySQL, la façon de démarrer un cluster MySQL/MariaDB Galera est un peu différente. Galera vous demande de démarrer un nœud dans un cluster comme point de référence, avant que les nœuds restants puissent rejoindre et former le cluster. Ce processus est connu sous le nom d'amorçage de cluster. L'amorçage est une première étape pour introduire un nœud de base de données en tant que composant principal, avant que d'autres ne le voient comme un point de référence pour synchroniser les données.

Comment ça marche ?

Lorsque Galera démarre avec la commande bootstrap sur un nœud, ce nœud particulier atteindra l'état principal (vérifiez la valeur de wsrep_cluster_status). Les nœuds restants nécessiteront simplement une commande de démarrage normale et ils rechercheront automatiquement le composant principal (PC) existant dans le cluster et se joindront pour former un cluster. La synchronisation des données se produit ensuite via un transfert d'état incrémentiel (IST) ou un transfert d'état d'instantané (SST) entre le jointeur et le donateur.

Donc, fondamentalement, vous ne devez amorcer le cluster que si vous souhaitez démarrer un nouveau cluster ou lorsqu'aucun autre nœud du cluster n'est à l'état PRIMARY. Faites attention lorsque vous choisissez l'action à entreprendre, sinon vous risquez de vous retrouver avec des clusters fractionnés ou une perte de données.

Les exemples de scénarios suivants illustrent quand amorcer un cluster à trois nœuds en fonction de l'état du nœud (wsrep_local_state_comment) et de l'état du cluster (wsrep_cluster_status) :

État de Galera	Flux d'amorçage

Comment démarrer le cluster Galera ?

Les 3 fournisseurs de Galera utilisent différentes commandes d'amorçage (basées sur la dernière version du logiciel). Sur le premier nœud, exécutez :

• Grappe MySQL Galera (Coder):

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

• Grappe Percona XtraDB (Percona) :

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

• Grappe MariaDB Galera (MariaDB) :

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

La commande ci-dessus n'est qu'un wrapper et ce qu'elle fait réellement est de démarrer l'instance MySQL sur ce nœud avec gcomm:// comme variable wsrep_cluster_address. Vous pouvez également définir manuellement les variables dans my.cnf et exécuter la commande standard de démarrage/redémarrage. Cependant, n'oubliez pas de modifier à nouveau wsrep_cluster_address pour contenir les adresses de tous les nœuds après le démarrage.

Lorsque le premier nœud est actif, exécutez la commande suivante sur les nœuds suivants :

$ service mysql start
$ systemctl start mysql

Le nouveau nœud se connecte aux membres du cluster comme défini par le paramètre wsrep_cluster_address. Il va maintenant récupérer automatiquement la carte du cluster et se connecter au reste des nœuds et former un cluster.

Avertissement :Ne démarrez jamais lorsque vous souhaitez reconnecter un nœud à un cluster existant et n'exécutez JAMAIS le démarrage sur plusieurs nœuds.

Drapeau Safe-to-Bootstrap

Galera à partir de la version 3.19 est livré avec un nouveau drapeau appelé "safe_to_bootstrap" dans grastate.dat. Cet indicateur facilite la décision et empêche les choix dangereux en gardant une trace de l'ordre dans lequel les nœuds sont arrêtés. Le nœud qui a été fermé en dernier sera marqué comme "Safe-to-Bootstrap". Tous les autres nœuds seront marqués comme dangereux pour le démarrage.

En regardant le contenu de grastate.dat (la valeur par défaut est sous MySQL datadir), vous devriez remarquer le drapeau sur la dernière ligne :

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

Lors de l'amorçage du nouveau cluster, Galera refusera de démarrer le premier nœud marqué comme dangereux pour l'amorçage. Vous verrez le message suivant dans les journaux :

"Il n'est peut-être pas sûr d'amorcer le cluster à partir de ce nœud. Ce n'était pas le dernier à quitter le cluster et peut ne pas contenir toutes les mises à jour.

Pour forcer l'amorçage du cluster avec ce nœud, modifiez manuellement le fichier grastate.dat et définissez safe_to_bootstrap sur 1 ."

En cas d'arrêt impur ou de crash dur, tous les nœuds auront "safe_to_bootstrap:0", nous devons donc consulter le moteur de stockage InnoDB pour déterminer quel nœud a validé la dernière transaction dans le cluster. Ceci peut être réalisé en démarrant mysqld avec la variable "--wsrep-recover" sur chacun des nœuds, ce qui produit une sortie comme celle-ci :

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

Le nombre après la chaîne UUID sur la ligne "Position récupérée" est celui à rechercher. Choisissez le nœud qui a le numéro le plus élevé et modifiez son fichier grastate.dat pour définir "safe_to_bootstrap :1", comme indiqué dans l'exemple ci-dessous :

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

Vous pouvez ensuite exécuter la commande bootstrap standard sur le nœud choisi.

Et si les nœuds ont divergé ?

Dans certaines circonstances, les nœuds peuvent avoir divergé les uns des autres. L'état de tous les nœuds peut devenir non principal en raison d'une division du réseau entre les nœuds, d'un crash de cluster ou si Galera rencontre une exception lors de la détermination du composant principal. Vous devrez ensuite sélectionner un nœud et le promouvoir en tant que composant principal.

Pour déterminer quel nœud doit être amorcé, comparez la valeur wsrep_last_committed sur tous les nœuds de base de données :

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

À partir des sorties ci-dessus, node2 a les données les plus à jour. Dans ce cas, tous les nœuds Galera sont déjà démarrés, vous n'avez donc pas nécessairement besoin de redémarrer le cluster. Nous avons juste besoin de promouvoir node2 en tant que composant principal :

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

Les nœuds restants se reconnecteront ensuite au composant principal (nœud2) et resynchroniseront leurs données en fonction de ce nœud.

Ou depuis ClusterControl > Performances > État de la base de données page :