1. 目标
- 掌握MariaDB Galera集群同步方案的搭建与配置
2. 脉络
- Galera集群同步方案介绍
- MariaDB集群部署规划
- Linux系统配置
- Nginx安装，增加Stream支持
- MariaDB服务安装
- MariaDB集群配置
- 集群启动验证与负载配置验证
- 数据导出与导入集群迁移验证
3. 知行
3.1 Galera集群同步方案介绍
MariaDB 10.1版本开始， 自带Galera集群方案插件， 这里我们通过Galera来实现MariaDB的多主集群部署。
Galera 集群的复制功能基于 Galeralibrary 实现,为了让 MySQL 与 Galera library 通讯，特别针对 MySQL 开发了 wsrep API。 MariaDB 集群， 最好采用XtraDB/ InnoDB 存储引擎， 对 MyISAM支持不太完善。
主要功能：
- 实现真正的multi-master多主同步， 即所有节点可以同时读写数据库。
- 自动的节点成员控制，失效节点自动被清除。
- 新节点的加入数据会自动复制。
- 真正的并行复制，行级数据复制。
- 用户可以直接连接集群当中任意一个节点使用。
优势：
- 多主模式， 不存在Slavelag(延迟)
- 不存在丢失事务的情况
- 各节点同时具有读和写的扩展能力
- 更小的客户端延迟
- 多主节点之间数据是同步的，不同于 Master/Slave 模式， 是异步传输, 不同 slave 上的 binlog 可能是不一致。
同步机制：
Galera 集群的复制功能基于 Galeralibrary 实现, 为了让 MySQL 与 Galera library 通讯，特别针对 MySQL 开发了 wsrep API。 Galera 插件保证集群同步数据，保持数据的一致性，靠的就是可认证的复制，工作原理如下图：
当客户端发出一个 commit 的指令，在事务被提交之前，所有对数据库的更改都会被write-set收集起来,并且将 write-set 纪录的内容发送给其他节点。
write-set 将在每个节点进行认证测试，测试结果决定着节点是否应用write-set更改数据。如果认证测试失败，节点将丢弃 write-set ；如果认证测试成功，则事务提交。
3.2 MariaDB集群部署规划
部署规划：
创建三台虚拟机作为集群节点： 10.10.20.25， 10.10.20.26， 10.10.20.27。
Nginx负责各节点的负载分发处理， 可根据实际情况灵活配置不同的负载策略。
3.3 Linux系统配置
-
关闭防火墙
如果是内部局域网运作， 可以关闭防火墙
systemctl disable firewalld.service systemctl stop firewalld.service如果不想关闭防火墙， 可以设定相关权限规则， 具体参考， Galeracluster Settings
-
关闭selinux
需要关闭selinux， 否则主节点同步会出现错误： Failed to prepare for rsync SST. Unrecoverable。
vi /etc/selinux/config修改内容：
SELINUX=disabled执行一下命令， 立即生效
setenforce 0
3.4 Nginx安装
在10.10.20.25节点上， 安装Nginx服务。
-
安装依赖包
yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel -
下载Nginx源码包
wget http://nginx.org/download/nginx-1.13.7.tar.gz tar -xvf nginx-1.13.7.tar.gz -
进入安装目录， 进行编译安装
进行配置时， 注意要加上stream转发支持
./configure --prefix=/usr/local/nginx --conf-path=/usr/local/nginx/nginx.conf --with-http_ssl_module --with-http_realip_module --with-stream=dynamic执行编译安装
make && make install -
环境设置
vi /etc/profile增加内容(根据实际， 修改nginx安装目录)：
export NGINX_HOME=/usr/local/nginx export PATH=$PATH:$NGINX_HOME/sbin -
启动nginx
nginx -c /usr/local/nginx/nginx.conf重启：
nginx -s reload
3.5 MariaDB服务安装
可以先在一台节点安装好， 其他节点再通过虚拟机克隆， 这样就无需重复安装设置。
-
如果YUM安装较慢， 可以采用阿里镜像服务
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo wget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo yum clean all yum makecache -
配置YUM源
vi /etc/yum.repos.d/mariadb-10.2.repo增加以下内容：
[mariadb] name = MariaDB baseurl = https://mirrors.ustc.edu.cn/mariadb/yum/10.2/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 -
执行安装
yum -y install mariadb mariadb-server MariaDB-client MariaDB-common galera rsync -
如果之前已经安装， 需要先删除（如果之前没有安装， 可以忽略此步骤）
-
停止Mariadb服务
[root@localhost yum.repos.d]# ps -ef | grep mysql root 1954 1 0 Jun04 ? 00:05:43 /usr/sbin/mysqld --wsrep-new-cluster --user=root root 89521 81403 0 07:40 pts/0 00:00:00 grep --color=auto mysql [root@localhost yum.repos.d]# kill 1954 -
卸载Mariadb服务
yum -y remove Maria* -
删除数据与配置：
rm -rf /var/lib/mysql/* rm -rf /etc/my.cnf.d/ rm -rf /etc/my.cnf
-
-
初始化配置
systemctl start mariadb mysql_secure_installation -
开启用户远程连接权限
将连接用户root开启远程连接权限；
mysql -uroot -p654321进入MySQL服务， 执行以下操作：
use mysql; delete from user; GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '654321' WITH GRANT OPTION; FLUSH PRIVILEGES;
3.6 MariaDB集群配置
-
修改Galera同步配置
vi /etc/my.cnf.d/server.cnf修改以下内容：
[galera] wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so # 集群名称 wsrep_cluster_name=galera_cluster # 集群同步地址， 列出所有节点 wsrep_cluster_address="gcomm://10.10.20.25,10.10.20.26,10.10.20.27" # 当前节点名称， 改成本地的IP地址 wsrep_node_name=10.10.20.25 # 当前节点地址， 改成本地的IP地址 wsrep_node_address=10.10.20.25 # 绑定本地所有IP bind-address=0.0.0.0 binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 # 采用rsync作为同步方式， 默认为mysqldump wsrep_sst_method=rsync # 同步认证的用户与密码信息 wsrep_sst_auth=root:654321参数解释：
- wsrep_on：在10.1以上版本的mariadb中，该参数的默认值为OFF，意为该节点的事务将不会发送给集群中的其他节点；
- wsrep_provider：wsrep库的路径，请自行确认；
- wsrep_cluster_name：集群名称，可自定义；
- wsrep_cluster_address：第一个启动的节点务必设置为以上代码中的值；
- wsrep_node_address：定义本节点的wsrep地址与端口，默认端口为4567；
- wsrep_sst_receive_address：定义本节点接受传入请求的域名或IP，可附带端口，默认的端口根据wsrep_sst_method定义的快照传输方式的不同而不同；
- wsrep_node_name：本节点名称，在集群中需唯一；
- wsrep_sst_auth：快照传输方式的验证信息；
- wsrep_sst_method：定义快照传输方式；
- bind-address：数据库监听的IP地址
-
在每台机器上面都要修改Galera同步配置
只需修改wsrep_node_name和wsrep_node_address这两项， 其他与上面保持一致
-
10.10.20.26
vi /etc/my.cnf.d/server.cnf修改：
wsrep_node_name=10.10.20.26 wsrep_node_address=10.10.20.26 -
10.10.20.27
vi /etc/my.cnf.d/server.cnf修改：
wsrep_node_name=10.10.20.27 wsrep_node_address=10.10.20.27
-
3.7 集群启动验证
-
执行启动命令
在第一个节点10.10.20.25中启动：
/usr/sbin/mysqld --wsrep-new-cluster --user=root &注意: 如果再次启动失败, 出现以下错误:
2020-03-06 9:52:06 140480315762880 [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 . 2020-03-06 9:52:06 140480315762880 [ERROR] WSREP: wsrep::connect(gcomm://10.10.20.25,10.10.20.26,10.10.20.27) failed: 7 2020-03-06 9:52:06 140480315762880 [ERROR] Aborting解决方法:
修改/var/lib/mysql/grastate.dat配置, 将safe_to_bootstrap改为1
# GALERA saved state version: 2.1 uuid: 6c0334e2-5f4d-11ea-a524-5323162f1675 seqno: -1 safe_to_bootstrap: 1 -
加入集群
在10.10.20.26和10.10.20.27中分别执行启动命令：
systemctl start mariadb -
查看集群状态：
mysql -uroot -p654321查看集群数量：
MariaDB [(none)]> show status like "wsrep_cluster_size"; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.23 sec)查看同步状态：
MariaDB [(none)]> show status like "wsrep%"; +-------------------------------+----------------------------------------------------+ | Variable_name | Value | +-------------------------------+----------------------------------------------------+ | wsrep_applier_thread_count | 1 | | wsrep_apply_oooe | 0.000000 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 0.000000 | | wsrep_causal_reads | 0 | | wsrep_cert_deps_distance | 0.000000 | | wsrep_cert_index_size | 0 | | wsrep_cert_interval | 0.000000 | | wsrep_cluster_conf_id | 6 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | 6c0334e2-5f4d-11ea-a524-5323162f1675 | | wsrep_cluster_status | Primary | | wsrep_cluster_weight | 3 | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 0.000000 | | wsrep_connected | ON | | wsrep_desync_count | 0 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0.000507855/0.00425364/0.0152006/0.00632055/4 | | 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 | 0b35c58f-e611-11e9-b468-ce293d449404 | | wsrep_incoming_addresses | 10.10.20.26:3306,10.10.20.25:3306,10.10.20.27:3306 | | wsrep_last_committed | 0 | | wsrep_local_bf_aborts | 0 | | wsrep_local_cached_downto | 18446744073709551615 | | wsrep_local_cert_failures | 0 | | wsrep_local_commits | 0 | | wsrep_local_index | 1 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_avg | 0.062500 | | wsrep_local_recv_queue_max | 2 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_replays | 0 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_local_state_uuid | 6c0334e2-5f4d-11ea-a524-5323162f1675 | | wsrep_open_connections | 0 | | wsrep_open_transactions | 0 | | wsrep_protocol_version | 9 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy <info@codership.com> | | wsrep_provider_version | 25.3.27(r3871) | | wsrep_ready | ON | | wsrep_received | 16 | | wsrep_received_bytes | 1617 | | wsrep_repl_data_bytes | 0 | | wsrep_repl_keys | 0 | | wsrep_repl_keys_bytes | 0 | | wsrep_repl_other_bytes | 0 | | wsrep_replicated | 0 | | wsrep_replicated_bytes | 0 | | wsrep_rollbacker_thread_count | 1 | | wsrep_thread_count | 2 | +-------------------------------+----------------------------------------------------+可以看到， 三个节点成功组建集群， 状态正常。
3.8 集群负载配置与验证
-
采用Nginx实现整个集群的负载， 默认是轮询策略。
-
修改Nginx配置
vi /usr/local/nginx/nginx.conf内容如下：
worker_processes 1; events { # 每个工作进程的连接数 worker_connections 1024; } stream { # garela集群节点信息 upstream garela_cluster { server 10.10.20.25:3306; server 10.10.20.26:3306; server 10.10.20.27:3306; } # 服务配置信息 server { # 监听13306端口 listen 13306; # 代理名称， 与上面的upstream的名称保持一致 proxy_pass garela_cluster; } } -
重启Nginx服务
nginx -s reload -
负载功能验证
通过Navicat客户端， 建立连接：
打开命令列界面：
输入查询命令， 显示当前节点名称：
mariadb> SHOW VARIABLES WHERE Variable_name like '%wsrep_node_name%'; +-----------------+-------------+ | Variable_name | Value | +-----------------+-------------+ | wsrep_node_name | 10.10.20.25 | +-----------------+-------------+ 1 row in set (0.01 sec)关闭命令列界面， 关闭连接， 再次打开命令列界面进行查询：
mariadb> SHOW VARIABLES WHERE Variable_name like '%wsrep_node_name%'; +-----------------+-------------+ | Variable_name | Value | +-----------------+-------------+ | wsrep_node_name | 10.10.20.26 | +-----------------+-------------+ 1 row in set (0.01 sec)可以看到， 节点名称产生了变化， 与另外一台节点10.10.20.26建立了连接。
3.9 数据导出与导入集群迁移验证
-
导出原数据库
选择数据库右键， 【转储SQL文件】- 【结构和数据】， 保存数据库文件至指定路径。
-
导入数据库
首先创建【mirson】数据库，选中数据库， 右键， 【运行SQL文件】。
![[(img-DyQL01iS-1587805577493)(images/image-20200425165721537.png)]](https://i-blog.csdnimg.cn/blog_migrate/7d081c6294d50848bb1b9addb9398678.png)
选择导入的数据库文件:
![[(img-9Yr6VMGT-1587805577494)(images/image-20200425170220674.png)]](https://i-blog.csdnimg.cn/blog_migrate/159c216cc6bbe088612cb24af671b614.png)
将【遇到错误时继续】选项取消，点击【开始】执行导入， 导入完成之后，整个集群节点都可以看到迁移导入的数据表。
4. 合一
- MariaDB+Galera 对多主集群有较好的支持，功能强大， 在生产当中，能够满足大规模数据的应用， 但也要注意， 这种多主集群方案也会存在一定局限性，比如对锁的操作不支持，不能统一控制， 如GET_LOCK()， RELEASE_LOCK()等。
- 整个集群写入吞吐量受木桶效应， 由最弱节点限制， 如果有一个节点缓慢， 那么整个集群的数据同步都会受到影响，所以在实际项目当中， 应合理设计， 均衡利用各节点资源，采取合理的负载策略， 避免单个节点出现高负载情况，同时， 为提升稳定性， 整个集群节点应使用统一的硬件配置。
本文由mirson创作分享，如需进一步交流，请加QQ群：19310171或访问www.softart.cn
1859
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
