1.pxc说明

pxc:Percona XtraDB Cluster,部署pxc,必须是percona .不能是官方版.

mgc:mariadb Galera cluster,部署必须是mariadb

pxc和mgc高度类似.

PXC 已经底层的源码进行修改,复制通道并不是走的3306,这也是为什么不能用官方版本的原因.

PXC不需要编译安装Galera library  而  mariadb需要编译安装Galera library

WSREP :write set replication 写集复制      Galera library  PXC的依赖库库文件

pxc的WSREP是基于行级别的并行复制,但其复制效率比较低,比异步复制低1/3-1/2.

MySQL复制: 可以访问所有的系统.但是数据不一致.   PXC: 数据完全一致.

 2.pxc特性(强数据一致性,多主写入,自动节点的添加)

部署pxc是三节点起步,其特性有:

1.data consistency: 强数据一致性.(支持同步复制)

2. synchronous replication: 同步复制(可设置完全同步,设置成最终一致性)

3.multi-master replication:支持多主写入. 不会造成1.丢数据 2.无需人为的处理主键冲突.

4.parallel applying on slaves: 并行复制(行级别并行复制)

5.automatic node provisioning: 自动节点的添加

 3.工作原理

基于认证的复制:客户端发出commit后，此时并没有发生真正的COMMIT，而是对事物更改的行写入写入集（writeset），并且会在每个节点上使用搜索到的主键进行确认性测试，测试此更改能否被应用。如果测试失败，则writeset被丢弃，事务回滚。如果测试成功事务会被提交，并且应用到其他节点。

即使没有真正的写入当前节点，但是如果其他节点认证成功的话，那么认为写入成功，返回正确结果，这段时间内，数据是有延迟的，这个时候可能不同节点，读取的时候，不一致，可以使用wsrep_causal_reads=ON来避免这种情况。这种情况需要等待全同步复制。

 4.数据最终一致性

数据一致性的原因:主库只要能向从库提交数据,返回了提交的确认信息,集群的其他节点,就能保证事务提交成功.等所有节点返回数据后,然后各节点再分别提交事务.这样导致主库必须要等所有从库返回确认信息后再提交.会产生木桶效应,某个节点性能差,会拖累整个集群的处理性能.为避免木桶效应,采用最终一致性.故一般情况下,并不是完全一致性,而是最终一致性.完全一致性的可行性有问题.

最终一致性:从节点能保证事务最终能提交成功,但不保证与主节点是同时提交的.

完全一致性:从库必须与主库一起提交成功.

 5.PXC同步复制与PXC优缺点

pxc因为修改了底层复制通道,可以保证主从不存在丢失事务的情况,导致无延迟.pxc的复制也是基于binlog,必须是row格式.

同步复制:

1. 同步复制 Synchronous replication，事务要不在所有节点提交，要不都回滚。

2. 多主复制，可以在任何节点进行读写操作

3. 主从复制为row级别的复制。

4. 同步无延迟，保证数据一致性

5. 使用原生MySQL接口

6. 每个节点都具有完整的数据副本

7. 多台数据库中数据同步由 wsrep 接口实现

 优势:

1. 因为是多主，所以不存在Slavelag(延迟)

2. 不存在丢失事务的情况

3. 同时具有读和写的扩展能力

4. 更小的客户端延迟

5. 节点间数据是同步的,而Master/Slave模式是异步的,不同slave上的binlog可能是不同的.

pxc相比mha,可以保证不丢时间,mha的binlog补偿机制是有局限性的,.

一些限制:

1. 仅支持innodb存储引擎，其他表都不会被复制。

2. delete不支持没有主键的表

3. 所有的表都应该具有主键。

4. 不能有大事务写入，不能超过wsrep_max_rows，并且不能报错wsrep_max_ws_size,否则客户端报错

5. 写性能取决于最差的节点,整个集群的写入吞吐量是整个集群的弱点，比如某个节点的硬盘变慢，则整个集群变慢

6. 尽量不要跨机房，跨机房如果带来大量的网络延迟，那么集群的效率将会变得很低

