Eu tive o mesmo problema e, finalmente, após corrigir o problema (no CentOS 7 - MariaDB-server-10.2.0-1 ), eu escrevi uma documentação sobre como configurá-lo corretamente e espero que ele conserte o seu também. Siga as instruções abaixo e tente construir seus nós Galera do zero. Observe que apenas usarei a configuração obrigatória, você poderá adicionar a sua posteriormente. Eu acho que você perdeu o quinto passo ou você não fez isso corretamente. De qualquer forma, vou escrever todos os passos para que qualquer pessoa possa achar mais fácil de seguir.
O problema surge quando você não usa o comando galera_new_cluster no nó mestre e não usa o endereço apropriado para wsrep_cluster_address - gcomm . Portanto, quando o mestre falha, outros nós não podem voltar para o par. (nem mesmo o mestre pode voltar no cluster)
Considere 3 servidores chamados GLR{1,2,3} e vamos configurar o Galera Cluster em cada um deles. - Eu explicarei como evitar falhas no cluster de dois nós na sétima etapa.
PASSO 1
Para instalação:
Abra /etc/yum.repos.d/mariadb.repo com seu editor favorito e adicione as seguintes linhas:
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
PASSO 2
Se você não souber como gerenciar / configurar o SELinux, defina-o como modo permissivo e verifique seus arquivos de log após concluir a instalação para executar as etapas necessárias para gerenciá-lo. Você também pode precisar ter setroubleshoot-server e setools-console packages instalados para entender melhor seus registros do SELinux.
Mas se você tiver o SELinux ativado e não quiser configurá-lo para o modo permissivo, você deve observar que ele pode impedir que o mysqld execute as operações necessárias. Portanto, você deve configurá-lo para permitir que o mysqld execute programas externos e abra sockets de escuta em portas não privilegiadas - isto é, coisas que um usuário sem privilégios pode fazer.
Ensinar como gerenciar o SELinux está além do escopo desta resposta, mas você pode configurá-lo no modo permissivo apenas para mysql solicitações, executando o seguinte comando:
semanage permissive -a mysql_t
PASSO 3
Após a instalação usando yum , adicione as seguintes linhas ao final de /etc/my.cnf.d/server.cnf conforme mostrado abaixo em cada servidor GLR, respectivamente:
[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
PASSO 4
Reinicialize todos os servidores.
PASSO 5
Use o seguinte comando apenas no GLR1 e, em seguida, reinicie o mariadb.service no GLR2 e GLR3:
$ galera_new_cluster
$ sevice mysql start
PASSO 6
Como você percebeu na sua pergunta, você pode testar a conectividade entre servidores usando o seguinte comando:
$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%'"
Ou apenas verifique o tamanho do cluster:
$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
PASSO 7
Por outro lado, depois de concluir todas as etapas acima, você pode usar este Artigo fornecido pelo website galeracluster sobre como evitar uma falha de nó único, fazendo com que o outro pare de funcionar se você quiser usar um cluster TWO-NODE.
There are two solutions available to you:
You can bootstrap the surviving node to form a new Primary Component, using the pc.boostrap wsrep Provider option. To do so, log into the database client and run the following command:
SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';This bootstraps the surviving node as a new Primary Component. When the other node comes back online or regains network connectivity with this node, it will initiate a state transfer and catch up with this node.
In the event that you want the node to continue to operate, you can use the pc.ignore_sb wsrep Provider option. To do so, log into the database client and run the following command:
SET GLOBAL wsrep_provider_options='pc.ignore_sb=TRUE';The node resumes processing updates and it will continue to do so, even in the event that it suspects a split-brain situation.
Note Warning: Enabling pc.ignore_sb is dangerous in a multi-master setup, due to the aforementioned risk for split-brain situations. However, it does simplify things in master-slave clusters, (especially in cases where you only use two nodes).
In addition to the solutions provided above, you can avoid the situation entirely using Galera Arbitrator. Galera Arbitrator functions as an odd node in quorum calculations. Meaning that, if you enable Galera Arbitrator on one node in a two-node cluster, that node remains the Primary Component, even if the other node fails or loses network connectivity.