pxc集群安装设置
上pxc的原因:之前使用mycat代理了一主一从两个mysql做的读写分离(可以看该专题之前的几篇文章),后来发现因为主从同步的时延原因,删除了几篇文章并且刷新页面之后还能看到这几篇文章。我这个练手的博客系统还好,数据有一致性问题没什么大关系,但是如果库里存的是订单数据,如果有数据一致性问题,后果不堪设想
PS:其实这个问题很隐蔽,应该是我限制了几个缓存大小限制了mysql的性能,造成了主从同步慢到能被观察到
- pxc的简介:
全称是Percona XtraDB Cluster,应该是业界主流的mysql集群方案,互联网公司的半壁江山,符合电商领域对数据一致性的要求。集群中的每个节点都是主节点,可以看做对一个节点的写入操作会实时同步到所有节点,所以是符合数据一致性的,少于半数节点down机不影响集群。官网:https://www.percona.com/software/mysql-database/percona-xtradb-cluster
- 下载pxc
现在最新的是5.7版本,只有linux可以用,我这里使用的linux通用免安装版(也就是一个压缩包,解压就可用的那种),也可以使用apt-get或yum或源码编译安装
ssl100、ssl101、ssl102分别对应三类linux版本,我的系统是centos7,所以下载ssl101的
将压缩包解压到/usr/local/pxc-5.7.22,在一台实体机上设置三个mysql节点的pxc伪集群,参照该官方文档,下面贴出我的配置
# my.4000.cnf
[mysqld]
port = 4000
socket=/tmp/mysql.4000.sock
datadir=/usr/local/pxc-5.7.22/4000
basedir=/usr/local/pxc-5.7.22
user=mysql
log_error=error.log
binlog_format=ROW
character_set_server=utf8mb4
performance_schema_max_table_instances=600
table_definition_cache=400
table_open_cache=256
wsrep_sync_wait=1
wsrep_cluster_address='gcomm://127.0.0.1:5030,127.0.0.1:6030'
wsrep_provider=/usr/local/pxc-5.7.22/lib/libgalera_smm.so
wsrep_sst_receive_address=127.0.0.1:4020
wsrep_node_incoming_address=127.0.0.1
wsrep_slave_threads=2
wsrep_cluster_name=trimethylxanthine
wsrep_provider_options = "gmcast.listen_addr=tcp://127.0.0.1:4030;"
wsrep_sst_method=rsync
wsrep_node_name=node4000
innodb_autoinc_lock_mode=2
# my.5000.cnf
[mysqld]
port = 5000
socket=/tmp/mysql.5000.sock
datadir=/usr/local/pxc-5.7.22/5000
basedir=/usr/local/pxc-5.7.22
user=mysql
log_error=error.log
binlog_format=ROW
character_set_server=utf8mb4
performance_schema_max_table_instances=600
table_definition_cache=400
table_open_cache=256
wsrep_sync_wait=1
wsrep_cluster_address='gcomm://127.0.0.1:4030,127.0.0.1:6030'
wsrep_provider=/usr/local/pxc-5.7.22/lib/libgalera_smm.so
wsrep_sst_receive_address=127.0.0.1:5020
wsrep_node_incoming_address=127.0.0.1
wsrep_slave_threads=2
wsrep_cluster_name=trimethylxanthine
wsrep_provider_options = "gmcast.listen_addr=tcp://127.0.0.1:5030;"
wsrep_sst_method=rsync
wsrep_node_name=node5000
innodb_autoinc_lock_mode=2
# my.6000.cnf
[mysqld]
port = 6000
socket=/tmp/mysql.6000.sock
datadir=/usr/local/pxc-5.7.22/6000
basedir=/usr/local/pxc-5.7.22
user=mysql
log_error=error.log
binlog_format=ROW
character_set_server=utf8mb4
performance_schema_max_table_instances=600
table_definition_cache=400
table_open_cache=256
wsrep_sync_wait=1
wsrep_cluster_address='gcomm://127.0.0.1:4030,127.0.0.1:5030'
wsrep_provider=/usr/local/pxc-5.7.22/lib/libgalera_smm.so
wsrep_sst_receive_address=127.0.0.1:6020
wsrep_node_incoming_address=127.0.0.1
wsrep_slave_threads=2
wsrep_cluster_name=trimethylxanthine
wsrep_provider_options = "gmcast.listen_addr=tcp://127.0.0.1:6030;"
wsrep_sst_method=rsync
wsrep_node_name=node6000
innodb_autoinc_lock_mode=2
- 初始化三个数据库实例(mysql5.6和5.7初始化方式不一样)及相关操作命令
# 分别初始化4000、5000、6000三个数据库实例
mysqld --defaults-file=/usr/local/pxc-5.7.22/my.4000.cnf --initialize
# 分别启动三个实例,将4000作为引导节点
mysqld_safe --defaults-file=/usr/local/pxc-5.7.22/my.4000.cnf --wsrep-new-cluster &
mysqld_safe --defaults-file=/usr/local/pxc-5.7.22/my.5000.cnf &
mysqld_safe --defaults-file=/usr/local/pxc-5.7.22/my.6000.cnf &
# 进入对应的error.log中找到对应实例的初始密码,登录后修改密码
mysql -uroot -p -S /tmp/mysql.4000.sock
set password=password('你的密码');
# 查看pxc状态,如果为3则大功告成
mysql -h127.0.0.1 -P6000 -uroot -p你的密码 -e "show global status like 'wsrep_cluster_size';"
# 分别关闭实例
mysqladmin -uroot -p你的密码 shutdown -S /tmp/mysql.4000.sock
# 重启pxc集群时,需要找到上次最后一个关闭的节点当做引导节点,也就是在启动命令加--wsrep-new-cluster参数
# 对应的grastate.dat文件中safe_to_bootstrap: 1则代表该节点可以当做引导节点
敲黑板!!!重点来了
注意上面的配置中
wsrep_sync_wait=1
,这个配置在官方给的参考配置中是没有的。不加该参数,在测试中发现像一个节点写入后,在另一个节点不能马上读到,也就是本文一开始的问题并没有解决。加入这个配置代表read前要保证没有所有事务都进行完,损失了一定的性能保证了实时读取。
官方文档中还说明了
wsrep_sync_wait=1
等价于wsrep_causal_reads=ON
,所以wsrep_causal_reads
参数被废弃了,但是也可以用。wsrep_sync_wait
其他的参数含义可以看官方文档。我为什么设为1只保证read操作前所有事务都完成:因为pxc多点insert没有问题,通过步长和初始值保证了自增主键不冲突(
SHOW VARIABLES LIKE 'auto_inc%'
),但是多点update会有问题。所以推荐pxc只在单节点写入,读操作可以在全部节点上负载均衡。读写分离和负载均衡可以看下一篇使用mycat代理pxc集群