1 votes

Aeesyah avatar

Le nœud de cluster MariaDB Galera ne peut pas démarrer après avoir été mis hors service.

Demandé el 26 de Novembre, 2016
Quand la question a-t-elle été
20885 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Mon environnement :

  • Deux nœuds - CentOS 6.4 x86_64

    Node1 : 10.10.201.3

    Node2 : 10.10.201.4

  • MariaDB-server-10.2.0-1.el6.x86_64

Les deux nœuds fonctionnent normalement, mais après avoir redémarré mysql sur le nœud 1, il ne pourra pas redémarrer alors que mysql sur le nœud 2 continue à fonctionner sans problème.

Configuration sur Node1 :

#/etc/my.cnf.d/server.cnf

node1
bind-address=10.10.201.3
datadir=/opt/mysql
socket=/opt/mysql/mysql.sock
handlersocket_address="10.10.201.3"
handlersocket_port="9998"
handlersocket_port_wr="9999"
open_files_limit = 25600
log-error=/opt/mysql/log/mysqld.log
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.201.4,10.10.201.3"
wsrep_cluster_name='galera_cluster_www'
wsrep_node_address='10.10.201.3'
wsrep_node_name='www-node1'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:password
wsrep-slave-threads=16
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON
wsrep_max_ws_size = 2G
binlog_row_image = minimal

Configuration sur Node2 :

#/etc/my.cnf.d/server.cnf

node2
bind-address=10.10.201.4
datadir=/opt/mysql
socket=/opt/mysql/mysql.sock
handlersocket_address="10.10.201.4"
handlersocket_port="9998"
handlersocket_port_wr="9999"
open_files_limit = 25600
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.201.3,10.10.201.4"
wsrep_cluster_name='galera_cluster_www'
wsrep_node_address='10.10.201.4'
wsrep_node_name='www-node2'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:password
wsrep-slave-threads=16
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON
wsrep_max_ws_size = 2G
binlog_row_image = minimal

Et enfin, Information sur le Cluster sur Node2 après l'échec de mysql sur le premier noeud (Node1) :

MariaDB [(none)]> show status like 'wsrep%';

+------------------------------+--------------------------------------+
| Variable_name                | Value                                |
+------------------------------+--------------------------------------+
| wsrep_apply_oooe             | 0.017353                             |
| wsrep_apply_oool             | 0.000050                             |
| wsrep_apply_window           | 1.021550                             |
| wsrep_causal_reads           | 0                                    |
| wsrep_cert_deps_distance     | 24.564685                            |
| wsrep_cert_index_size        | 48                                   |
| wsrep_cert_interval          | 0.021750                             |
| wsrep_cluster_conf_id        | 69                                   |
| wsrep_cluster_size           | 1                                    |
| wsrep_cluster_state_uuid     | c07f825f-132f-11e6-b219-d7e841605104 |
| wsrep_cluster_status         | Primary                              |
| wsrep_commit_oooe            | 0.000000                             |
| wsrep_commit_oool            | 0.000034                             |
| wsrep_commit_window          | 1.005403                             |
| wsrep_connected              | ON                                   |
| wsrep_evs_delayed            |                                      |
| wsrep_evs_evict_list         |                                      |
| wsrep_evs_repl_latency       | 0/0/0/0/0                            |
| wsrep_evs_state              | OPERATIONAL                          |
| wsrep_flow_control_paused    | 0.000000                             |
| wsrep_flow_control_paused_ns | 0                                    |
| wsrep_flow_control_recv      | 0                                    |
| wsrep_flow_control_sent      | 0                                    |
| wsrep_gcomm_uuid             | 401f6755-71da-11e6-8244-9e88079ed6c4 |
| wsrep_incoming_addresses     | 10.10.201.4:3306                     |
| wsrep_last_committed         | 2364263                              |
| wsrep_local_bf_aborts        | 116                                  |
| wsrep_local_cached_downto    | 2221069                              |
| wsrep_local_cert_failures    | 23                                   |
| wsrep_local_commits          | 729390                               |
| wsrep_local_index            | 0                                    |
| wsrep_local_recv_queue       | 0                                    |
| wsrep_local_recv_queue_avg   | 0.004725                             |
| wsrep_local_recv_queue_max   | 6                                    |
| wsrep_local_recv_queue_min   | 0                                    |
| wsrep_local_replays          | 112                                  |
| wsrep_local_send_queue       | 0                                    |
| wsrep_local_send_queue_avg   | 0.000335                             |
| wsrep_local_send_queue_max   | 2                                    |
| wsrep_local_send_queue_min   | 0                                    |
| wsrep_local_state            | 4                                    |
| wsrep_local_state_comment    | Synced                               |
| wsrep_local_state_uuid       | c07f825f-132f-11e6-b219-d7e841605104 |
| wsrep_protocol_version       | 7                                    |
| wsrep_provider_name          | Galera                               |
| wsrep_provider_vendor        | Codership Oy <info@codership.com>    |
| wsrep_provider_version       | 25.3.15(r3578)                       |
| wsrep_ready                  | ON                                   |
| wsrep_received               | 1376816                              |
| wsrep_received_bytes         | 630752657                            |
| wsrep_repl_data_bytes        | 303429595                            |
| wsrep_repl_keys              | 3039261                              |
| wsrep_repl_keys_bytes        | 41097380                             |
| wsrep_repl_other_bytes       | 0                                    |
| wsrep_replicated             | 729452                               |
| wsrep_replicated_bytes       | 391211903                            |
| wsrep_thread_count           | 17                                   |
+------------------------------+--------------------------------------+
Demandé el 26 de Novembre, 2016 par Aeesyah