7.不能解决热点更新问题, pxc虽然可以多节点写入,而且集群自动解决主键冲突问题.但较少使用多点写入功能,一般只将pxc当做高可用来使用,原因:多点写入会造成热点更新问题和锁与事务回退等.(热点更新问题:同时对热数据更新,导致有的事务成功,有的事务被回退,严重影响业务)

8.对于写密集型应用需要控制单个节点的大小，单个节点数据越大，新加节点如果采用自动添加可能产生很大抖动（自动添加节点需注意单个DB的大小,添加节点建议用备份或者备份+binlog 进行ist 同步,减少抖动.）。

9.复制效率低导致流控问题(主库写入效率高,从库队列被填满,则会导致整个集群对外锁死,流量控制,不对外服务,只有等待队列慢慢消化后,才可再次写入)

 6.Galera的状态快照转移（SST与ist）

Galera的状态快照转移（SST）

SST允许新接入的节点使用定制的方法来获取最初的数据，当前mysql支持三种SST方法：

1、mysqldump

这需要接收服务器在转移前完全初始化和准备接收连接。此方法是通过定义阻塞，阻止修改自身状态转移的持续时间。这也是最慢的方式，可能会带来高负载的问题。需要提供其他复制节点的帐号密码,会锁表.

2、rsync

最快的方式，也是galera默认使用的方式。rsync脚本运行在发送和接收端上。在接收端，开启rsync服务模式，等待发送端连接。在发送端，开启rsync客户端模式，发送mysql数据目录内容到连接节点。这种方法也会阻塞，但是比mysqldump快。全量数据拷贝底层文件,无需提供账号密码,会锁表.

3、xtrabackup

也很快，但需要额外安装，xtrabackupu不会在进行数据迁移的过程中加锁，推荐使用xtrabackup进行搭建，不需要初始化数据目录.需要提供其他复制节点的账号和密码.是不加锁复制.(wsrep_sst_method=xtrabackup-v2)

 

添加节点的方法: sst (全量复制) 和ist(增量复制)

ist 采用增量复制的方式,来进行数据的补偿,但是是有限制的,如果超过了,就自动转为sst

怎样区分是增量还是全量同步:

cd  /database/mysql3306/mysql3306:发现文件galera.cache,这是缓存的队列文件,若同步的数据超过该文件大小(1G,可调),则为全量同步:

-rw-r----- 1 mysql mysql 134219048 Sep  6 04:22 galera.cache

 

部署pxc

 1.移除之前官方mysql版本

先移除之前的官方版本mysql:

[root@master1 ~]# mv /database/mysql3306/mysql3306 /database/mysql3306/mysql3306.bak

[root@master1 ~]# rm -fr /database/mysql3306/logs/*

[root@master1 ~]# mkdir /database/mysql3306/mysql3306

[root@master1 ~]# chown mysql.mysql /database/mysql3306/mysql3306

[root@master1 local]# mv ./mysql mysqlbak    

 2.安装percona.(三台主机都安装)

tar xvf Percona-XtraDB-Cluster-5.7.19-rel17-29.22.3.Linux.x86_64.ssl101.tar.gz

mv  Percona-XtraDB-Cluster-5.7.19-rel17-29.22.3.Linux.x86_64.ssl101/  /usr/local/mysql

[root@master1 local] chown -R mysql.mysql /usr/local/mysql

 

 3.配置文件解析及修改(三台主机都做相应修改)

##############################################################

innodb_autoinc_lock_mode=2

bind-address=0.0.0.0

#galera的库文件的地址

wsrep_provider=/usr/local/mysql/lib/libgalera_smm.so

wsrep_on=on

pxc_strict_mode=ENFORCING

#监听服务

wsrep_provider_options="gmcast.listen_addr=tcp://0.0.0.0:4567;"

#集群名称,各节点需要一样

wsrep_cluster_name="mysql_pxc"

#集群内成员的ip地址

wsrep_cluster_address="gcomm://192.168.2.10,192.168.2.11,192.168.2.12"

#本节点主机名

wsrep_node_name=master

#本节点ip地址

wsrep_node_address=192.168.2.10

#并行复制线程数

wsrep_slave_threads=4

wsrep_certify_nonPK=1

#事务最大的行数和大小

