PXC集群资料整理

1、mysql集群方案对比

方案1  NDBCluster 

参考：https://www.cnblogs.com/kevingrace/p/5685371.html?utm_source=itdadao&utm_medium=referral

优点：

1、通过自动分片实现高水平的写入扩展能力MySQL Cluster 自动将表分片（或分区）到不同节点上，

   使数据库可以在低成本的商用硬件上横向扩展，同时保持对应用程序完全应用透明。

2、99.999%的可用性凭借其分布式、无共享架构，MySQL Cluster 可提供 99.999% 的可用性，

   确保了较强的故障恢复能力和在不停机的情况下执行预定维护的能力

3、实时性能好，MySQL Cluster 提供实时的响应时间和吞吐量，能满足最苛刻的 Web、电信及企业应用程序的需求

4、具有跨地域复制功能的多站点集群 跨地域复制使多个集群可以分布在不同的地点，从而提高了灾难恢复能力和全球

   Web 服务的扩展能力。

5、联机扩展和模式升级为支持持续运营，MySQL Cluster 允许向正在运行的数据库模式中联机添加节点和更新内容，

   因而能支持快速变化和高度动态的负载。

缺点：

1、基于内存，数据库的规模受集群总内存的大小限制

2、多个节点通过网络实现通讯和数据同步、查询等操作，因此整体性受网络速度影响

3、NDB的事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改

4、Data Node节点数据会被尽量放在内存中，对内存要求大。

5、外键支持：虽然最新的Cluster版本已经支持外键，但性能有问题（因为外键所关联的记录可能在别的分片节点中），

   所以建议去掉所有外键。

 

方案2  Mysql组复制

参考：https://blog.csdn.net/weixin_34162695/article/details/85997711

     https://www.cnblogs.com/f-ck-need-u/p/9197442.html

     https://blog.csdn.net/wwy0324/article/details/81572312

     https://blog.51cto.com/ylw6006/1971139

优点：

1、高一致性

   基于原生复制及 paxos 协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；

2、高容错性

   只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，

   按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

   高扩展性

3、节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，

   如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

4、高灵活性

   有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有 server

   都可以同时处理更新操作。

缺点：

1、InnoDB存储引擎：数据必须存储在事务型的InnoDB存储引擎中

2、Primary Keys：每张需要被组复制的表都必须显式定义一个主键

3、使用IPv4 地址：MySQL组复制使用的组通信引擎组件只支持 IPv4

4、良好的网络性能：组复制设计的初衷是部署在集群环境中，集群中的节点相互之间都非常近，因此除了网络延迟，网络带宽也会影响组复制。

5、如果只是实现高可用，数据同步，组复制需要添加中间件，数据同步是集群内部操作，而直接用JDBC去连接是不能实现自动的高可用。

 

方案3  基于主从复制的高可用方案：双节点主从 + keepalived

方案4  基于主从复制的高可用方案：多节点主从+MHA/MMM

 

方案5  基于Galera协议的高可用方案：PXC

优点：

1、服务高可用 多个节点的数据是相同的，只要最后一个节点可用，就还能运行。

   无需集中管理。可以在任何时间点失去任何节点，但是集群将照常工作，不受影响。

2、同步复制，事务要么在所有节点提交或不提交。各节点间无延迟且节点宕机不会导致数据丢失。

3、多主复制，可以在任意节点进行写操作。

4、在从服务器上并行应用事件，真正意义上的并行复制。

5、节点自动配置。无需手工备份当前数据库并拷贝至新节点。

6、数据一致性，不再是异步复制。

7、PXC最大的优势：强一致性、无同步延迟

8、应用程序的兼容性：无需更改应用程序

缺点：

1、对InnoDB的事物控制是支持的，其他的不支持，5.7版本

2、加入新节点，开销大。需要复制完整的数据。新加入节点采用SST时代价高；

3、不能有效的解决写缩放问题，所有的写操作都将发生在所有节点上。

4、有多少个节点就有多少重复的数据。

5、写入效率取决于节点中最弱的一台，因为PXC集群采用的是强一致性原则，一个更改操作在所有节点都成功才算执行成功。

   集群吞吐量/性能取决于短板；

6、所有表都要有主键；

7、锁冲突、死锁问题相对更多

8、不支持LOCK TABLE等显式锁操作；

9、不支持XA；

XA百度百科解释：分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

 

参考：http://blog.itpub.net/15498/viewspace-2135219/

 

