vlambda
2021-09-23

Galera for MySQL集群安装手册终极版

1.Galera Cluster for MySQL 安装官方指引

Galera Cluster for MySQL 安装手册文字版 https://galeracluster.com/library/documentation/install-mysql.html

Galera Cluster for MySQL 安装手册PPT版 {% pdf /images/galera/galera-mysql-installing.pdf %}

Galera Cluster for MySQL 安装手册视频版 https://galeracluster.com/library/training/videos/galera-mysql-installing.html

配置参数：https://galeracluster.com/library/documentation/mysql-wsrep-options.html#

2.集群安装详细步骤

2.1 在/etc/yum.repos.d/ 的目录下新增gelare.repo文件

[galera]name = Galerabaseurl = https://releases.galeracluster.com/galera-3/DIST/RELEASE/ARCHgpgkey = https://releases.galeracluster.com/GPG-KEY-galeracluster.comgpgcheck = 1
[mysql-wsrep]name = MySQL-wsrepbaseurl = https://releases.galeracluster.com/mysql-wsrep-VERSION/DIST/RELEASE/ARCHgpgkey = https://releases.galeracluster.com/GPG-KEY-galeracluster.comgpgcheck = 1

注意需要替换掉相应的参数，针对自己的环境作出相应的更改。

VERSION是mysql-wsrep的版本，如5.7；DIST是操作系统，如centos；RELEASE是操作系统版本，如7；ARCH是系统架构，如x86_64；

2.2 一键安装

源配置好之后，就可以安装了，只需执行以下命令：

# yum install galera-3 mysql-wsrep-5.7

若网络环境不允许，则可以离线安装，需要按照下面步骤进行安装：使用 (yum install -y 包名)命令进行安装。

安装顺序：    1、 mysql-wsrep-libs-compat-5.7-5.7.23-25.15.el7.x86_64.rpm    2、 mysql-wsrep-common-5.7-5.7.23-25.15.el7.x86_64.rpm    3、 mysql-wsrep-libs-5.7-5.7.23-25.15.el7.x86_64.rpm    4、 mysql-wsrep-devel-5.7-5.7.23-25.15.el7.x86_64.rpm    5、 mysql-wsrep-client-5.7-5.7.23-25.15.el7.x86_64.rpm    6、 mysql-wsrep-server-5.7-5.7.23-25.15.el7.x86_64.rpm    7、 mysql-wsrep-5.7-5.7.23-25.15.el7.x86_64.rpm    8、 mysql-wsrep-test-5.7-5.7.23-25.15.el7.x86_64.rpm（该包在安装时会提示没有 mysql-wsrep-server的依赖，使用rpm 加上–nodeps参数安装，该安装可忽略）    9、 galera-3-25.3.24-2.el7.x86_64

不推荐使用离线安装方式：虽然yum配置的目录中存储的就是离线安装的包，但是每个操作系统版本不同，需要安装不同的包；避免后面发生问题，无法定位是否是安装包版本的问题。

2.3 MySQL初始化

--①.初始化mysql# mysqld --initialize 
--②.查看默认密码# grep 'temporary password' /var/log/mysqld.log
--③.更改权限# chown -R mysql:mysql /var/lib/mysql
--④.启动mysql服务# service mysqld start
--⑤.进入mysql# mysql -uroot -p
--⑥.修改密码# alter user user() identified by "新密码";
--⑦.开放远程登录授权# GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;# flush privileges;
--⑧.关闭mysql服务# service mysqld stop （注意mysql5.7是mysqld）

官方推荐的三步操作法：

# systemctl start mysqld# grep 'temporary password' /var/log/mysqld.log# mysql_secure_installation

官方推荐步骤中 mysql_secure_installation 采用交互式设置方式，虽然简单，但在不熟悉的情况下，建议还是逐个步骤设置，在熟悉后，再使用该命令则效果较好。并且该命令为二进制文件，无法看到具体的执行逻辑源码。

务必注意点：防火墙状态一定需要确认关闭，或者允许指定端口访问，否则会影响集群正常创建！！！

