web-dev-qa-db-fra.com

mariadb galera - Erreur lors de l'arrêt du noeud ERROR 1047 WSREP n'a pas encore préparé le noeud pour l'utilisation de l'application

J'ai installé 2 nœuds Mariadb Galera (mariadb-galera-10.0.27-linux-x86_64.tar.gz) sur 2 serveurs CentO 6.6. 

Une fois installé, je lance node1 avec le paramètre --wsrep-new-cluster, puis lance node2 sans ce paramètre. Ils fonctionnent bien, les données sont synchronisées avec succès entre 2 nœuds. 

Mais, quand j'ai arrêté node1. Node2 toujours en cours d'exécution, mais lorsque j'essaie d'accéder à la base de données. Il montre cette erreur: 

use testdb;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Qu'est-ce qui se passe dans ce cas? Voici ma configuration sur 2 NODES (adresse IP différente) 

[galera] 
wsrep_on=ON
wsrep_cluster_name='mysql-cluster'
wsrep_provider='/home/mariadb/mariadb-galera/lib/galera/libgalera_smm.so'
wsrep_provider_options="gcache.size=1G"
wsrep_cluster_address="gcomm://10.211.26.116:4567?

pc.wait_prim=no"
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_node_address=10.211.26.117:4567
wsrep_node_name='db2'
mariadbgalera
5
namdt55555

Deux groupes de noeuds

Dans un cluster two-node, une défaillance de single-node provoque l'arrêt du travail de l'autre.

Situation

Vous avez un cluster composé de seulement deux nœuds. L'un des nœuds quitte le cluster de manière disgracieuse. En d’autres termes, au lieu d’être arrêté via init ou systemd, il se bloque ou subit une perte de connectivité réseau. Le nœud qui reste devient non opérationnel. Il en reste ainsi jusqu'à ce que des informations supplémentaires soient fournies par une tierce partie, telle qu'un opérateur humain ou un autre nœud.

Si le nœud restait opérationnel après que l'autre ait quitté le cluster sans grâces, chacun des deux nœuds risquerait de se penser comme étant le composant principal. Pour éviter cela, le nœud devient non opérationnel.

Solutions

Deux solutions s'offrent à vous:

  • Vous pouvez amorcer le nœud survivant pour former un nouveau composant principal, à l'aide de l'option pc.boostrap wsrep Provider. Pour ce faire, connectez-vous au client de base de données et exécutez la commande suivante:

SET GLOBAL wsrep_provider_options = 'pc.bootstrap = YES';

Cela amorce le nœud survivant en tant que nouveau composant principal. Lorsque l'autre nœud revient en ligne ou regagne la connectivité réseau avec ce nœud, il initie un transfert d'état et rattrape ce nœud.

  • Si vous souhaitez que le nœud continue à fonctionner, vous pouvez utiliser l'option pc.ignore_sb wsrep Provider. Pour ce faire, connectez-vous au client de base de données et exécutez la commande suivante:

SET GLOBAL wsrep_provider_options = 'pc.ignore_sb = TRUE';

Le nœud reprend le traitement des mises à jour et continuera à le faire, même s'il suspecte une situation de scission du cerveau.

Remarque: l'activation de pc.ignore_sb est dangereuse dans une configuration multi-maîtres, en raison du risque susmentionné pour les situations à cerveau divisé. Cependant, cela simplifie les choses dans les clusters maître-esclave (en particulier n'utilisez que deux nœuds).

En plus des solutions fournies ci-dessus, vous pouvez éviter la situation entièrement avec Galera Arbitrator. Galera Arbitrator fonctionne comme un nœud impair dans les calculs de quorum. Cela signifie que si vous activez Galera Arbitrator sur un nœud d'un cluster à deux nœuds, ce nœud reste le composant principal, même si l'autre nœud échoue ou perd la connectivité réseau.

http://galeracluster.com/documentation-webpages/twonode.html

6
scarface_90

La raison probable est que votre node1 s'est effondré de façon disgracieuse, ou du moins que ce soit ce que pensait noeud2. Dans ce cas, le cluster à 2 nœuds atteint une situation de cerveau divisé, où les parties restantes du cluster ne peuvent pas décider si elles sont supposées être le composant principal. C'est pourquoi les clusters à 2 nœuds ne sont pas recommandés. 

Consultez les journaux de node1 pour voir s’il s’est arrêté normalement et, le cas échéant, les journaux de node2 pour voir comment il a perçu la situation. S'il voyait un arrêt normal de node1, il dirait quelque chose comme: 

[Note] WSREP: forgetting xxxxxxx (tcp://X.X.X.X:XXXX)

etc.; mais s'il pensait que l'autre noeud était perdu, ce serait plutôt comme

[Note] WSREP: (70f85e74, 'tcp://x.x.x.x:xxxx') turning message relay requesting on, nonlive peers: tcp://X.X.X.X:XXXX

etc. 

Voir http://nirbhay.in/blog/2015/02/split-brain/ pour plus de détails et consigner des exemples de la situation de division du cerveau. 

Le moyen le moins coûteux de l'éviter est de recourir à l'arbitre Galera: http://nirbhay.in/blog/2013/11/what-is-galera-arbitrator/

1
elenst