wsrep_max_ws_rows=131072

wsrep_max_ws_size=1073741824

wsrep_debug=0

wsrep_convert_LOCK_to_trx=0

wsrep_retry_autocommit=1

wsrep_auto_increment_control=1

wsrep_drupal_282555_workaround=0

pxc_strict_mode = ENFORCING

wsrep_causal_reads=0

###sst的方法和用户密码.

wsrep_sst_method=xtrabackup-v2

wsrep_sst_auth=root:root

############################################################

修改配置文件后,将上面项追加放置到mysqld下.

修改内容如下:其他机器修改以下两项即可.其他不变.

#本节点主机名              wsrep_node_name=master

#本节点ip地址             wsrep_node_address=192.168.2.10

 

参数说明:

pxc端口

mysql实例端口：3306

pxc cluster相互通讯的端口：4567

wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4567; "

innodb_autoinc_lock_mode=2

1.innodb_autoinc_lock_mode=0，在这一模式下，所有的insert语句倒要在语句开始的时候得到一个表级的auto_inc锁，在语句结束的时候才释放这把锁。由于锁要保持的语句结束，影响到了并发的插入

2.innodb_autoinc_lock_mode=1，对simple insert做了优化，一次性插入值的个数可以立马得到确定，所以mysql可以一次生成几个连续的值，用于这个insert语句，保证了基于语句复制的安全，这是mysql的默认模式，好处是auto_inc锁(自增锁,insert瞬间加锁,不用等commit,即自动释放)不需要一只保持到语句的结束，只要语句得到了相应的值后就可以提前释放锁，可能会造成id不连续出现1，3，2的情况

3。innodb_autoinc_lock_mode=2，这个模式下没有了auto_inc锁，性能最优，但会造成基于statement的复制出问题，主要会造成从库的主键冲突

总结：1 innodb row复制时，可将innodb_autoinc_lock_mode设置为2，这时可在所有insert情况下表获得最大并发度

2 innodb statement复制时，可将innodb_autoinc_lock_mode设置为1，保证复制安全的同时，获得简单insert语句的最大并发度(一般都是row格式,不用statement格式.)

3 myisam引擎情况下，无论什么样自增id锁都是表级锁，设置innodb_autoinc_lock_mode参数无效（测试略）

wsrep_max_ws_rows和wsrep_max_ws_size

允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。

wsrep_causal_reads:

COMMIT的响应时间由下面几部分组成:

网络往返的时间,认证时间,本地执行的时间

可能在从库上面读到还未改变的数据..然而,这种行为可以通过参数变量wsrep_causal_reads=ON改变,在这种情况下,想要读取从库的数据,需要等待事务执行完(但是,这会增加响应时间).复制之所以被称为"virtually synchronous replication"而不是"synchronous replication",就是因为主库和从库直接存在这种间隔.

 4.初始化数据库

初始化: /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --initialize-insecure --basedir=/usr/local/mysql --user=mysql

 5.启动集群第一个节点并授权(--wsrep-new-cluster )

/usr/local/mysql/bin/mysqld_safe --ledir=/usr/local/mysql/bin --basedir=/usr/local/mysql --wsrep-new-cluster --user=mysql &

启动注意指定--ledir,第一个节点加上--wsrep-new-cluster选项.

开启成功后,直接输入mysql回车,即可进入数据库.

授权:

grant all on *.* to root@'%' identified by 'root';

grant all on *.* to root@'localhost' identified by 'root'; (--这步一定要做.否则无权限)

flush privileges;

 6.安装xtrabackup及pxc依赖包

因配置文件:wsrep_sst_method=xtrabackup-v2    故需安装xtrabackup.

软件包:percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm 和libev-4.15-3.el7.x86_64.rpm

 1.安装依赖包:

yum install perl-DBI

yum install perl-DBD-MySQL

 2.安装依赖:

yum -y localinstall  libev-4.15-3.el7.x86_64.rpm

安装xtrabackup

yum -y localinstall percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm

查看是否安装成功: innobackupex --help  或者 innobackupex --help

安装完成后再安装依赖包:    yum -y install socat*

 7.开启其他节点(无需初始化mysql,无主从搭配)