2、PXC原理

PXC会使用大概是4个端口号

3306：数据库对外服务的端口号

4444：请求SST SST: 指数据一个镜象传输 xtrabackup , rsync ,mysqldump 在新节点加入时起作用

4567: 组成员之间进行沟通的一个端口号

4568: 传输IST用的。相对于SST来说的一个增量  ，节点下线，重启加入时起作用

名词：

WS：write set 写数据集

IST: Incremental State Transfer 增量同步

SST：State Snapshot Transfer 全量同步

 

PXC架构示意图

Galera是Codership提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，

并且可保障数据库的服务高可用及数据一致.

 

数据读写示意图

可以在集群中的任意一个节点上进行读写操作

 

异步复制与半同步复制

不管同步或是半同步，都存在一定的延迟。

异步复制，在主节点上提交成功后，以日志的方式提交到从节点，从节点开始写入，这之间有一个时间延时

半同步复制，在主节点上开始提交后就提交日志，主节点上提交成功后，从节点开始写入。延时时间会小一点。

PXC最大的优势：强一致性、无同步延迟

    每一个节点都可以读写，WriteSet写的集合，用箱子推给Group里所有的成员， data page 相当于物理复制，

而不是发日志，就是一个写的结果了。

    当client端执行dml操作时，将操作发给server，server的native进程处理请求，client端执行commit，

server将复制写数据集发给group(cluster)，cluster中每个动作对应一个GTID，其它server接收到并通过验证(合并数据)后，

执行appyl_cb动作和commit_cb动作，

    若验证没通过，则会退出处理;当前server节点验证通过后，执行commit_cb，并返回，若没通过，执行rollback_cb。

只要当前节点执行了commit_cb和其它节点验证通过后就可返回。

    用户发起Commit，在收到Ok之前，集群每次发起一个动作，都会有一个唯一的编号 ，也就是PXC独有的Global Trx Id。

动作发起者是commit_cb，其它节点多了一个动作： apply_cb

   任意节点收到sql请求，对于dml更新操作事务，在commit之前，由wsrep API调用galera库进行集群内部广播，

验证当前事务是否能在所有节点中执行，验证通过后该事务真正提交到集群所有节点执行，反之roll back回滚。

 

3、PXC环境搭建

在host文件中设置了节点:  （后面名称即为对应的ip）

    centos1 10.3.13.213  node1

    centos2 10.3.13.197  node2

    centos3 10.3.13.194  node3

 

关闭防火墙

开放系统的3306端口   如果设置了防火墙的话，我们搭建的系统把防火墙已经关了

firewall-cmd  --zone=public --add-port=3306/tcp --permanent

firewall-cmd --reload

 

检查是否安装有MySQL Server： 在安装percona之前需要将mysql以及mariadb删除

rpm -qa | grep mysql

rpm -qa | grep  mariadb 查找是否有mysql或mariadb存在

删除方法：

rpm -e mysql   #普通删除模式

rpm -e --nodeps mysql    #强行删除模式，如果使用上面命令删除时，提示有依赖的其它文件，则用该命令可以对其强行删除。

yum remove mariadb-libs-5.5.41-2.el7_0.x86_64

要注意的是mariadb也是不能存在的,有的话就要删除,删除的时候有依赖关系,直接yum卸载

 

设置 vim /etc/selinux/config    

SELINUX=disabled  

需要reboot重启后生效

 

安装yum源 

yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm

这个0.1-6已经是目前最新的yum源了

yum list | grep percona  查看当前安装的percona软件

 

安装依赖包

发现安装有问题需要依赖包：

yum install perl-IO-Socket-SSL.noarch

yum install  perl-DBD-MySQL.x86_64

yum install  perl-Time-HiRes

yum install  openssl

yum install  openssl-devel

yum install  socat

备份用到的软件 yum install percona-xtrabackup-24.x86_64

 

安装集群服务等软件包

在线安装发现特别慢，所以采用离线安装。在官网下载http://www.percona.com/

tar -xvf Percona-XtraDB-Cluster-5.7.23-31.31-r438-el7-x86_64-bundle.tar

yum install *.rpm

目前所有安装的内容：

$ rpm -qa|grep -i percona                                                

Percona-XtraDB-Cluster-devel-57-5.7.23-31.31.2.el7.x86_64

percona-xtrabackup-24-2.4.13-1.el7.x86_64