2.4 网络配置&同步工具安装

关闭防火墙(生产上可开放端口)

# setenforce 0 && systemctl stop firewalld

去掉Postfix，这个可能跟MySQL配置有冲突:

# yum remove postfix -y

安装rsync包，后面galera集群节点间数据同步会使用该工具。rsync工具使用方法可参考：http://www.ruanyifeng.com/blog/2020/08/rsync.html

# yum -y install rsync

2.5 节点配置

修改my.cnf

vim /etc/my.cnf，在末尾增加：!includedir /etc/my.cnf.d/

修改wsrep.cnf

vim /etc/my.cnf.d/wsrep.cnf

节点78上wsrep.cnf完整配置：

[mysqld]server-id=78 #每个节点一个唯一的IDbind-address=0.0.0.0
# common settinglower_case_table_names=0table_open_cache=2048query_cache_size=0query_cache_type=0back_log=500skip-name-resolvesql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
# character settingcharacter-set-server=utf8mb4collation-server=utf8mb4_general_ciinit_connect='SET NAMES utf8mb4'default-time-zone='+8:00'
# slow settingslow_query_log=1slow_query_log_file=/data/mysql_data/mysql_slow/localhost-slow.log # 手动创建目录，需要使用chown -R mysql:mysql 该目录权限long_query_time=1log_output=table,filelog_queries_not_using_indexes=1
# innodb settingdefault-storage-engine=innodbinnodb_autoinc_lock_mode=2innodb_locks_unsafe_for_binlog=1innodb_buffer_pool_size=12Ginnodb_max_dirty_pages_pct=75innodb_buffer_pool_chunk_size=128MBinnodb_buffer_pool_instances=8innodb_log_buffer_size=16Minnodb_flush_log_at_trx_commit=1innodb_log_file_size=3072Minnodb_log_files_in_group=2innodb_io_capacity=200innodb_print_all_deadlocks=1innodb_lock_wait_timeout = 50transaction_isolation=REPEATABLE-READ
# client connection settingmax_connections=500max_connect_errors=100000
# wsrepwsrep_on=ONwsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_node_name="node78" #node名称，每个节点名称唯一wsrep_node_address="192.168.36.78" #本节点地址
wsrep_cluster_name="ztgj_mysql_cluster" #集群名称，所有节点配置为同一个wsrep_cluster_address="gcomm://192.168.36.78,192.168.36.79,192.168.36.80" #集群中所有节点地址
wsrep_provider_options="gcs.fc_limit=200;gcs.fc_factor=0.8" #修改为本节点地址
wsrep_slave_threads=40wsrep_certify_nonPK=1wsrep_max_ws_rows=131072wsrep_max_ws_size=1073741824wsrep_debug=0wsrep_convert_LOCK_to_trx=0wsrep_retry_autocommit=1wsrep_auto_increment_control=1wsrep_drupal_282555_workaround=0wsrep_causal_reads=0wsrep_notify_cmd=
wsrep_sst_method=rsyncwsrep_sst_auth=root:ztgjwq666 #数据量库用户名密码wsrep_sst_donor="node78,node79,node80" #节点中所有节点的node名称

节点79上wsrep.cnf配置：

server-id=79 #每个节点一个唯一的ID....
wsrep_node_name="node79" #node名称，每个节点名称唯一wsrep_node_address="192.168.36.79" #本节点地址

节点80上wsrep.cnf配置：

server-id=80 #每个节点一个唯一的ID....
wsrep_node_name="node80" #node名称，每个节点名称唯一wsrep_node_address="192.168.36.80" #本节点地址

2.6 启动集群

①.启动首节点

任意选取一个节点，执行：

# mysqld_bootstrap

参看 mysqld_bootstrap 执行内容：

