我的环境：
两个节点 – CentOS 6.4 x86_64
节点1：10.10.201.3
节点2：10.10.201.4
MariaDB的服务器，10.2.0-1.el6.x86_64
两个节点都正常运行，但是在Node1上重新启动mysql之后，Node2上的mysql继续运行时将无法再次启动。
Node1上的configuration：
#/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 Node2上的configuration：
#/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
最后，在第一个节点（Node1）上失败mysql之后，节点2上的集群信息：
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 <[email protected]> | | 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 | +------------------------------+--------------------------------------+
我遇到了同样的问题，最后在修复这个问题之后（在CentOS 7 – MariaDB-server-10.2.0-1上 ），我写了一个关于如何正确设置的文档，希望它能解决你的问题。 按照下面的说明，并尝试从头开始build立你的Galera节点。 请注意，我将只使用强制configuration，您可以稍后将其添加到它。 我想你已经错过了第五步，或者你没有做正确的。 无论如何，我会写所有的步骤，让其他人可以更容易地遵循。
如果在主节点上不使用galera_new_cluster命令，并且没有使用wsrep_cluster_address – gcomm的适当地址， wsrep_cluster_address 出现此问题 。 所以当主设备发生故障时，其他节点不能回到对端。 （甚至连主人都不能回来）
考虑3台名为GLR{1,2,3}服务器，我们将在每台服务器上设置Galera集群。 – 我将在第七步中解释如何避免双节点群集上的故障。
安装：
用你最喜欢的编辑器打开/etc/yum.repos.d/mariadb.repo ，并添加以下几行：
[mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.0/centos6-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
如果您不知道如何pipe理/configurationSELinux，请将其设置为宽容模式，并在安装完成后检查您的日志文件，以执行pipe理所需的步骤。 您可能还需要安装setroubleshoot-server和setools-console软件包，以更好地了解您的SELinux日志。
但是，如果您启用了SELinux并且不想将其设置为宽容模式，则应该注意，它可能会阻止mysqld执行所需的操作。 所以你应该configuration它来允许mysqld运行外部程序，并在非特权端口上打开监听套接字 – 也就是说，非特权用户可以做的事情。
教授如何pipe理SELinux不在这个答案的范围之内，但是您可以通过执行以下命令将其设置为只允许mysql请求的许可模式：
semanage permissive -a mysql_t
在使用yum进行安装之后，分别在每个GLR服务器上将以下行添加到/etc/my.cnf.d/server.cnf的末尾，如下所示：
[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
重新启动所有服务器。
仅在GLR1上使用以下命令，然后在GLR2和GLR3上重新启动mariadb.service：
$ galera_new_cluster $ sevice mysql start
正如您在问题中注意到的那样，您可以使用以下命令testing服务器之间的连接性：
$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%'"
或者只是检查群集大小：
$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
另一方面，在完成上述所有步骤之后，您可以使用galeracluster网站提供的本文，了解如何避免单节点故障，如果您想使用双节点集群，则会导致另一节点停止工作。
有两种解决scheme可供您使用：
您可以使用pc.boostrap wsrep提供程序选项引导存活节点以形成新的主要组件。 为此，请login到数据库客户端并运行以下命令：
SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';这会将存活的节点引导为新的主要组件。 当另一个节点恢复在线状态或重新获得与该节点的networking连接时，它将启动一个状态转移并赶上这个节点。
如果您希望节点继续运行，则可以使用pc.ignore_sb wsrep提供程序选项。 为此，请login到数据库客户端并运行以下命令：
SET GLOBAL wsrep_provider_options='pc.ignore_sb=TRUE';节点恢复处理更新，即使在怀疑出现裂脑的情况下，它也会继续这样做。
注意警告：由于上述裂脑情况的风险，在多主设备中启用pc.ignore_sb是危险的。 但是，它可以简化主从群集中的事情（特别是在只使用两个节点的情况下）。
除了上面提供的解决scheme之外，您可以完全避免使用Galera仲裁器的情况。 加莱拉仲裁员在法定人数计算中充当奇数节点。 这意味着，如果在双节点集群中的一个节点上启用Galera仲裁器，即使其他节点出现故障或丢失networking连接，该节点仍然是主要组件。