Percona-XtraDB-Cluster-shared-57-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-57-debuginfo-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-57-5.7.23-31.31.2.el7.x86_64

percona-release-0.1-6.noarch

Percona-XtraDB-Cluster-shared-compat-57-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-test-57-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-garbd-57-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-server-57-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-client-57-5.7.23-31.31.2.el7.x86_64

Percona-XtraDB-Cluster-full-57-5.7.23-31.31.2.el7.x86_64

上面的操作需要在每个节点上进行，

 

配置文件

vim /etc/my.cnf

[mysqld]

datadir=/var/lib/mysql

user=mysql

server-id=1 # PXC集群中MySQL实例的唯一ID，不能重复，必须是数字   （这个也可以不用配置，每一个节点都不需要配置）

wsrep_provider=/usr/lib64/galera3/libgalera_smm.so   指定Galera库的路径

wsrep_cluster_name=pxc-cluster  #PXC集群的名称

 

wsrep_cluster_address=gcomm://10.3.13.213,10.3.13.197,10.3.13.194 

集群中各节点地址。地址使用组通信协议gcomm://(group communication)

 

wsrep_node_name=node1  #当前节点的名称

wsrep_node_address=10.3.13.213  #当前节点的IP（这里也可以填写host文件中ip对应的名称）

 

wsrep_sst_method=xtrabackup-v2  #同步方法（mysqldump、rsync、xtrabackup）

tate_snapshot_transfer(SST)使用的传输方法，可用方法有mysqldump、rsync和xtrabackup，前两者在传输时都需要对Donor加全局只读锁(FLUSH TABLES WITH READ LOCK)，xtrabackup则不需要(它使用percona自己提供的backup lock)。强烈建议采用xtrabackup

 

wsrep_sst_auth= sstuser:Abc_123456  #同步使用的帐户，在SST传输时需要用到的认证凭据，格式为："用户：密码"

pxc_strict_mode=ENFORCING  #同步严厉模式 是否限制PXC启用正在试用阶段的功能，ENFORCING是默认值，表示不启用

binlog_format=ROW  #基于ROW复制（安全可靠）

default_storage_engine=InnoDB  #默认引擎

innodb_autoinc_lock_mode=2  #主键自增长不锁表  只能设置为2，设置为0或1时会无法正确处理死锁问题

 

主节点操作：

在启动前现需要运行下：停止MySQL服务 service mysql stop  否则下面的运行不能启动

主节点的启动命令与从节点是有区别的。

systemctl start mysql@bootstrap.service

systemctl stop mysql@bootstrap.service

systemctl restart mysql@bootstrap.service

 

进入mysql进行操作：

#查看 root 密码

cat /var/log/mysqld.log | grep "A temporary password"

#修改 root 密码,建议先创建快照,以便恢复.

mysql_secure_installation

 

进入数据库

mysql -uroot -p

在数据库库中查看当前状态：mysql> show status like 'wsrep%';

在结果中注意

| wsrep_incoming_addresses         | 10.3.13.213:3306                     | 目前集群中只有一个ip

| wsrep_cluster_size               | 1                                    | 目前node2和node3还没有加进来

 

pxc集群启动问题：https://blog.csdn.net/geoffreychan/article/details/80499956

 

从节点启动：

systemctl start mysqld

这里在启动从节点的时候一直报错，通过查找/var/lib/mysql下的错误日志和查看主节点的innobackup.backup.log

发现是同步账户sstuser的权限问题。

 

登录数据库

mysql -uroot -p

创建、授权、同步账号

mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'Abc_123456';

mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';

mysql> FLUSH PRIVILEGES;

 

数据库设置权限：

mysql> set global validate_password_policy=0  设置安全级别，0 是最低的

mysql> set global validate_password_length=4; 设置最小的密码长度

mysql> set PASSWORD=PASSWORD('123456');  重新设置密码

赋予远程访问的权限：

mysql> grant all privileges  on *.* to root@'%' identified by "123456";  设置远程访问的权限

mysql>  flush privileges;

 

4、PXC操作

对搭建的三个节点的数据库进行测试：

mysql -uroot -p

在节点node3上  mysql> create database yl123_db;

在节点node2上  mysql> show databases; 会发现数据已经同步过去了

 

将portal数据库转存储到percona上去

开始的时候portal数据库转存储为sql文件后，在保存到percona上出错，是因为version_history没有设置主键

percona的数据库中每个table都需要主键