[root@condition-db2 log]# whereis mysqld_bootstrapmysqld_bootstrap: /usr/bin/mysqld_bootstrap
[root@condition-db2 log]# cat /usr/bin/mysqld_bootstrap OLDVAL=$(systemctl show-environment | grep '^MYSQLD_OPTS=')
if [ -z "$OLDVAL" ]; then systemctl set-environment MYSQLD_OPTS="--wsrep-new-cluster" systemctl start mysqld systemctl unset-environment MYSQLD_OPTSelse systemctl set-environment "$OLDVAL --wsrep-new-cluster" systemctl start mysqld systemctl set-environment "$OLDVAL"fi

-z 判断 "$OLDVAL" 变量是否为空，若为空，则 set-environment MYSQLD_OPTS="--wsrep-new-cluster"，然后启动MySQL systemctl start mysqld，启动成功后，则 systemctl unset-environment MYSQLD_OPTS 清除设置。

防坑注意点：若第一次执行 mysqld_bootstrap 中执行启动mysqld失败，则不会执行 unset-environment，则后面无论执行多少次启动，都无法将节点加入到集群中！！！

预防方法：在每次执行mysqld_bootstrap前，先执行systemctl show-environment | grep '^MYSQLD_OPTS='检查结果是否为空，若不为空，则手动执行systemctl unset-environment MYSQLD_OPTS 清除参数设置。

检查启动结果，不出意外的话，就会显示1，表明这个集群内现在只有一个节点.

# mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

②.启动其它节点

登陆到其它节点上，依次执行：

service mysqld start

然后再查看wsrep_cluster_size数量

2.7 集群状态检查

# show status like 'wsrep%';

集群完整性检查

wsrep_cluster_state_uuid：在集群所有节点的值应该是相同的,有不同值的节点,说明其没有连接入集群. wsrep_cluster_conf_id：正常情况下所有节点上该值是一样的.如果值不同,说明该节点被临时”分区”了.当节点之间网络连接恢复的时候应该会恢复一样的值. wsrep_cluster_size：如果这个值跟预期的节点数一致,则所有的集群节点已经连接. wsrep_cluster_status：集群组成的状态.如果不为”Primary”,说明出现”分区”或是”split-brain”状况.

节点状态检查

wsrep_ready：该值为ON,则说明可以接受SQL负载.如果为Off,则需要检查wsrep_connected. wsrep_connected：如果该值为Off,且wsrep_ready的值也为Off,则说明该节点没有连接到集群.(可能是wsrep_cluster_address或wsrep_cluster_name等配置错造成的.具体错误需要查看错误日志) wsrep_local_state_comment：如果wsrep_connected为On,但wsrep_ready为OFF,则可以从该项查看原因.

复制健康检查

wsrep_flow_control_paused：表示复制停止了多长时间.即表明集群因为Slave延迟而慢的程度.值为0~1,越靠近0越好,值为1表示复制完全停止.可优化wsrep_slave_threads的值来改善. wsrep_cert_deps_distance：有多少事务可以并行应用处理.wsrep_slave_threads设置的值不应该高出该值太多. wsrep_flow_control_sent：表示该节点已经停止复制了多少次. wsrep_local_recv_queue_avg：表示slave事务队列的平均长度.slave瓶颈的预兆. ps：最慢的节点的wsrep_flow_control_sent和wsrep_local_recv_queue_avg这两个值最高.这两个值较低的话,相对更好.

检测慢网络问题

wsrep_local_send_queue_avg：网络瓶颈的预兆.如果这个值比较高的话,可能存在网络瓶

冲突或死锁的数目

wsrep_last_committed：最后提交的事务数目 wsrep_local_cert_failures和wsrep_local_bf_aborts：回滚,检测到的冲突数目

3.集群运维指南

3.1 Galera状态文件

通常在 /var/lib/mysql 目录下会存储Galera的集群信息，也可通过配置datadir来指定Galera存储位置。在该目录下主要有三个文件：

①.gvwstate.dat

当节点将Primary Component状态存储到磁盘时，会保存为gvwstate.dat文件。如果节点正常关闭，则会删除该文件。如果群集在节点关闭后继续运行（即，有其他节点未关闭），则剩余节点之一将成为Primary Component的主机，并在其文件系统上创建gvwstate.dat文件。