将主节点的修改配置文件的scp到其他机器,修改其中两项即可:

wsrep_node_name=master 和       wsrep_node_address=192.168.2.10

开启其他节点无需初始化数据库,但需前提建好/database/mysql3306/logs/mysql-error.log文件,否则无法成功.

touch mysql-error.log        chown mysql.mysql mysql-error.log

无需初始化,直接启动,即可同步master1的信息.

直接开启同步:

/usr/local/mysql/bin/mysqld_safe --ledir=/usr/local/mysql/bin --basedir=/usr/local/mysql --user=mysql &

同步时也会将master的创建的用户及权限同步过来.故同步完成后可直接mysql -p登录.

故pxc无所谓搭建主从.数据库安装后,无需初始化,无需搭建主从即可实现数据同步.

 8.查看wsrep状态

在任何一节点里:mysql> show status like '%wsrep%';

 9.测试及修复后加入集群

在其中一台节点上建表建库,发现自动都同步了.

注意:xpc里建表一定要带主键,最好设置主键自增长.且主键一定是int类型.

create table test2 (id int primary key auto_increment,wold varchar(6));

 insert into test2 values (null, 'a');

 insert into test2 values (null, 'b');

 insert into test2 values (null, 'c');

发现自动解决了主键冲突问题,步长为节点个数.(步长为3)

关闭某节点的mysql,发现自增长产生波动,然后根据正常的节点个数自动调整.(步长为2)

show status like '%wsrep%';显示的信息也自动改变

修改节点后加入集群,发现自动同步:

/usr/local/mysql/bin/mysqld_safe --ledir=/usr/local/mysql/bin --basedir=/usr/local/mysql --user=mysql &

节点宕机后，指定节点donor加入集群(不选会自动选一个)

/usr/local/mysql/bin/mysqld_safe --ledir=/usr/local/mysql/bin --basedir=/usr/local/mysql --

wsrep_sst_donor=192.168.88.2 &

pxc常用命令及状态检查

查看版本:SHOW GLOBAL STATUS LIKE 'wsrep_provider_version';

查看wsrep有关的所有变量:SHOW VARIABLES LIKE 'wsrep%' \G

查看GALERA集群状态: show status like 'wsrep%';

 

 1.节点状态检查:

通过show status like 'wsrep%'在里面查看

wsrep_ready：该值为ON,则说明可以接受SQL负载.如果为Off,则需要检查wsrep_connected

wsrep_connected：如果该值为Off,且wsrep_ready的值也为Off,则说明该节点没有连接到集群.(可能是wsrep_cluster_address或wsrep_cluster_name等配置错造成的.具体错误需要查看错误日志)

wsrep_local_state_comment：如果wsrep_connected为On,但wsrep_ready为OFF,则可以从该项查看原因.

 2.复制健康检查:

wsrep_flow_control_paused：表示复制停止了多长时间.即表明集群因为Slave延迟而慢的程度.值为0~1,越靠近0越好,值为1表示复制完全停止.可优化wsrep_slave_threads的值来改善

wsrep_cert_deps_distance：有多少事务可以并行应用处理.wsrep_slave_threads设置的值不应该高出该值太多.

wsrep_flow_control_sent：表示该节点已经停止复制了多少次

wsrep_local_recv_queue_avg：表示slave事务队列的平均长度.slave瓶颈的预兆.

最慢的节点的wsrep_flow_control_sent和wsrep_local_recv_queue_avg这两个值最高.这两个值较低的话,相对更好.

 3.检测慢网络问题:

wsrep_local_send_queue_avg:网络瓶颈的预兆.如果这个值比较高的话,可能存在网络瓶

 4.冲突或死锁的数目:

wsrep_last_committed:最后提交的事务数目

wsrep_local_cert_failures和wsrep_local_bf_aborts:回滚,检测到的冲突数目

 5.pxc备份问题

备份时,某个节点性能较低的话,,其效率会下降,因pxc复制的木桶效应,带来的问题是拖慢整个集群的效率..解决方法:

1.备份问题,外挂一个从库专门做备份.(从库是异步的,不影响性能.)

2.在有主从的情况下,把备份作业优先放置到从库.