☰

MariaDB Galera 集群节点关闭后无法启动

tag-icon • tag-icon cluster mariadb galera
MariaDB Galera 集群节点关闭后无法启动

我的环境：

  • 两个节点 - 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上的配置：

#/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上的配置：

#/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 出现故障后，Node2 上的集群信息：

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

答案1

我遇到了同样的问题，最后在修复了这个问题之后（CentOS 7-MariaDB-服务器-10.2.0-1)，我写了一份关于如何正确设置的文档，希望它也能解决你的问题。按照下面的说明尝试从头开始构建你的 Galera 节点。请注意，我将只使用强制配置，你可以稍后添加自己的配置。我猜你错过了第五步或者你没有正确完成。无论如何，我会写下所有步骤，以便其他人可以更轻松地遵循。

当您没有galera_new_cluster在主节点上使用该命令，并且没有使用适当的地址时，就会出现问题wsrep_cluster_address-通讯网。因此，当主节点发生故障时，其他节点无法恢复到对等节点。（集群中的主节点也无法恢复）

考虑 3 台服务器GLR{1,2,3}，我们将在每台服务器上设置 Galera 集群。——我将在第七步解释如何避免双节点集群出现故障。

步骤1

安装：

用您最喜欢的编辑器打开/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

第2步

如果您不知道如何管理/配置 SELinux，请将其设置为宽容模式，并在完成安装后检查日志文件以执行管理它所需的步骤。您可能还需要安装setroubleshoot-server和setools-console软件包以更好地了解您的 SELinux 日志。

但是，如果您启用了 SELinux 并且不想将其设置为宽容模式，则应注意它可能会阻止 mysqld 执行所需的操作。因此，您应该将其配置为允许 mysqld 运行外部程序并在非特权端口上打开侦听套接字 — 即非特权用户可以执行的操作。

教导如何管理 SELinux 超出了本答案的范围，但您可以mysql通过执行以下命令将其设置为仅针对请求的宽容模式：

semanage permissive -a mysql_t

步骤 3

使用安装后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

步骤4

重新启动所有服务器。

步骤 5

仅在 GLR1 上使用以下命令，然后在 GLR2 和 GLR3 上重新启动 mariadb.service：

$ galera_new_cluster
$ sevice mysql start

步骤 6

正如您在问题中注意到的那样，您可以使用以下命令测试服务器之间的连接：

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

或者仅检查集群大小：

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

步骤 7

另一方面，完成上述所有步骤后，您可以使用此文章如果您想使用双节点集群，galeracluster 网站提供了有关如何避免单节点故障导致其他节点停止工作的信息。

有两种解决方案可供您选择：

  • 您可以使用以下方式引导幸存的节点以形成新的主组件：pc.boostrapwsrep 提供程序选项。为此，请登录数据库客户端并运行以下命令：

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

这将引导幸存节点作为新的主组件。当另一个节点重新上线或重新获得与此节点的网络连接时，它将启动状态传输并赶上此节点。

  • 如果您希望节点继续运行，可以使用忽略_sbwsrep 提供程序选项。为此，请登录数据库客户端并运行以下命令：

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

节点将恢复处理更新，并且即使在怀疑出现裂脑情况的情况下也会继续这样做。

注意警告：在多主设置中启用 pc.ignore_sb 是危险的，因为存在上述裂脑风险。但是，它确实简化了主从集群中的事情（特别是在您只使用两个节点的情况下）。

除了上述解决方案外，您还可以使用 Galera Arbitrator 完全避免这种情况。Galera Arbitrator 在仲裁计算中充当奇数节点。这意味着，如果您在双节点集群中的一个节点上启用 Galera Arbitrator，则该节点仍是主要组件，即使另一个节点发生故障或失去网络连接。

相关内容