my_uuid: af1027d0-1a04-11ec-86ca-57c930759d43#vwbegview_id: 3 af1027d0-1a04-11ec-86ca-57c930759d43 12bootstrap: 0member: af1027d0-1a04-11ec-86ca-57c930759d43 0member: bb0e7607-1a04-11ec-bd8f-af2b63e25777 0member: e8a96415-1a06-11ec-96da-76f17e3872d7 0#vwend

官方文档：https://galeracluster.com/library/documentation/pc-recovery.html

②.grastate.dat

定位最近状态的节点、安全引导保护、定位崩溃的节点

# GALERA saved stateversion: 2.1uuid: db2e443c-1a02-11ec-986a-bbd1796395d8seqno: -1safe_to_bootstrap: 0

③.galera.cache

galera缓存文件，非可读文件

官方文档：https://galeracluster.com/library/kb/customizing-gcache-size.html

3.2 MySQL错误日志

系统日志：/var/log/mysqld.log

mysql错误日志位置查看

# show variables like 'log_error';

3.3 集群重启

官方文档：https://galeracluster.com/library/training/tutorials/restarting-cluster.html

当需要重启整个Galera群集时，若以错误的顺序启动节点，可能会造成灾难性后果，并导致数据丢失。

3.3.1 识别最高级别的节点

通过比较集群中每个节点上的全局事务ID值，来确定最高级的节点状态ID。可以在grastate.dat文件中查找，如果grastate.dat文件如下所示，则该节点即为最高级的节点状态ID：

# GALERA saved stateversion: 2.1uuid: db2e443c-1a02-11ec-986a-bbd1796395d8seqno: 12safe_to_bootstrap: 0

若seqno非大于0的值，则需要查找上次提交的事务的序列号，使用--wsrep recover选项运行mysqld，该命令将相应的全局事务ID值打印到错误日志中，然后退出。使用该命令时，mysql服务务必是停止状态，若mysql服务还未终止，则该命令会一直卡着不会返回，需要手动kill掉该命令。

[root@db2 ~]# mysqld --wsrep-recover --user=mysql[root@db2 ~]# [root@db2 ~]# grep "Recovered position" /var/log/mysqld.log 2021-09-20T11:20:13.844208Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:02021-09-21T05:21:26.637687Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:39:42.770713Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:44:46.217621Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:48:15.066574Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:12[root@db2 ~]# [root@db2 ~]# mysqld --wsrep-recover --user=mysql[root@db2 ~]# [root@db2 ~]# grep "Recovered position" /var/log/mysqld.log 2021-09-20T11:20:13.844208Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:02021-09-21T05:21:26.637687Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:39:42.770713Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:44:46.217621Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:48:15.066574Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:48:25.395356Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:12[root@db2 ~]#

该命令无论执行多少次，都只会输出最后一次的事务ID，该值是节点状态ID。找到该值后，然后手动更新grastate.dat文件中seqno字段为输出结果中的值。

作为替代方案，可以让mysqld_safe自动恢复，并在下次启动数据库服务器时将值传递给数据库服务器，通过将grastate.dat文件中safe_to_bootstrap的值设为1，使用mysqld_bootstrap命令启动该节点，其他节点启动与以前一致。

3.3.2 “安全引导”保护

从版本3.19开始，Galera提供了一个额外的保护，以防止：尝试使用“可能不是群集关闭之前最后一个节点”来引导启动群集。如果Galera能够最终确定哪个节点是最后一个存活的节点，它将被标记为“安全引导”，如下grastate.dat所示：

# GALERA saved stateversion: 2.1uuid: 5981f182-a4cc-11e6-98cc-77fabedd360dseqno: 1234safe_to_bootstrap: 1

这样的节点可用于引导集群，尝试使用任何其他节点进行引导将导致以下错误消息：

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.It was not the last one to leave the cluster and may not contain all the updates.To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

若要覆盖此保护，可以编辑“要用作第一个节点”的grastate.dat文件中的safe_to_bootstrap。

