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集群