将portal中的version_history添加主键后，poral数据库可以完全的拷贝到percona的一个节点，拷贝成功后，查看

其他节点，数据库已经同步过去了。

 

旧节点加入到集群中：

    如果旧节点加入Galera集群，说明这个节点在之前已经在Galera集群中呆过，有一部分数据基础，缺少的只是它离开集群时的数据。

这时加入集群时，会采用IST(incremental snapshot transfer)传输机制，即使用增量传输。但注意，这部分增量传输的数据源是Donor

上缓存在GCache文件中的，这个文件有大小限制，如果缺失的数据范围超过已缓存的内容，则自动转为SST传输。如果旧节点上的数据和Donor

上的数据不匹配(例如这个节点离组后人为修改了一点数据)，则自动转为SST传输。关于GCache以及Galera是如何判断数据状态的，本文不展开

描述，可参见Understanding GCache in Galera。

 

    节点在退出集群后, 从新加入的时候, 如果这个故障节点的ip 在自己的配置文件 wsrep_cluster_address 的选项中的第一个ip .

那么这个节点是永远都无法再加入这个集群了.参考：http://blog.itpub.net/133735/viewspace-2140548/

    若是主节点，ip不能放在第一个，不能再用开始启动主节点的方式来进行启动 。

    之前的从节点重启后就加入到集群中去了，没啥特殊

 

新节点加入到集群中：

    新节点加入集群时，需要从当前集群中选择一个Donor节点来同步数据，也就是所谓的state_snapshot_tranfer(SST)过程。

SST同步数据的方式由选项wsrep_sst_method决定，一般选择的是xtrabackup。

    wsrep_sst_method：state_snapshot_transfer(SST)使用的传输方法，可用方法有mysqldump、rsync和xtrabackup，前两者在传输时都需要对Donor加全局只读锁(FLUSH TABLES WITH READ LOCK)，xtrabackup则不需要(它使用percona自己提供的backup lock)。强烈建议采用xtrabackup

    必须注意，新节点加入Galera时，会删除新节点上所有已有数据，再通过xtrabackup(假设使用的是该方式)从Donor处完整备份

所有数据进行恢复。所以，如果数据量很大，新节点加入过程会很慢。而且，在一个新节点成为Synced状态之前，不要同时加入其它新

节点，否则很容易将集群压垮。如果是这种情况，可以考虑使用wsrep_sst_method=rsync来做增量同步，既然是增量同步，最好保证

新节点上已经有一部分数据基础，否则和全量同步没什么区别，且这样会对Donor节点加上全局read only锁

1 OPEN 节点启动成功，尝试连接到集群，如果失败则根据配置退出或创建新的集群

2 PRIMARY 节点已处于集群中，在新节点加入时，选取donor进行数据同步时会产生的状态

3 JOINER 节点处于等待接收/接收同步文件时的状态

4 JOINED 节点完成数据同步，但有部分数据没跟上，在尝试保持和集群进度一致的过程状态

         例如某个节点故障后，重新加入集群，在追赶集群进度时的状态

5. SYNCED 节点正常提供服务的状态，表示已经同步完成并和集群进度保持一致。

6. DONOR 节点处于为新节点提供全量数据数据同步时的状态。此时该节点对客户端不提供服务。

 

参考：https://blog.51cto.com/arvin0213/2308595

    如果是集群是新搭建的，或者说直接使用SST的方式加入新节点，那么新节点的配置就直接按照前面的主节点配置来就可以了，只是把wsrep_node_address改成

对应节点的IP即可，而对于已经运行了一段事件的集群，新加入节点使用SST传送全量数据的方式同步的代价比较高，所以下面讨论一个IST方式加入新节点同步数据的方式

 

5、JDBC连接

spring中的jdbc配置1：顺序优先的方式

jdbc.driver=com.mysql.jdbc.Driver

jdbc.url=jdbc:mysql://10.3.13.213:3306,10.3.13.197:3306,10.3.13.194:3306/portalyl

jdbc.username=root

jdbc.password=123456

node1可用的时候，永远只连接上的是node1

node1挂掉之后，就会去连接node2，依次往后

 

spring中jdbc的配置2：负载均衡的模式

jdbc.driver=com.mysql.jdbc.Driver

jdbc.url=jdbc:mysql:loadbalance://10.3.13.213:3306,10.3.13.197:3306,10.3.13.194:3306/portalyl?loadBalanceAutoCommitStatementThreshold=5

jdbc.username=root

jdbc.password=123456