在所有节点同时崩溃的情况下，集群找不到任何一个节点来安全引导，当手动编辑grastate.dat文件后，即可为集群指定安全引导节点。

3.3.3 Gcache恢复

从版本3.19开始，Galera提供了gcache.recover参数。如果设置为“是”，Galera将在节点启动时尝试恢复gcache。如果gcache恢复成功，节点将能够向其他加入节点提供IST，这可以加快整个集群的总体重启时间。

Gcache恢复需要读取整个Gcache文件两次。对于位于慢速磁盘上的大型gcache文件，此操作可能需要一些时间。Gcache恢复是一项“尽力而为”的操作。如果恢复未成功，则节点将继续正常运行，但其他节点在尝试加入时将退回到SST。

3.3.4 识别崩溃节点

通过查看grastate.dat文件的内容，可以轻松确定节点是否崩溃。如果看起来像下面的示例，那该节点要么在执行非事务性操作（例如ALTER TABLE）期间崩溃，要么由于数据库不一致而中止。

# GALERA saved stateversion: 2.1uuid: 5ee99582-bb8d-11e2-b8e3-23de375c1d30seqno: -1cert_index:

如上所述，您可以从InnoDB恢复上次提交的事务的全局事务ID。然而，恢复是毫无意义的。崩溃后，节点状态可能已损坏，可能无法正常工作。如果群集中没有一个具有定义良好状态的节点，则无需保留节点状态ID。您必须执行彻底的数据库恢复过程，类似于在独立数据库服务器上使用的过程。恢复一个节点后，将其用作新集群中的第一个节点。

3.4 故障恢复

官方文档：https://galeracluster.com/library/documentation/crash-recovery.html

Galera集群作为一个逻辑实体，控制其节点的状态、一致性以及整个集群的状态。与异步复制相比，这样可以更高效地维护数据完整性，而不会同时丢失多个节点上的安全写入。然而，可能会出现这样的情况：数据库服务停止，没有节点能够为请求提供服务，这些场景将在下面的章节中描述。

3.4.1 节点1正常停止

在三节点集群（节点 1、2 和 3）中，节点 1 被优雅地停止，用于维护、配置更改等。

在这种情况下，其他节点收到停止节点的“再见”消息，集群规模减小；某些属性（如仲裁计算或自动增量）会自动更改。一旦节点 1 再次启动，它就会根据其wsrep_cluster_address中的变量加入集群my.cnf。

如果写集缓存在节点2或节点3上执行时，在节点1关闭时仍然执行了所有事务，则可以通过IST加入。如果由于donor的gcache中缺少事务而无法进行IST，则由donor做出回退决定，并自动启动SST。

3.4.2 两个节点正常停止

在3.4.1章节的情景下，集群大小减少到1个，即使是单个剩余的节点 3 也可以构成了primary组件，可以为客户端请求提供服务。要将其它节点重新加入集群，只需启动它们。

但是，当新节点加入集群时，节点 3 将切换到“Donor/Desynced”状态，因为它必须至少向第一个加入节点提供状态转移。在该过程中仍然可以对其进行读/写，但可能会慢得多，这取决于在状态传输期间应该发送多少数据。此外，一些负载均衡器可能会认为donor节点无法运行并将其从池中删除。所以，最好避免只有一个节点up的情况。

如果重新启动节点 1 和节点 2，请确保节点 2 不使用节点 1 作为状态转移donor：节点 1 的 gcache 中可能没有所有需要的写集。在配置文件中指定节点 3 节点作为donor并启动mysql服务：systemctl start mysql

3.4.3 所有三个节点都正常停止

集群完全停止，关键问题是如何再次初始化。很重要的一点是：节点将其最后执行的位置写入grastate.dat文件。通过比较此文件中的seqno编号，可以看到哪个是最先进的节点（很可能是最后一个停止的）。必须使用此节点引导集群，否则具有更高先进位置的节点将必须执行完整的 SST 才能加入从不太高级的集群初始化的集群。因此，一些事务将丢失）。要引导第一个节点，请像这样调用启动脚本：