Réponse

Trop de publicités?

4voto

Utilisateur non enregistré avatar
Utilisateur non enregistré Points 0

J'ai eu le même problème, et finalement après avoir résolu le problème ( sur CentOS 7 - MariaDB-server-10.2.0-1 ), j'ai écrit une documentation sur la façon de le configurer correctement et j'espère qu'elle réparera le vôtre aussi. Suivez les instructions ci-dessous et essayez de construire vos noeuds Galera à partir de zéro. Notez que je n'utiliserai que la configuration obligatoire, vous pourrez y ajouter la vôtre plus tard. Je suppose que vous avez manqué le cinquième étape ou vous ne l'avez pas fait correctement. Quoi qu'il en soit, je vais écrire toutes les étapes pour que tout le monde puisse suivre plus facilement.

Le problème se pose lorsque l'on n'utilise pas l'option galera_new_cluster sur le nœud maître, et vous n'utilisez pas l'adresse appropriée pour la commande wsrep_cluster_address - gcomm . Ainsi, lorsque le maître tombe en panne, les autres nœuds ne peuvent pas revenir vers le pair. (même le maître ne peut pas revenir dans le cluster).

Considérons 3 serveurs nommés GLR{1,2,3} et nous allons installer Galera Cluster sur chacun d'eux. - J'expliquerai comment éviter les pannes sur un cluster à deux nœuds dans la septième étape.

ÉTAPE 1

Pour l'installation :

Ouvrir /etc/yum.repos.d/mariadb.repo avec votre éditeur préféré et ajoutez-y les lignes suivantes :

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

ÉTAPE 2

Si vous ne savez pas comment gérer/configurer SELinux, définissez-le en mode permissif et vérifiez vos fichiers journaux après avoir terminé l'installation pour effectuer les étapes nécessaires à sa gestion. Vous pouvez également avoir besoin d'avoir setroubleshoot-server y setools-console installés pour mieux comprendre vos journaux SELinux.

Mais si SELinux est activé et que vous ne voulez pas le mettre en mode permissif, vous devez savoir qu'il peut empêcher mysqld d'effectuer les opérations requises. Vous devez donc le configurer pour permettre à mysqld d'exécuter des programmes externes et d'ouvrir des sockets d'écoute sur des ports non privilégiés, c'est-à-dire des choses qu'un utilisateur non privilégié peut faire.

L'enseignement de la gestion de SELinux dépasse le cadre de cette réponse, mais vous pouvez le configurer en mode permissif uniquement pour les éléments suivants mysql en effectuant la commande suivante :

semanage permissive -a mysql_t

ÉTAPE 3

Après l'installation en utilisant yum Ajoutez les lignes suivantes à la fin de /etc/my.cnf.d/server.cnf comme indiqué ci-dessous sur chaque serveur GLR respectivement :

[GLR1]

$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR1 IP}'
wsrep_node_name='GLR1'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

[GLR2]

$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR2 IP}'
wsrep_node_name='GLR2'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

[GLR3]

$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR3 IP}'
wsrep_node_name='GLR3'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

ÉTAPE 4

Redémarrez tous les serveurs.

ÉTAPE 5

Utilisez la commande suivante sur GLR1 uniquement, puis redémarrez mariadb.service sur GLR2 et GLR3 :

$ galera_new_cluster
$ sevice mysql start

ÉTAPE 6

Comme vous l'avez remarqué dans votre question, vous pouvez tester la connectivité entre les serveurs en utilisant la commande suivante :

$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%'"

Ou vérifiez simplement la taille du cluster :

$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"

ÉTAPE 7

D'autre part, après avoir terminé toutes les étapes ci-dessus, vous pouvez utiliser cette Article fourni par le site galeracluster sur la façon d'éviter qu'une défaillance d'un seul nœud entraîne l'arrêt du fonctionnement de l'autre si vous voulez utiliser un cluster à DEUX NŒUDS.

Deux solutions s'offrent à vous :

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

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

Le nœud survivant devient ainsi un nouveau composant primaire. Lorsque l'autre nœud revient en ligne ou retrouve la connectivité réseau avec ce nœud, il lance un transfert d'état et rattrape ce nœud.

  • Dans le cas où vous souhaitez que le nœud continue à fonctionner, vous pouvez utiliser la fonction pc.ignore_sb wsrep option fournisseur. Pour ce faire, connectez-vous au client de la 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 il continuera à le faire, même s'il soupçonne une situation de cerveau divisé.

Note Avertissement : Activer pc.ignore_sb est dangereux dans une configuration multi-maître, en raison du risque susmentionné de situations de cerveau divisé. Cependant, cela simplifie les choses dans les clusters maître-esclave (surtout dans les cas où vous n'utilisez que deux noeuds).

En plus des solutions proposées ci-dessus, vous pouvez éviter complètement la situation en utilisant Galera Arbitrator. Galera Arbitrator fonctionne comme un nœud impair dans le calcul du 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 primaire, même si l'autre nœud tombe en panne ou perd sa connectivité réseau.

Répondu el 26 de Novembre, 2016 par Utilisateur non enregistré (0 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X