如何搭建并使用数据强一致性的MySQL集群？
MySQL数据库集群之PXC方案—PXC简介
通常大家熟知的mysql集群采用的是Replication方案，Replication采用的是节点之间异步传输，无法保证数据的一致性，属于弱一致性。Replication事务机制是保证当前节点提交成功，并不保证数据同步成功。
比如下边这种情况，当我们往第一台mysql数据库写入数据，然后提交事务成功，然后因为网络原因这条数据并没有同步到另一个mysql节点，当我们通过读写分离的方式，向第二台mysql数据库发送读请求的时候，无法读到刚才写入的数据。这就是数据库集群同步采用异步传输呈现出的弱一致性出现的危害。
本文讲解的PXC方案采用的是数据强一致性，数据的强一致性100%保证往一个节点上写入数据，一定会同步到其余的mysql子节点中。
一、PXC相关简介
1.PXC简介
PXC（Percona XtraDB Cluster）是一个开源的MySQL高可用解决方案。它将Percona server和XtraBackup与galera库集成，以实现同步多主复制。基于Galera的高可用方案主要有MariaDB Galera cluster和Percona XtraDB cluster，目前PXC架构在生产线上用的很多而且更加成熟。PXC相比那些传统的基于主从模式的集群架构MHA和双主，Galera cluster最突出的特点是解决了诟病已久的复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，他们互相的关系是对等的。本身galera cluster也是一种多主架构。PXC是在存储引擎层实现的同步复制，而非异步复制，所以其数据的一致性是相当高的。
数据读写示意图:
要搭建PXC架构至少需要三个MySQL实例来组成一个集群，三个实例之间不是主从模式，而是各自为主，所以三者是对等关系，不分从属，这也叫multi-master架构。客户端读写时，连接哪个实例都是一样的，读取到的数据是相同的，写入任意一个实例后，集群会将自己新写入的数据同步到其他实例上，这种架构不共享任何数据，是一种高冗余的集群架构。
2.PXC的优缺点
优点
✔ 实现了MySQL集群的高可用性和数据的强一致性。
✔ 完成了真正的多节点读写的集群方案。
✔ 改善了主从复制延迟问题，基本上达到了实时同步。
✔ 新加入的节点可以自动部署，无需提前手动备份，维护方便。
✔ 由于是多节点写入，所以DB故障切换很容易。缺点
✔ 加入新节点时开销大，添加新节点时，必须从现有节点之一复制完整数据集。如果是100GB，则复制100GB。
✔ 任何更新的事务都需要全局验证通过，才会在其他节点上执行。集群性能受限于性能最差的节点，也就是常说的木桶定律。
✔ 因为需要保证数据的一致性，PXC采用的实时基于存储引擎层来实现同步复制，所以在多节点并发写入时，锁冲突问题比较严重。
✔ 存在写扩大的问题，所以节点上都会发生写操作，对于写负载过大的场景，不推荐使用PXC。
✔ 只支持innodb存储引擎。
3.PXC原理
PXC的操作流程大体是这样的，首先客户端向请求连接的写入节点提交事务之前，由该节点将需要产生的replication writeset广播出去，然后获取全局事务ID，一并传送到其他节点。其他节点通过certification合并数据之后，发现没有冲突数据，便执行apply_cb和commit_cb操作，否则就discard此次事务。
而当前节点（客户端请求的写入节点）通过验证之后，执行commit_cb操作，并返回OK给客户端。如果验证没有通过，则rollback_cb。
在生产线上的PXC集群中，至少有三台节点。如果其中一个节点没有通过验证，出现了数据冲突，那么此时采取的方式就是将出现数据不一致的节点踢出集群，而且它会自动执行shutdown命令来自动关机。
我们要搭建的pxc集群是三个pxc节点的集群，我们不能搭建2节点的pxc集群，为了防止脑一半以上的节点无法访问的情况下，集群会自动停止运行，如果我们配置2节点pxc集群，一旦一个节点挂掉了，恰好是一半节点不能访问，那么剩下的节点也无法使用了。这种方式的容灾性特别不好。假设是三个节点pxc集群，即便dangji宕机一个节点，我们还有2个节点可以使用，高可用性会更好一些。pxc集群增加多一些的节点，pxc集群的高可用性会更加好。一定要记住一半以上的节点宕机时pxc集群就无法使用了
4.PXC中重要的概念
首先要规范集群中节点的数量，整个集群节点数控制在最少3个、最多8个的范围内。最少3个是为了防止脑裂现象，因为只有在两个节点的情况下才会出现脑裂。脑裂的表现就是输出任何命令，返回的结果都是unknow command。
当一个新节点要加入PXC集群时，需要从集群中各节点里选举一个doner节点作为全量数据的贡献者。
PXC有两种节点的数据传输方式，一种叫SST全量传输，另一种叫IST增量传输。SST传输有XtraBackup、mysqldump、rsync三种方式，而增量传输只有XtraBackup。一般数据量不大时可以使用SST作为全量传输，但也只是使用XtraBackup方式。
节点在集群中，会因为新节点的加入或故障，同步失效等而发生状态的切换，下面列举出这状态的含义。
open：节点启动成功，尝试连接到集群。
primary：节点已在集群中，在新节点加入集群时，选取doner进行数据同步时会产生式的状态。
joiner：节点处于等待接收同步数据文件的状态。
joined：节点已完成了数据同步，尝试保持和集群中其他节点进度一致。
synced：节点正常提供服务的状态，表示已经同步完成并和集群进度保持一致。
doner：节点处于为新加入节点提供全量数据时的状态。
5.PXC中重要的配置参数
(1) 搭建PXC过程中，需要在my.cnf中设置以下参数。
wsrep_cluster_name： 指定集群的逻辑名称，对于集群中的所有节点，集群名称必须相同。
wsrep_cluster_address： 指定集群中各节点地址。
wsrep_node_name： 指定当前节点在集群中的逻辑名称。
wsrep_node_address： 指定当前节点的IP
wsrep_provider： 指定galera库的路径。
wsrep_sst_method： 模式情况下，PXC使用XtraBackup进行SST传输。强烈建议failure参数指为xtrabackup-v2。
wsrep_sst_auth： 指定认证凭证SST作为sst_user:sst_pwd。必须在引导第一个节点后创建此用户并赋于必要的权限。
pxc_strict_mode： 严格模式，官方建议该参数值为enforcing。
在PXC中还有一个特别重要的模块就是Gcache。它的核心功能就是每个节点缓存当前最新的写集。如果有新节点加入集群，就可以把新数据等待增量传输给新节点，而不需要使用SST方式。这样可以让节点更快的加入到集群中。
(2) Gcache模块涉及了如下参数
gcache.size： 代表用来缓存写集增量信息的大小。它的默认大小为128MB，通过wsrep_provider_options变量参数设置。建议调整为2G-4G范围，足够的空间便于缓存更多的增量信息。
gcache.mem.size： 代表gcache中内存换存的大小，适度调大可以提高整个集群的性能。
gcache.page.size：可以理解为如果内存不够用（cache不足），就直接将写集写入到磁盘文件中。
(3) PXC集群状态监控
在集群搭建好之后，可以通过以下状态变量’%wsrep%'来查看集群各节点的状态。
wsrep_local_state_uuid： 集群中所有节点的该状态值应该是相同的，如果有不同值的节点，说明其没有加入集群。
wsrep_last_committed： 最后提交的事务数目。
wsrep_cluster_size： 当前集群中的节点数量。
wsrep_cluster_status： 集群组成的状态。如果不是”primary“，说明出现脑裂现象。
wsrep_local_state： 当前节点状态，值为4表示正常。该状态有4个值。
joining： 表示节点正在加入集群。
doner： 节点处于为新加入节点提供全量数据时的状态。
joined： 当前节点已成功加入集群。
synced： 当前节点与集群中各节点是同步状态。
wsrep_ready： 为on表示当前节点可以正常提供服务。为off表示节点可能发生脑裂或网络问题导致。
6.PXC集群的注意事项
✔ 尽可能的控制PXC集群的规模，节点越多，数据同步速度越慢
✔ 所有 PXC节点的硬件配置要一致，如果不一致，配置低的节点将拖慢数据同步速度
✔ PXC集群只支持InnoDB引擎，不支持其他的存储引擎
7.比较PXC模式和Replication(传统主从)
PXC 集群方案所有节点都是可读可写的，Replication从节点不能写入，因为主从同步是单向的，无法从slave节点向master点同步
PXC 同步机制是同步进行的，这也是它能保证数据强一致性的根本原因，Replication同步机制是异步进行的，它如果从节点停止同步，依然可以向主节点插入数据，正确返回，造成数据主从数据的不一致性。
PXC 是用牺牲性能保证数据的一致性，Replication在性能上是高于PXC的。所以两者用途也不一致。PXC是用于重要信息的存储，例如：订单、用户信息等。Replication用于一般信息的存储，能够容忍数据丢失，例如：购物车，用户行为日志等。
二、部署PXC
环境准备
| 主机名 | IP |
|---|---|
| master | 192.168.235.13 |
| node1 | 192.168.235.14 |
| node2 | 192.168.235.15 |
1.安装PXC相关依赖包
yum install -y libev lsof perl-Compress-Raw-Bzip2 perl-Compress-Raw-Zlib perl-DBD-MySQL perl-DBI perl-Digest perl-Digest-MD5 perl-IO-Compress perl-Net-Daemon perl-PIRPC qpress socat openssl openssl-devel
2.卸载mariadb
[root@master ~]# rpm -e mariadb-libs --nodeps
3.下载软件包
wget https://www.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.18/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm
wget https://www.percona.com/downloads/Percona-XtraDB-Cluster-57/Percona-XtraDB-Cluster-5.7.28-31.41/binary/tarball/Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101.tar.gz
scp percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101.tar.gz node1:/root
scp percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101.tar.gz node2:/root
4.安装xtrabackup
yum -y localinstall percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm
5.创建MySQL的组和用户
groupadd -r mysql
useradd -M -s /bin/false -r -g mysql mysql
6.解压软件包到/usr/local/mysql，并创建数据目录，赋予权限。
tar zxf Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101.tar.gz
mv Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101 /usr/local/mysql
mkdir -p /usr/local/mysql/data/
chown -R mysql:mysql /usr/local/mysql
7.安装qpress
tar xf qpress-11-linux-x64.tar
mv qpress /usr/local/bin/
8.准备配置文件
binlog格式必须是row，node2和node3上的配置文件相同，但是注意修改server_id、wsrep_node_name、wsrep_node_address。
[root@master ~]# vim /etc/my.cnf
[client]
port=3306
socket=/tmp/mysql.sock
[mysql]
prompt="\u@\h \R:\m:\s[\d]> "
no-auto-rehash
[mysqld]
user=mysql
port=3306
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
pid-file=db.pid
character_set_server=utf8mb4
skip_name_resolve=1
open_files_limit=65535
back_log=1024
max_connections=512
max_connect_errors=1000000
table_open_cache=1024
table_definition_cache=1024
table_open_cache_instances=64
thread_stack=512K
external-locking=FALSE
max_allowed_packet=32M
sort_buffer_size=4M
join_buffer_size=4M
thread_cache_size=768
#query_cache_size = 0
#query_cache_type = 0
interactive_timeout=600
wait_timeout=600
tmp_table_size=32M
max_heap_table_size=32M
slow_query_log=1
slow_query_log_file=/usr/local/mysql/data/slow.log
log-error=/usr/local/mysql/data/error.log
long_query_time=0.1
server_id=1813306
log_bin=/usr/local/mysql/data/mysql-bin
sync_binlog=1
binlog_cache_size=4M
max_binlog_cache_size=1G
max_binlog_size=1G
expire_logs_days=7
master_info_repository=TABLE
relay_log_info_repository=TABLE
gtid_mode=on
enforce_gtid_consistency=1
log_slave_updates=1
binlog_format=row
relay_log_recovery=1
relay_log_purge=1
key_buffer_size=32M
read_buffer_size=8M
read_rnd_buffer_size=4M
bulk_insert_buffer_size=64M
lock_wait_timeout=3600
explicit_defaults_for_timestamp=1
innodb_thread_concurrency=0
innodb_sync_spin_loops=100
innodb_spin_wait_delay=30
transaction_isolation=REPEATABLE-READ
innodb_buffer_pool_size=1024M
innodb_buffer_pool_instances=8
innodb_buffer_pool_load_at_startup=1
innodb_buffer_pool_dump_at_shutdown=1
innodb_data_file_path=ibdata1:1G:autoextend
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=32M
innodb_log_file_size=2G
innodb_log_files_in_group=2
#innodb_max_undo_log_size=4G
innodb_io_capacity=2000
innodb_io_capacity_max=4000
innodb_flush_neighbors=0
innodb_write_io_threads=4
innodb_read_io_threads=4
innodb_purge_threads=4
innodb_page_cleaners=4
innodb_open_files=65535
innodb_max_dirty_pages_pct=50
innodb_flush_method=O_DIRECT
innodb_lru_scan_depth=4000
innodb_checksum_algorithm=crc32
#innodb_file_format=Barracuda
#innodb_file_format_max=Barracuda
innodb_lock_wait_timeout=10
innodb_rollback_on_timeout=1
innodb_print_all_deadlocks=1
innodb_file_per_table=1
innodb_online_alter_log_max_size=4G
internal_tmp_disk_storage_engine=InnoDB
innodb_stats_on_metadata=0
# PXC
wsrep_provider=/usr/local/mysql/lib/libgalera_smm.so
wsrep_provider_options="gcache.size=1G"
wsrep_cluster_name=pxc-test
wsrep_cluster_address=gcomm://192.168.235.13,192.168.235.14,192.168.235.15
wsrep_node_name=master
wsrep_node_address=192.168.235.13
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sst:pwd@123
pxc_strict_mode=ENFORCING
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
[mysqldump]
quick
max_allowed_packet=32M
注意：node2和node3的这几项需要修改server_id
wsrep_node_name
wsrep_node_address
9.准备node1、node2，操作同master。
配置环境变量和各节点进行初始化集群。
ln -s /usr/local/mysql/bin/* /usr/local/bin/
mysqld --defaults-file=/etc/my.cnf --user=mysql --basedir=/usr/local/mysql/ --datadir=/usr/local/mysql/data --initialize
注意：上面所有的步骤都要在三台主机上操作。
10.引导master节点初始化集群 (耐心等待一会）
(1)在master上启动MySQL
mysqld --defaults-file=/etc/my.cnf --wsrep_new_cluster &
# 刚启动时只会有4567这个端口，过一会加入集群后就会启动3306
[root@master ~]# ss -anpult | grep mysql
tcp LISTEN 0 128 *:4567 *:* users:(("mysqld",pid=79532,fd=11))
[root@master ~]# ss -lntup | grep mysql
tcp LISTEN 0 128 *:4567 *:* users:(("mysqld",pid=79532,fd=11))
tcp LISTEN 0 128 :::3306 :::* users:(("mysqld",pid=79532,fd=31))
(2)在错误日志中获取临时密码，登录MySQL终端，第一次登录需要修改密码。
grep 'password' /usr/local/mysql/data/error.log
(3)创建PXC中的SST传输账号 (对应配置文件里面的wsrep_sst_auth)。
mysql -uroot -p
alter user root@localhost identified by 'asd123';
grant all on *.* to 'sst'@'localhost' identified by 'pwd@123';
flush privileges;
11.将其他节点加入到集群
(1)在node2和node3上启动MySQL，并加入到集群中。
mysqld --defaults-file=/etc/my.cnf &
(2)此刻node2和node3正在从master往本地同步数据 (需要等待一会)
[root@node1 ~]# ss -anput | grep mysql
tcp LISTEN 0 128 *:4567 *:* users:(("mysqld",pid=35971,fd=11))
tcp ESTAB 0 0 192.168.235.14:48338 192.168.235.15:4567 users:(("mysqld",pid=35971,fd=14))
tcp ESTAB 0 0 192.168.235.14:57506 192.168.235.13:4567 users:(("mysqld",pid=35971,fd=12))
tcp LISTEN 0 128 [::]:3306 [::]:* users:(("mysqld",pid=35971,fd=33))
(3)node2和node3已将master的数据同步到本地
直接使用master上设置的MySQL root密码，就可以直接登录到MySQL终端。
mysql -uroot -pasd123
(5)查看集群状态，可以看到当前集群中有三台节点。
root@localhost 12:36: [(none)]> show global status like '%wsrep_cluster%';
+--------------------------+--------------------------------------+
| Variable_name | Value |
+--------------------------+--------------------------------------+
| wsrep_cluster_weight | 3 |
| wsrep_cluster_conf_id | 6 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | 41841af7-e61a-11ec-b1de-16b287abb0c5 |
| wsrep_cluster_status | Primary |
+--------------------------+--------------------------------------+
5 rows in set (0.01 sec)
root@localhost 12:39: [(none)]> show global status like '%wsrep_ready%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_ready | ON |
+---------------+-------+
1 row in set (0.00 sec)
12.验证复制
(1)在任意节点创建库表，往其中插入数据，在另外两个节点上查看数据是否同步。
node2上创建数据
create database test;
use test;
create table test(id int primary key auto_increment,name varchar(20));
insert into test(name) values('zhao'),('huai'),('z');
root@localhost 12:41: [test]> select * from test;
+----+------+
| id | name |
+----+------+
| 2 | zhao |
| 5 | huai |
| 8 | z |
+----+------+
3 rows in set (0.00 sec)
(2)其他节点查看数据是否同步
[root@master ~]# mysql -uroot -pasd123
root@localhost 12:42: [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test |
+--------------------+
5 rows in set (0.00 sec)
root@localhost 12:42: [(none)]> use test
root@localhost 12:42: [test]> show tables;
root@localhost 12:42: [test]> select * from test;
+----+------+
| id | name |
+----+------+
| 2 | zhao |
| 5 | huai |
| 8 | z |
+----+------+
3 rows in set (0.00 sec
Don’t let anyone drain your inner sunshine. Life should be filled with people and things you love.
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