//对于 MySQL：$ mysqld_bootstrap --wsrep-new-cluster
//对于 PXC：$ systemctl start mysql@bootstrap.service
//对于 MariaDB：$ galera_new_cluster

注意：即使从最高级的节点引导，其他节点的序列号也较低。他们仍然必须通过完整的 SST 加入，因为 Galera Cache 在重新启动时不会保留。为此，建议在集群完全关闭之前停止写入集群，以便所有节点可以停在同一位置。

3.4.4 一个节点从集群中消失

当一个节点由于断电、硬件故障、内核崩溃、mysqld 崩溃或通过kill -9使mysqld pid而变得不可用时，剩下的两个节点观察到与节点 1 的连接已关闭，并开始尝试重新连接它。几次超时后，节点 1 从集群中删除。quorum会保存更新（三个节点中有两个已启动），因此不会发生服务中断。重新启动后，节点 1 会自动加入，和“节点 1 正常停止”中所述一样。

3.4.5 两个节点从集群中消失

两个节点不可用，其余节点（节点 3）无法单独形成quorum。集群必须切换到non-primary模式，其中 MySQL 拒绝提供任何 SQL 查询。在这种状态下，节点 3 上的“mysqld”进程仍在运行并且可以连接，但是与data相关的任何语句都失败并显示错误。如下示例：

mysql> select * from test.sbtest1;ERROR 1047 (08S01): WSREP has not yet prepared node for application use

在节点 3 判定它不能访问节点 1 和节点 2 之前，可以进行读取。禁止新的写入。一旦其他节点可用，集群就会自动再次形成。如果节点 2 和节点 3 只是与节点 1 进行网络隔离，但它们仍然可以相互访问，则它们将继续运行，因为它们仍然构成quorum。如果节点 1 和节点 2 崩溃，您需要手动启用节点 3 上的primary组件，然后才能启动节点 1 和节点 2。执行此操作的命令是：

mysql> SET GLOBAL wsrep_provider_options='pc.bootstrap=true';

这种方法仅适用于其他节点在执行此操作之前已关闭的情况！否则，最终会得到两个具有不同数据的集群。

3.4.6 所有节点在没有正确关闭程序的情况下关闭

这种情况可能发生在数据中心电源故障或遇到 MySQL 或 Galera 错误时。此外，这可能是由于数据一致性被破坏，集群检测到每个节点具有不同的数据。该文件未更新且不包含有效序列号 (seqno)。grastate.dat可能看起来像这样：

$ cat /var/lib/mysql/grastate.dat# GALERA saved stateversion: 2.1uuid: 220dcdcb-1629-11e4-add3-aec059ad3734seqno: -1safe_to_bootstrap: 0

在这种情况下，您无法确定所有节点都彼此一致。我们不能使用safe_to_bootstrap变量来确定提交了最后一个事务的节点，因为它对于每个节点都设置为 0。除非使用mysqld --wsrep-recover，否则尝试从此类节点引导将导致失败。

恢复位置标记为最大数字的节点是最佳引导候选数据。在grastate.dat中，将safe_to_bootstrap变量设置为1，然后，从此节点引导启动。

3.4.7 由于脑裂，集群失去了主要状态

假设我们有一个由偶数个节点组成的集群：例如，六个。其中三个在一个位置，而另外三个在另一个位置，并且它们失去了网络连接。避免这种拓扑结构的最佳做法是：如果您不能拥有奇数个实际节点，则可以使用额外的仲裁节点或pc.weight为某些节点设置更高的值。但是当脑裂以任何方式发生时，没有一个分离的组可以维持仲裁：所有节点必须停止服务请求，集群的两个部分将不断尝试重新连接。

如果你想在网络链接恢复之前恢复服务，可以使用“3.4.5 两个节点从集群中消失”中所述的相同命令再次将其中一个组设为主组。

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

此后，你可以处理集群的手动恢复部分，而另一半部分应该能够在网络链接恢复后立即使用 IST 自动重新加入。

