1. 集群搭建步骤
Galera Cluster分支概述 : MySQL Galera Cluster , MariaDB Galera Cluster ,XtraDB Galera Cluster。三个版本的安装方式基本一致。
MGC 会使用大概 4 个端口号
3306: 数据库对外服务的端口号4444: 请求SST。SST: 指数据镜象传输端口, 使用方法xtrabackup,rsync,mysqldump4567: 组成员之间进行沟通的一个端口号4568: 传输IST用的。相对于SST来说的一个增量。
1.1 mariadb 安装流程
这里安装的mariadb版本为10.5.27
使用
yum命令安装mairadb以及对应的galera的相关软件包[root@node01 ~]#yum install -y mariadb mariadb-server mariadb-server-galera galera按照如下方式配置
node01节点配置文件, 这里主要配置如下信息即可。[root@node01 ~]# cat /etc/my.cnf.d/mariadb-server.cnf [mysqld] server-id=25 datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/log/mariadb/mariadb.log pid-file=/run/mariadb/mariadb.pid #使用galera一定要是ROW格式而不能是SQL格式, 不然会影响性能和一致性 binlog_format=ROW # # * Galera-related settings # [galera] # Mandatory settings wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so #集群名称, 同一个集群必须保持一直 wsrep_cluster_name=test-cluster # 当前节点IP和其他节点IP列表(以逗号分隔) wsrep_cluster_address=gcomm://192,168.71.25,192.168.71.26,192.168.71.27 # 当前节点名称 wsrep_node_name=node01 # 当前节点地址 wsrep_node_address=192.168.71.25 #同步时使用的用户名和密码 wsrep_sst_auth=syncuser:123456 #同步方法, 同步方法共有三种: mariabackup , rsync,xtrabackup wsrep_sst_method=rsync 其他两个节点的配置文件如下
#node02 [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/log/mariadb/mariadb.log pid-file=/run/mariadb/mariadb.pid server-id=26 binlog_format=ROW # # * Galera-related settings # [galera] # Mandatory settings wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so #集群名称, 同一个集群必须保持一直 wsrep_cluster_name=test-cluster # 当前节点IP和其他节点IP列表(以逗号分隔) wsrep_cluster_address=gcomm://192.168.71.25,192.168.71.26,192.168.71.27 # 当前节点名称 wsrep_node_name=node02 # 当前节点地址 wsrep_node_address=192.168.71.26 #同步时使用的用户名和密码 wsrep_sst_auth=syncuser:123456 #同步方法, 同步方法共有三种: mariabackup , rsync,xtrabackup wsrep_sst_method=rsync #node03 [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/log/mariadb/mariadb.log pid-file=/run/mariadb/mariadb.pid server-id=27 binlog_format=ROW # # * Galera-related settings # [galera] wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so wsrep_cluster_address=gcomm://192.168.71.25,192.168.71.26,192.168.71.27 wsrep_node_name=node03 wsrep_node_address=192.168.71.27 wsrep_sst_auth=syncuser:123456 wsrep_sst_method=rsync 在节点1中使用
galera_new_cluster脚本, 启动mariadb。这个脚本是第一次启动过程中运行的。这里说明三种安装方式的服务启动方式如下:galera:mysqld_bootstrap --wsrep-new-clustermariadb:mysqld --wsrep-new-clusterPercona XtraDB Cluster:systemctl start mysql@bootstrap.service
[root@node01 ~]# galera_new_cluster #运行之后可以直接看到mariadb服务已经启动。从启动的服务脚本里面可以看到。这个脚本实际上运行的命令为/usr/libexec/mariadbd --basedir=/usr --wsrep-new-cluster启动的服务 [root@node01 ~]# systemctl status mariadb ● mariadb.service - MariaDB 10.5 database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; preset: disabled) Active: active (running) since Tue 2025-05-27 00:49:41 CST; 1min 7s ago Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Process: 28721 ExecStartPre=/usr/libexec/mariadb-check-socket (code=exited, status=0/SUCCESS) Process: 28743 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir mariadb.service (code=exited, status=0/SUCCESS) Process: 28846 ExecStartPost=/usr/libexec/mariadb-check-upgrade (code=exited, status=0/SUCCESS) Main PID: 28827 (mariadbd) Status: "Taking your SQL requests now..." Tasks: 13 (limit: 23152) Memory: 94.7M CPU: 585ms CGroup: /system.slice/mariadb.service └─28827 /usr/libexec/mariadbd --basedir=/usr --wsrep-new-cluster May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: The second is mysql@localhost, it has no password either, but May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: you need to be the system 'mysql' user to connect. May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: After connecting you can set the password, if you would need to be May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: able to connect as any of these users with a password and without sudo May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: See the MariaDB Knowledgebase at https://mariadb.com/kb May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: Please report any problems at https://mariadb.org/jira May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: The latest information about MariaDB is available at https://mariadb.org/. May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: Consider joining MariaDB's strong and vibrant community: May 27 00:49:40 node01 mariadb-prepare-db-dir[28782]: https://mariadb.org/get-involved/ May 27 00:49:41 node01 systemd[1]: Started MariaDB 10.5 database server. 创建同步用户, 这里rsync的用户配置之后, 发现其实不用创建
[root@node01 ~]# mysql -uroot Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 7 Server version: 10.5.27-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> create user 'syncuser'@'localhost' identified by '123456'; Query OK, 0 rows affected (0.018 sec) MariaDB [(none)]> grant reload,process,lock tables,replication client on *.* to 'syncuser'@'localhost'; Query OK, 0 rows affected (0.017 sec) MariaDB [(none)]> flush privileges; Query OK, 0 rows affected (0.021 sec) 其余两个节点使用
systemctl start mariadb启动服务使用以下命令检查
mariadb集群状态[root@node01 ~]# mysql -uroot Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 7 Server version: 10.5.27-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.002 sec) MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment'; +---------------------------+--------+ | Variable_name | Value | +---------------------------+--------+ | wsrep_local_state_comment | Synced | +---------------------------+--------+ 1 row in set (0.001 sec)
1.2 galera 安装流程
这一步使用mysql安装galera ,这里的galera是直接在官网下载的。
galera官网地址: Downloads | Galera Cluster for MySQL
配置
yum源[galera] name = Galera baseurl = https://releases.galeracluster.com/galera-4/redhat/9/x86_64/ gpgcheck = 0 enable=1 [mysql-wsrep] name = MySQL-wsrep baseurl = https://releases.galeracluster.com/mysql-wsrep-8.4/redhat/9/x86_64/ gpgcheck = 0 enable=1安装软件包, 需要注意, 这里
mysql-wsrep-server的rpm包已经包含了mysqld服务本身, 不需要额外安装mysql服务[root@node01 ~]# yum install galera-4 mysql-wsrep-8.4 [root@node01 ~]# rpm -qa | grep -E 'galera|wsrep' mysql-wsrep-common-8.4.4-26.22.el9.x86_64 mysql-wsrep-client-plugins-8.4.4-26.22.el9.x86_64 mysql-wsrep-libs-8.4.4-26.22.el9.x86_64 mysql-wsrep-client-8.4.4-26.22.el9.x86_64 mysql-wsrep-icu-data-files-8.4.4-26.22.el9.x86_64 mysql-wsrep-server-8.4.4-26.22.el9.x86_64 mysql-wsrep-8.4-8.4.4-26.22.el9.x86_64 galera-4-26.4.22-1.el9.x86_64 这里安装的
mysql-wsrep-8.4版本, 下载xtrabackup-8.4.0版本安装。 下载链接为: Software Downloads - Percona[root@node01 ~]# wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.4/Percona-XtraBackup-8.4.0-1/binary/redhat/9/x86_64/percona-xtrabackup-84-8.4.0-1.1.el9.x86_64.rpm [root@node01 ~]# yum localinstall percona-xtrabackup-84-8.4.0-1.1.el9.x86_64.rpm至此软件包安装已完成。启动集群只要很少几项必须配置。
修改
node01配置文件, 这里修改配置文件的参数内容与mariadb安装过程中一样[root@node01 ~]# cat /etc/my.cnf server-id=30 binlog_format=ROW wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_address=gcomm://192.168.71.30,192.168.71.33,192.168.71.34 wsrep_node_name=node01 wsrep_node_address=192.168.71.30 wsrep_sst_auth=syncuser:Password01! wsrep_sst_method=xtrabackup这里在
node01节点中初始化集群:/usr/bin/mysqld_bootstrap。该命令会启动本机的mysqld服务,MySQL缺省安装目录为/var/lib/mysql。注意,/usr/bin/mysqld_bootstrap命令只在集群第一个节点启动时使用, 因为该脚本中带有一个参数:--wsrep-new-cluster, 代表新建集群。[root@node01 ~]# /usr/bin/mysqld_bootstrap [root@node01 ~]# systemctl status mysqld ● mysqld.service - MySQL Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; preset: disabled) Active: active (running) since Wed 2025-05-28 01:41:03 CST; 8s ago Docs: man:mysqld(8) http://dev.mysql.com/doc/refman/en/using-systemd.html Process: 28978 ExecStartPre=/usr/bin/mysqld_pre_systemd --pre (code=exited, status=0/SUCCESS) Process: 29143 ExecStartPost=/usr/bin/mysqld_pre_systemd --post (code=exited, status=0/SUCCESS) Main PID: 29095 (mysqld) Status: "Server is operational" Tasks: 41 (limit: 23152) Memory: 482.1M CPU: 7.553s CGroup: /system.slice/mysqld.service └─29095 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1/0/0/00000000-0000-00> May 28 01:40:32 node01 systemd[1]: Starting MySQL Server... May 28 01:41:00 node01 mysql[29093]: WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1/0/0/00000000-0000-0000-0000-0000000000> May 28 01:41:03 node01 systemd[1]: Started MySQL Server.进入
mysql中,创建同步时需要的用户并修改root用户密码[root@node01 ~]# grep -i 'temporary password' /var/log/mysqld.log 2025-05-27T17:40:49.366967Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: %.BX!rYkO9>_ [root@node01 ~]# mysql -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 13 Server version: 8.4.4 Copyright (c) 2000, 2025, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> ALTER USER root@localhost identified by 'Password01!'; Query OK, 0 rows affected (0.04 sec) mysql> select user,host from mysql.user; +------------------+-----------+ | user | host | +------------------+-----------+ | mysql.infoschema | localhost | | mysql.session | localhost | | mysql.sys | localhost | | root | localhost | +------------------+-----------+ 4 rows in set (0.00 sec) mysql> update mysql.user set host='%' where user = 'root'; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select user,host from mysql.user; +------------------+-----------+ | user | host | +------------------+-----------+ | root | % | | mysql.infoschema | localhost | | mysql.session | localhost | | mysql.sys | localhost | +------------------+-----------+ 4 rows in set (0.01 sec) mysql> flush privileges; Query OK, 0 rows affected (0.02 sec) mysql> create user 'syncuser'@'%' identified by 'Password01!'; Query OK, 0 rows affected (0.48 sec) mysql> grant reload,process,lock tables,replication client on *.* to 'syncuser'@'%'; Query OK, 0 rows affected (0.42 sec) mysql> flush privileges; Query OK, 0 rows affected (0.02 sec)修改
node02,node03两个节点的配置文件[root@node02 ~]# cat /etc/my.cnf server-id=33 binlog_format=ROW wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_address=gcomm://192.168.71.30,192.168.71.33,192.168.71.34 wsrep_node_name=node02 wsrep_node_address=192.168.71.33 wsrep_sst_auth=syncuser:Password01! wsrep_sst_method=xtrabackup [root@node03 ~]# cat /etc/my.cnf server-id=34 binlog_format=ROW wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_address=gcomm://192.168.71.30,192.168.71.33,192.168.71.34 wsrep_node_name=node03 wsrep_node_address=192.168.71.34 wsrep_sst_auth=syncuser:Password01! wsrep_sst_method=xtrabackup其余两个节点使用命令
systemctl start mysqld启动服务。整体的流程和mariadb的galera集群配置方式一样。
1.3 XtraDB Galera Cluster
因为percona官方提供的版本比较低 , 这里直接使用网上的一个文章。之后可以作为参考
准备
yum源[percona] name=percona_repo baseurl = https://mirrors.tuna.tsinghua.edu.cn/percona/release/$releasever/RPMS/$basearch enabled = 1 gpgcheck = 0使用以下命令安装
yum -y install Percona-XtraDB-Cluster-57注意 , 装了
Percona-XtraDB-Cluster就自带好了Percona-mysql, 不要再装MySQL, 不要再装MySQL, 不要再装MySQL。不止一个人因为这个问题 ,PXC死活启动不了。典型错误提示 :unknown variable 'wsrep_provider=/usr/lib64/libgalera_smm.so'配置文件
第一个节点配置文件
/etc/my.cnf[mysqld] server-id=100 # 各节点不同 datadir=/data socket=/data/mysql.sock log-error=/data/error.log pid-file=/data/mysqld.pid log-bin=/data/master-bin log_slave_updates wsrep_provider=/usr/lib64/galera3/libgalera_smm.so wsrep_cluster_name=pxc-cluster wsrep_cluster_address=gcomm://192.168.70.61,192.168.70.62,192.168.70.63 wsrep_node_name=pxc1 # 各节点不同 wsrep_node_address=192.168.70.61 # 各节点不同 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2第二个节点配置文件
[mysqld] server-id=110 # 各节点不同 datadir=/data socket=/data/mysql.sock log-error=/data/error.log pid-file=/data/mysqld.pid log-bin=/data/master-bin log_slave_updates wsrep_provider=/usr/lib64/galera3/libgalera_smm.so wsrep_cluster_name=pxc-cluster wsrep_cluster_address=gcomm://192.168.70.61,192.168.70.62,192.168.70.63 wsrep_node_name=pxc2 # 各节点不同 wsrep_node_address=192.168.70.62 # 各节点不同 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2第三个节点配置文件
[mysqld] server-id=120 # 各节点不同 datadir=/data socket=/data/mysql.sock log-error=/data/error.log pid-file=/data/mysqld.pid log-bin=/data/master-bin log_slave_updates wsrep_provider=/usr/lib64/galera3/libgalera_smm.so wsrep_cluster_name=pxc-cluster wsrep_cluster_address=gcomm://192.168.70.61,192.168.70.62,192.168.70.63 wsrep_node_name=pxc3 # 各节点不同 wsrep_node_address=192.168.70.63 # 各节点不同 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2配置文件各项配置意义:
wsrep_provider: 指定Galera库的路径wsrep_cluster_name:Galera集群的名称wsrep_cluster_address:Galera集群中各节点地址。地址使用组通信协议gcomm://(group communication)wsrep_node_name: 本节点在Galera集群中的名称wsrep_node_address: 本节点在Galera集群中的通信地址wsrep_sst_method:state_snapshot_transfer(SST)使用的传输方法 , 可用方法有mysqldump、rsync和xtrabackup, 前两者在传输时都需要对Donor加全局只读锁(FLUSH TABLES WITH READ LOCK) ,xtrabackup则不需要(它使用percona自己提供的backup lock)。强烈建议采用xtrabackupwsrep_sst_auth: 在SST传输时需要用到的认证凭据 , 格式为 : "用户 : 密码"pxc_strict_mode: 是否限制PXC启用正在试用阶段的功能 ,ENFORCING是默认值 , 表示不启用binlog_format: 二进制日志的格式。Galera只支持row格式的二进制日志default_storage_engine: 指定默认存储引擎。Galera的复制功能只支持InnoDBinnodb_autoinc_lock_mode: 只能设置为2, 设置为0或1时会无法正确处理死锁问题
引导
galera中的第一个节点引导启动
galera集群/etc/init.d/mysql bootstrap-pxc # 或 systemctl start mysql@bootstrap.service引导后, 查看状态:
mysql@pxc1> show status like 'wsrep%'; +----------------------------+--------------------------------------+ | Variable_name | Value | +----------------------------+--------------------------------------+ | wsrep_local_state_uuid | c2883338-834d-11e2-0800-03c9c68e41ec | | ... | ... | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | ... | ... | | wsrep_cluster_size | 1 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | ... | ... | | wsrep_ready | ON | +----------------------------+--------------------------------------+上述状态表示 , 该
Galera集群中只有一个节点 , 状态为Synced(4) , 表示数据已同步完成(因为是第一个引导节点 , 无数据需要同步)。角色为Primary, 且已经完全连接并准备好 ,connected和ready状态决定了该节点是否是Galera中的正式成员 , 正式成员才能向外提供MySQL服务。正确引导了第一个节点后 , 需要在第一个节点(
Galera的初始化引导节点)上创建SST的认证用户 , 注意这个用户名和密码需要和配置文件中的对应。create user 'sstuser'@localhost identified by 'passw0rd'; grant reload,lock tables,process,replication client on *.* to 'sstuser'@localhost; flush privileges;向
galera中加入第二、第三个节点加入节点非常简单 , 只需正常启动
MySQL服务即可 , 在启动时会读取配置文件 , 并根据配置自动加入到对应的Galera集群中。#### 在第二个节点上执行 /etc/init.d/mysql start #### 在第三个节点上执行 /etc/init.d/mysql start查看各个节点状态
mysql@pxc3> show status like 'wsrep%'; +----------------------------+--------------------------------------+ | Variable_name | Value | +----------------------------+--------------------------------------+ | wsrep_local_state_uuid | c2883338-834d-11e2-0800-03c9c68e41ec | | ... | ... | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | ... | ... | | wsrep_cluster_size | 3 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | ... | ... | | wsrep_ready | ON | +----------------------------+--------------------------------------+可见这两个节点已经完成了数据同步 , 且已经是
Galera集群中的正式成员 , 可以向外提供MySQL服务。
2. 选项说明
wsrep_auto_increment_control: 如果设置为1(默认值) , 将根据集群的大小以及集群大小的变化自动调整auto_increment_increment和auto_increment_offset变量。 这样可以避免由于auto_increment而引起的复制冲突。 在主从环境中 , 可以设置为OFF。wsrep_causal_reads: 如果设置为ON(默认为OFF) , 则在整个集群中强制执行读取提交的特征。 如果主设备比从设备更快地应用事件 , 则两者可能会短暂地不同步。 在将此变量设置为ON的情况下 , 从站将等待事件应用 , 然后再处理其他查询。 设置为ON也将导致更大的读取延迟。wsrep_certification_rules: 说明 : 要在集群中使用的认证规则。可能的值为 :
strict: 可能会导致更多认证失败的更严格的规则。 例如 , 对于外键 , 如果不同的节点大约在同一时间收到指向父表中同一行的无冲突插入 , 则可能导致认证失败optimized: 宽松的规则 , 允许更多的并发性 , 并减少更少的认证失败。wsrep_certify_nonPK: 设置为“开” ( 默认值 ) 时 , 将自动为没有一个表的表生成主键。 这对于并行应用是必需的 , 强烈建议对所有表使用。wsrep_cluster_address: 说明 , 启动时要连接的群集节点的地址 , 例如gcomm://192.168.0.1:1234?gmcast.listen_addr = 0.0.0.0:2345。 优良作法是以gcomm://<node1或ip:port>,<node2或ip2:port>,<node3或ip3:port>的形式指定所有可能的群集节点。 指定一个空ip(gcomm://)将导致该节点启动新群集(不应在my.cnf文件中完成此操作 , 因为每次重新启动后 , 服务器将不会重新加入当前群集 ) 。 在某些配置中 , 可以在运行时更改该变量 , 这将导致节点关闭与任何当前群集的连接 , 并连接至新地址。 如果指定端口 , 请注意这是Galera端口 , 而不是MariaDB端口。wsrep_cluster_name: 描述 ,集群的名称。 节点无法连接到名称不同的集群 , 因此在同一集群中的所有节点上都必须相同。wsrep_convert_LOCK_to_trx: 说明 ,将LOCK/UNLOCK TABLES语句转换为BEGIN和COMMIT。 主要用于使较旧的应用程序与多主机设置一起使用 , 请谨慎使用 , 因为这可能会导致极大的写入集。wsrep_data_home_dir: 说明 ,wsrep提供程序将在其中存储其内部文件的目录。wsrep_dbug_option: 说明 ,用于将DBUG选项传递给wsrep提供程序。wsrep_debug: 说明 , 当设置为ON( 默认为OFF) 时 , 调试消息也将记录到错误日志中。wsrep_desync: 描述 , 当节点接收到的写集超出其可应用的数量时 , 事务将放入接收的队列中。 如果节点的接收队列等待应用的写入集过多 ( 如gcs.fc_limit WSREP提供程序选项所定义 ) , 则该节点通常将使用Flow Control。 但是 , 当此选项设置为ON时 , 将为取消同步的节点禁用Flow Control。 取消同步的节点将一直处理接收到的队列 , 直到达到可管理的大小为止。 已取消同步的节点继续从群集中的其他节点接收写集。 群集中的其他节点不等待不同步的节点赶上 , 因此 , 不同步的节点可能甚至落在群集中的其他节点之后。 您可以通过检查wsrep_local_state_comment状态变量是否等于Donor/Desynced来检查节点是否被取消同步。wsrep_dirty_reads: 说明 , 默认情况下 , 当不与组同步时 (wsrep_ready = OFF) , 节点将拒绝除SET和SHOW之外的所有查询。 如果wsrep_dirty_reads设置为1, 则该节点将接受不更改数据的查询 , 例如SELECT查询 ( 脏读 ) , 创建prepare语句等。wsrep_drupal_282555_workaround: 说明 , 如果设置为ON, 则启用Drupal/MySQL/InnoDB错误＃282555的解决方法。 这是一个错误 , 在某些情况下 , 将DEFAULT值插入到AUTO_INCREMENT列中时 , 可能会返回重复的键错误。wsrep_forced_binlog_format: 说明 , 一种二进制日志格式 , 它将覆盖所有会话二进制日志格式设置。wsrep_gtid_domain_id: 说明 , 此系统变量定义用于wsrep GTID模式的GTID域ID。 当wsrep_gtid_mode设置为ON时 , 所有Galera Cluster写集都将使用wsrep_gtid_domain_id代替gtid_domain_id。 当wsrep_gtid_mode设置为OFF时 , 将忽略wsrep_gtid_domain_id, 以实现向后兼容。 为了使此模式生成一致的GTID, 还需要满足一些其他要求。wsrep_gtid_mode: 说明 ,Wsrep GTID模式尝试使所有群集节点上的Galera Cluster写入集的GTID保持一致。 在SST期间 ,GTID状态最初会复制到联接节点。 如果您打算将Galera Cluster与MariaDB复制一起使用 , 则wsrep GTID模式可能会有所帮助。 当wsrep_gtid_mode设置为ON时 , 所有Galera Cluster写集都将使用wsrep_gtid_domain_id代替gtid_domain_id。 当wsrep_gtid_mode设置为OFF时 , 将忽略wsrep_gtid_domain_id, 以实现向后兼容。 为了使此模式生成一致的GTID, 还需要满足一些其他要求。wsrep_gtid_seq_no: 说明 , 内部服务器使用情况 , 手动设置WSREP GTID seqno。wsrep_ignore_apply_errors: 说明 , 如果设置 , 将忽略复制错误。wsrep_load_data_splitting: 说明 , 如果设置为ON(MariaDB 10.4.2和更低版本的默认设置 ) , 则LOAD DATA INFILE通过引入事务拆分来支持大数据文件。 该设置已在Galera 4中弃用 , 并且从MariaDB 10.4.3默认为OFF。wsrep_log_conflicts: 说明 , 如果设置为ON( 默认为OFF) , 则会记录群集中发生冲突的MDL以及InnoDB锁的详细信息。wsrep_max_ws_rows: 说明 , 每个写入集允许的最大行数。 在MariaDB Galera 10.0.27和MariaDB 10.1.17之前 , 此变量在内部被忽略 , 并且对节点没有影响。 从MariaDB Galera 10.0.27和MariaDB 10.1.17起 , 已添加了对此变量的支持 , 并且为了向后兼容 , 默认值已更改为0, 这实际上允许写集为任意大小。wsrep_max_ws_size: 说明 , 每个写入集允许的最大大小 ( 以字节为单位 ) 。 超出此限制的Writeset将被拒绝。 请注意 ,MariaDB 10.1.17和MariaDB Galera 10.0.27以及之前的版本允许将最大值设置为2GB以上 , 这被Galera拒绝。wsrep_mysql_replication_bundle: 说明 , 确定分组在一起的复制事件的数量。 实验实现旨在在单个从站面临大量提交时间延迟时帮助解决瓶颈问题。 如果设置为0 ( 默认值 ) , 则没有分组。wsrep_node_address: 说明 , 指定节点的网络地址 , 格式为ip address[:port]。 从MariaDB 10.1.8开始 , 支持IPv6。 节点的默认行为是拉取系统上第一个网络接口的地址和默认的Galera端口。 这种自动猜测可能不可靠 , 尤其是在以下情况下 : 云部署 容器部署 具有多个网络接口的服务器。 运行多个节点的服务器。 网络地址转换 (NAT) 。 节点在多个区域中的群集。wsrep_node_incoming_address:说明 , 这是节点用来侦听客户端连接的地址。 如果未指定地址或将其设置为AUTO( 默认 ) , 则mysqld使用--bind-address或--wsrep-node-address, 或尝试以相同顺序从可用网络接口列表中获取一个地址。wsrep_node_name: 描述 , 此节点的名称。 此名称可以在wsrep_sst_donor中用作首选供体。 请注意 , 群集中的多个节点可以具有相同的名称。wsrep_notify_cmd: 说明 , 每次节点状态或集群成员资格更改时要执行的命令。 可用于发出警报 , 配置负载均衡器等。 有关更多详细信息 , 请参见编码通知脚本页面。wsrep_on: 说明 , 是否启用wsrep复制。 如果全局值设置为OFF(MariaDB 10.1以来的默认值 ) , 则无法加载提供程序并加入集群中的节点。 如果仅将会话值设置为OFF, 则该特定会话的操作不会在群集中复制 , 但其他会话和应用程序线程将照常继续。 变量的会话值不会影响节点的成员身份 , 因此 , 无论其值如何 , 节点都会不断从群集中的其他节点接收更新。 在MariaDB 10.1之前 , 即使该变量默认情况下为ON, 其值也会根据是否已指定强制配置以打开Galera复制而自动调整。 从MariaDB 10.1开始 , 默认情况下将其设置为OFF, 并且必须启用它才能启用Galera复制。wsrep_OSU_method: 说明 , 在线模式升级方法。 默认值为TOI, 指定不带可选参数的设置将设置为RSU。TOI: 总订单隔离。 在每个群集节点中 , 对于其他事务 , 将以相同的顺序处理DDL, 从而确保数据的一致性。 但是 , 数据库的受影响部分将为整个群集锁定。RSU: 滚动架构升级。DDL处理仅在节点上本地完成 , 用户需要在每个节点上手动执行更改。 在进行处理以避免阻塞其他节点的同时 , 该节点与群集的其余部分不同步。 模式更改必须以与基于ROW的复制相同的方式向后兼容 , 以避免在单个节点上完成DDL处理并重新开始复制时中断复制。wsrep_patch_version: 说明 ,Wsrep修补程序版本 , 例如wsrep_25.10。wsrep_provider: 描述 ,wsrep库的位置 , 通常在Debian和Ubuntu上为/usr/lib/libgalera_smm.so, 在Red Hat/CentOS上通常为/usr/lib64/libgalera_smm.so。wsrep_provider_options: 说明 , 用分号 (;) 分隔的wsrep选项列表。wsrep_recover: 说明 , 如果在服务器启动时将其设置为ON, 则服务器将恢复Galera应用的最新写入集的序列号 , 并将其输出到stderr, 通常将其重定向到错误日志。 此时 , 服务器将退出。 可以将此序列号提供给wsrep_start_position系统变量。wsrep_reject_queries: 说明 , 设置为拒绝来自客户端连接的查询的变量 , 对维护很有用。 该节点继续应用写集 , 但是客户端查询生成错误1047: 未知命令错误。NONE: 未设置。 查询将照常处理。ALL: 来自客户端连接的所有查询将被拒绝 , 但现有的客户端连接将保留。ALL_KILL: 来自客户端连接的所有查询将被拒绝 , 现有的客户端连接 ( 包括当前的客户端连接 ) 将被立即终止。wsrep_replicate_myisam: 说明 , 是否将复制MyISAM表的DML更新。 此功能仍处于试验阶段 , 不应在生产系统中使用。wsrep_restart_slave: 说明 , 如果设置为ON, 则当节点重新加入群集时 , 复制从属会自动重新启动。wsrep_retry_autocommit: 说明 , 在将错误返回给客户端之前 , 由于群集范围内的冲突而导致重试自动提交的查询的次数。 如果设置为0 , 将不尝试重试 , 而值1 ( 默认值 ) 或更大将指定尝试的重试次数。 有助于使用自动提交来避免死锁的应用程序。wsrep_slave_FK_checks: 说明 , 如果设置为ON( 默认值 ) , 则应用程序从属线程执行外键约束检查。wsrep_slave_threads: 说明 , 用于并行应用Galera写集的从属线程数。Galera从属线程能够确定可以安全并行应用哪些写集。 但是 , 如果您的群集节点似乎经常出现一致性问题 , 那么将该值设置为1可能会解决此问题。 有关更多信息 , 请参见关于Galera复制 :Galera从属线程。wsrep_slave_UK_checks: 说明 , 如果设置为ON, 则应用程序从属线程执行辅助索引唯一性检查。wsrep_sr_store: 说明 , 用于流式复制片段的存储。wsrep_sst_auth: 描述 , 用于复制的用户名和密码。 如果wsrep_sst_method设置为rsync, 则未使用 , 而对于其他方法 , 它的格式应为:。 内容在日志中以及使用SHOW VARIABLES查询值时被屏蔽。wsrep_sst_donor: 说明 , 以逗号分隔的列表 ( 从5.5.33起 ) 或作为捐赠者的服务器名称 ( 按照wsrep_node_name) 或状态转移的源 ( 按优先顺序排列 ) 。通常 , 施主选择算法更喜欢一个施主 , 该施主只能将丢失的事务 (IST) 转移到合并节点 , 而不是完整状态 (SST) 。因此 , 它首先在给定的施主列表中寻找一个具有IST功能的节点 , 然后是集群中的其余节点。如果在指定的施主列表之外找到多个候选节点 , 则首选与连接器位于同一段 (gmcast.segment) 中的节点。如果集群中的现有节点都无法通过IST服务丢失的事务 , 则该算法会继续寻找合适的节点以传输整个状态 (SST) 。首先查看供体列表中指定的节点 ( 不考虑其段 ) 。如果仍然找不到合适的施主 , 则仅在施主列表具有“终止逗号”的情况下 , 检查其余施主节点的适用性。请注意 , 无状态节点 (Galera仲裁器 ) 永远不能成为施主。wsrep_sst_donor_rejects_queries: 说明 , 如果设置为ON( 默认为OFF) , 施主节点将拒绝传入的查询 , 并返回UNKNOWN COMMAND错误代码。 可以用于通知负载均衡器节点不可用。wsrep_sst_method: 说明 , 用于进行状态快照传输 (SST) 的方法wsrep_sst_receive_address: 说明 , 这是群集中其他节点 ( 供体 ) 连接以发送状态转移更新的地址。 如果未指定地址或将其设置为AUTO( 默认 ) , 则mysqld使用--wsrep_node_address的值作为接收地址。 但是 , 如果未设置--wsrep_node_address, 它将使用--bind-address中的地址 , 或尝试以相同顺序从可用网络接口列表中获取一个地址。 注意 : 将其设置为localhost将使在其他主机上运行的节点无法到达该节点。wsrep_start_position:说明 , 节点应使用的起始位置 , 格式为 :UUID:seq_no。 可以使用wsrep_recover恢复用于该位置的正确值。wsrep_strict_ddl:说明 , 如果设置 , 则拒绝不支持Galera复制的受影响表上的DDL。wsrep_sync_wait: 说明 , 设置此变量可确保在执行由值指定的类型的操作之前进行因果关系检查 , 以确保在完全同步的节点上执行该语句。进行检查时 , 将在节点上阻止新查询 , 以使服务器能够赶上群集中进行的所有更新 , 直到检查开始为止。到达后 , 将在节点上执行原始查询。这会导致更高的延迟。请注意 , 当wsrep_dirty_reads设置为ON时 ,wsrep_sync_wait的值将变得无关紧要。样本用法 ( 对于必须具有最新数据的关键读取 )SET SESSION wsrep_sync_wait = 1;选择 ...; SET SESSION wsrep_sync_wait = 0;0: 禁用 (默认)1: 读取 ( 选择和开始/开始事务 ) 。直到MariaDB 10.2.8,MariaDB 10.1.26,MariaDB Galera 10.0.31和MariaDB Galera 5.5.56( 也显示 ) 。这与wsrep_causal_reads = 1相同。2: 更新和删除；3: 读取 , 更新和删除；4: 插入和更换；5: 读取 , 插入和替换；6: 更新 , 删除 , 插入和替换；7: 读取 , 更新 , 删除 , 插入和替换；8: 显示 ( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)9: 读取和显示 ( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)10: 更新 , 删除和显示 ( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)11: 读取 , 更新 , 删除和显示 ( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)12: 插入 , 替换和显示 ( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)13: 读取 , 插入 , 替换和显示( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)14: 更新 , 删除 , 插入 , 替换和显示( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)15: 读取 , 更新 , 删除 , 插入 , 替换和显示( 来自MariaDB 10.2.9,MariaDB 10.1.27,MariaDB Galera 10.0.32,MariaDB Galera 5.5.57)wsrep_trx_fragment_size: 描述 , 用于流复制的事务片段的大小 ( 以wsrep_trx_fragment_unit指定的单位度量 )wsrep_trx_fragment_unit: 说明 , 流复制事务片段大小的单位 : 字节 : 交易的Binlog事件缓冲区大小 ( 以字节为单位 ) 行 : 受事务影响的行数 语句 : 在多语句事务中执行的SQL语句数
3. 故障说明
3.1 数据库重启
如果数据库全部关机, 再次启动会遇到以下报错
[root@MariaDB-Node1 ~]# cd /data/logs/mysql/
[root@MariaDB-Node1 /data/logs/mysql]# tail -100f mysql_error.log
2021-01-09 13:49:33 0 [Note] WSREP: Read nil XID from storage engines, skipping position init
2021-01-09 13:49:33 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/mysql/lib/galera/libgalera_smm.so'
2021-01-09 13:49:33 0 [Note] WSREP: wsrep_load(): Galera 25.3.31(r0ede97d) by Codership Oy <info@codership.com> loaded successfully.
2021-01-09 13:49:33 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration.
2021-01-09 13:49:33 0 [Note] WSREP: Found saved state: a4d25ee0-515c-11eb-b451-66b7a1b050e2:0, safe_to_bootstrap: 0
2021-01-09 13:49:33 0 [Note] WSREP: Passing config to GCS: base_dir = /data/mysql/data/; base_host = 192.168.40.50; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /data/mysql/data/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /data/mysql/data//galera.cache; gcache.page_size = 128M; gcache.recover = no; gcache.size = 2G; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.segment = 0; gmcast.version = 0; pc.announce_timeout =
2021-01-09 13:49:33 0 [Note] WSREP: Assign initial position for certification: 0, protocol version: -1
2021-01-09 13:49:33 0 [Note] WSREP: wsrep_sst_grab()
2021-01-09 13:49:33 0 [Note] WSREP: Start replication
2021-01-09 13:49:33 0 [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster
2021-01-09 13:49:33 0 [Note] WSREP: Setting initial position to a4d25ee0-515c-11eb-b451-66b7a1b050e2:0
2021-01-09 13:49:33 0 [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 .
2021-01-09 13:49:33 0 [ERROR] WSREP: wsrep::connect(gcomm://192.168.40.50,192.168.40.60,192.168.40.70) failed: 7
2021-01-09 13:49:33 0 [ERROR] Aborting解决办法
[root@MariaDB-Node1 /data/logs/mysql]# cd /data/mysql/data/
[root@MariaDB-Node1 /data/mysql/data]# cat grastate.dat
# GALERA saved state
version: 2.1
uuid: a4d25ee0-515c-11eb-b451-66b7a1b050e2
seqno: -1
safe_to_bootstrap: 0
[root@MariaDB-Node1 /data/mysql/data]#
把 safe_to_bootstrap: 0 修改为 1
[root@MariaDB-Node1 /data/mysql/data]# vim grastate.dat
# GALERA saved state
version: 2.1
uuid: a4d25ee0-515c-11eb-b451-66b7a1b050e2
seqno: -1
safe_to_bootstrap: 1
[root@MariaDB-Node1 /data/mysql/data]# mysqld_safe --defaults-file=/etc/my.cnf --user=mysql --wsrep-new-cluster &把 safe_to_bootstrap:0 修改为 1 , 然后再用带参数 启动就可以 , 其他节点使用正常方法启动 。这里需要先使用galera_recovery 或者使用mysqld_safe --wsrep_recover命令获取集群中每个节点的gtid值 , 并比较所有值中最大的gtid值 , 在最大值的节点使用命令galera_new_cluster 或者使用/usr/bin/mysqld_bootstrap启动第一个节点的数据库。之后剩余的节点使用systemctl start mariadb 直接启动数据库服务即可
3.2 单个节点down
mysql HA集群某个节点无故down了并且有一段时间处于down的情况通过以下方式恢复 :
若日志里面出现以下日志
[Warning] WSREP: Failed to prepare for incremental state transfer: Local state UUID (00000000-0000-0000-0000-000000000000) does not match group state UUID (eb9f50c6-bc95-11e5-a735-9f48e437dc03): 1 (Operation not permitted)解决方法 : 删除/var/lib/mysql/grastate.dat 文件 ( 若还存在无法同步的情况则删除galera.cache文件 )
3.3 同步数据过长问题
一个mysql节点若down了一段时间。重新启动的时候需要一些时间去同步数据 , 服务的启动超时时间不够 , 导致服务无法启动 , 解决方法如下:
The correct way to adjust systemd settings so they don't get overwritten is to create a directory and file as such:
/etc/systemd/system/mariadb.service.d/timeout.conf
[Service]
TimeoutStartSec=12min或者直接修改/usr/lib/systemd/system/mariadb.service
[Service]
TimeoutStartSec=12min这里的时间最少要大于90s , 默认是90s之后执行 systemctl daemon-reload再重启服务即可
3.4 创建数据库失败
日志中出现类似如下错误 :
160428 13:54:49 [ERROR] Slave SQL: Error 'Table 'manage_operations' already exists' on query. Default database: 'horizon'. Query: 'CREATE TABLE `manage_operations` (
`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
`name` varchar(50) NOT NULL,
`type` varchar(20) NOT NULL,
`operation` varchar(20) NOT NULL,
`status` varchar(20) NOT NULL,
`time` date NOT NULL,
`operator` varchar(50) NOT NULL
) default charset=utf8', Error_code: 1050
160428 13:54:49 [Warning] WSREP: RBR event 1 Query apply warning: 1, 28585
160428 13:54:49 [Warning] WSREP: Ignoring error for TO isolated action: source: 752eecd1-0ce0-11e6-83fc-3e0502d0bdd2 version: 3 local: 0 state: APPLYING flags: 65 conn_id: 24053 trx_id: -1 seqnos (l: 28668, g: 28585, s: 28584, d: 28584, ts: 80224119986850)导致进程异常关闭 , 此时可以通过执行mysqladmin flush-tables来刷新表项 , 这个问题的原因是三个节点之间的表同步存在问题 , 刷新一下表即可
3.5 Too many open files
日志出现以下错误:
160820 3:13:41 [ERROR] Error in accept: Too many open files
160820 3:19:42 [ERROR] Error in accept: Too many open files
160827 3:16:24 [ERROR] Error in accept: Too many open files
160831 17:20:52 [ERROR] Error in accept: Too many open files
160831 19:54:29 [ERROR] Error in accept: Too many open files
160831 20:21:53 [ERROR] Error in accept: Too many open files
160901 11:25:57 [ERROR] Error in accept: Too many open files解决方法
vim /usr/lib/systemd/system/mariadb.service
[Service]
LimitNOFILE=10000默认的mysql的open_file_limits是1024将该项增大 , 并且修改vim /etc/my.cnf.d/server.cnf该文件的open_files_limit值
systemctl daemon-reload
systemctl restart mysqld查看mysql的open_file_limits值是否调整成功
cat /proc/$pid/limit其中$pid为mysql进程的pid看看值是否调整成功 , 并看看日志是否还会出现上述错误
4. 添加新节点
新节点加入Galera集群
新节点加入集群时, 需要从当前集群中选择一个
Donor节点来同步数据, 也就是所谓的state_snapshot_tranfer(SST)过程。SST同步数据的方式由选项wsrep_sst_method决定, 一般选择的是xtrabackup。必须注意, 新节点加入
Galera时, 会删除新节点上所有已有数据, 再通过xtrabackup(假设使用的是该方式)从Donor处完整备份所有数据进行恢复。所以, 如果数据量很大, 新节点加入过程会很慢。而且, 在一个新节点成为Synced状态之前, 不要同时加入其它新节点, 否则很容易将集群压垮。如果是这种情况, 可以考虑使用
wsrep_sst_method=rsync来做增量同步, 既然是增量同步, 最好保证新节点上已经有一部分数据基础, 否则和全量同步没什么区别, 且这样会对Donor节点加上全局read only锁。旧节点加入
Galera集群如果旧节点加入
Galera集群, 说明这个节点在之前已经在Galera集群中呆过, 有一部分数据基础, 缺少的只是它离开集群时的数据。这时加入集群时, 会采用IST(incremental snapshot transfer)传输机制, 即使用增量传输。但注意, 这部分增量传输的数据源是
Donor上缓存在GCache文件中的, 这个文件有大小限制, 如果缺失的数据范围超过已缓存的内容, 则自动转为SST传输。如果旧节点上的数据和Donor上的数据不匹配(例如这个节点离组后人为修改了一点数据), 则自动转为SST传输。
5. 文件说明
这里galera集群创建成功之后 , 会默认在数据目录中生成两个文件: /var/lib/mysql/grastate.dat ,/var/lib/mysql/gvwstate.dat 。
5.1 grastate.dat
功能
定位最近状态的节点 : 当关闭一个节点时 , 其
seqno会写入该文件中 , 后续的seqno该节点将无法接收到。当所有节点关闭后准备重启时 , 可通过查看seqno的值来确定哪个节点是最后关闭的 ,seqno值最大的节点即为最近状态的节点。安全引导保护 : 从
Galera 3.19版本开始 , 引入了安全引导的保护机制。Galera会自动判断哪个节点是最后一个离开集群的 , 并将信息写入该文件。如果使用safe_to_bootstrap为0的节点来引导集群 , 数据库将无法启动 , 需手动编辑该文件将值设置为 1 才能引导 , 但这样可能会造成数据丢失。定位崩溃的节点 : 如果
seqno为-1则说明数据库正在运行 , 或者非正常关闭。此时可以重新启动该节点 ,Galera集群会自动恢复并同步数据
文件内容详解
version: 表示文件的版本信息 , 例如2.1。uuid: 是节点的全局唯一标识符 , 用于在集群中标识该节点。seqno : 代表该节点在集群中的事务序列号。正常关闭的节点 , 会将当前的事务序列号写入该文件；如果节点正在运行或非正常关闭 , 其值为 -1。
safe_to_bootstrap : 用于指示该节点是否可以安全地引导启动集群。当集群需要重新启动时 , 查看各个节点该参数的值 , 只有值为 1 的节点才可以用于引导启动集群
5.2 gvwstate.dat
在 Galera 集群中 , /var/lib/mysql/gvwstate.dat 文件用于保存主组件(Primary Component)状态信息 , 以下是其功能和内容的详细说明 :
功能
保存主组件状态 : 当集群形成或更改主组件时 , 节点会创建并更新此文件 , 确保节点保留最新的主组件状态。如果节点失去连接 , 它可以引用此文件来获取之前的状态信息。
辅助集群恢复 : 在集群恢复过程中 , 特别是当所有节点都宕机后重新启动时 ,
gvwstate.dat文件中的信息可用于确定哪些节点属于最后一个主组件 , 从而帮助选择合适的节点来引导集群启动。
文件内容详解
my_uuid: 提供节点的UUID, 这是节点在集群中的唯一标识符。view_id: 从三个部分构成视图的标识符 :view_type: 始终为3, 表示主视图。view_uuid: 视图的唯一标识符的一部分。view_seq: 视图的序列号 , 与view_uuid一起构成标识符的唯一值。
bootstrap: 显示节点是否已引导 , 但不影响主组件恢复过程。member: 显示此主组件中节点的UUID。
示例
my_uuid: 4a6cfe9d-f9de-11e9-9ad4-23840b115384
#vwbeg
view_id: 3 4a6cfe9d-f9de-11e9-9ad4-23840b115384 3
bootstrap: 0
member: 4a6cfe9d-f9de-11e9-9ad4-23840b115384 0
member: 78bdb344-f9de-11e9-bcfa-eb03d339c6d7 0
member: 7d14464b-f9de-11e9-83b3-5b022ee44499 0
#vwend注意事项
文件创建与删除 : 只有当节点是主组件的一部分时 , 才会创建
gvwstate.dat文件。如果节点正常关闭 , 该文件会被删除。避免手动修改 : 在正常情况下 , 应避免编辑或修改
gvwstate.dat文件 , 因为这样做可能会导致意想不到的结果
参考链接
Linux 搭建 MariaDB Galera Cluster 高可用集群-CSDN博客
超详细, 多图文使用galera cluster搭建mysql集群并介绍wsrep相关参数 - lgx211 - 博客园
MariaDB Galera Cluster集群搭建 - 背锅的Mike - 博客园