注意：如果在两个分离的部分上都设置了 bootstrap 选项，您将最终得到两个活动的集群实例，而数据可能会彼此分开。在这种情况下恢复网络链接不会使它们重新加入，直到节点重新启动并且配置文件中指定的成员再次连接。那么，由于Galera复制模型真正关心的是数据的一致性：一旦检测到不一致，节点因数据差异而无法执行行更改语句——将执行紧急关闭，并且是将节点带回集群的唯一方法是通过完整的 SST。

3.5 集群访问模式

在实际应用中，Galera集群常与haproxy配合，haproxy作为单一入口，将SQL流量分配到后端Galera，注意此处是TCP级别的，而不是SQL语句级别。如果需要SQL语句级别的，可以参考看看MaxScale，相比haproxy方案，各有应用。

实际应用的结构，haproxy作为Galera Cluster的前端，2台haproxy用keepalived避免单点故障。后端的Galera集群是3个节点，为了避免Galera写入冲突，在haproxy配置中，实际上只允许一个节点接受写入，另一个节点带有backup参数，只有当前允许写入的节点坏掉，才会自动写入另一个节点。为了充分利用另一个节点，同时做读写分离，在haproxy上监听两个端口，例如：3307用于写入，3308用于读取。

参考资料

Percona Clustercheck https://github.com/olafz/percona-clustercheck

MySQL的Galera Cluster配置说明 http://blog.sina.com.cn/s/blog_704836f40101lixp.html

galera集群启动异常问题汇总 https://www.cnblogs.com/jinyuanliu/p/10929324.html

MySQL Galera Cluster grastate.dat文件详解 https://blog.csdn.net/zhongbeida_xue/article/details/110000874

vlambda博客
学习文章列表

Galera for MySQL集群安装手册终极版

1.Galera Cluster for MySQL 安装官方指引

2.集群安装详细步骤

2.1 在/etc/yum.repos.d/ 的目录下新增gelare.repo文件

2.2 一键安装

2.3 MySQL初始化

2.4 网络配置&同步工具安装

2.5 节点配置

2.6 启动集群

2.7 集群状态检查

3.集群运维指南

3.1 Galera状态文件

3.2 MySQL错误日志

3.3 集群重启

3.3.1 识别最高级别的节点

3.3.2 “安全引导”保护

3.3.3 Gcache恢复

3.3.4 识别崩溃节点

3.4 故障恢复

3.4.1 节点1正常停止

3.4.2 两个节点正常停止

3.4.3 所有三个节点都正常停止

3.4.4 一个节点从集群中消失

3.4.5 两个节点从集群中消失

3.4.6 所有节点在没有正确关闭程序的情况下关闭

3.4.7 由于脑裂，集群失去了主要状态

3.5 集群访问模式

参考资料

标签:

推荐阅读

相关文章

vlambda博客 学习文章列表

Galera for MySQL集群安装手册终极版

1.Galera Cluster for MySQL 安装官方指引

2.集群安装详细步骤

2.1 在/etc/yum.repos.d/ 的目录下新增gelare.repo文件

2.2 一键安装

2.3 MySQL初始化

2.4 网络配置&同步工具安装

2.5 节点配置

2.6 启动集群

2.7 集群状态检查

3.集群运维指南

3.1 Galera状态文件

3.2 MySQL错误日志

3.3 集群重启

3.3.1 识别最高级别的节点

3.3.2 “安全引导”保护

3.3.3 Gcache恢复

3.3.4 识别崩溃节点

3.4 故障恢复

3.4.1 节点1正常停止

3.4.2 两个节点正常停止

3.4.3 所有三个节点都正常停止

3.4.4 一个节点从集群中消失

3.4.5 两个节点从集群中消失

3.4.6 所有节点在没有正确关闭程序的情况下关闭

3.4.7 由于脑裂，集群失去了主要状态

3.5 集群访问模式

参考资料

标签:

推荐阅读

相关文章

vlambda博客
学习文章列表