MySQL系列-高可用性解决方案-Percona XtraDB Cluster介绍

一、概述

Percona XtraDB集群是一个完全开源的MySQL高可用性解决方案。 它将Percona服务器和Percona XtraBackup与Galera库集成，以实现同步多主复制。一个集群由节点组成，其中每个节点包含同一节点上同步的一组数据（也就是说在任何一个节点进行写入操作，都会同步给其它所有节点写入到自己的磁盘。这点跟Oracle Rac有本质的区别，Rac是多个节点连同一个共享存储，假如Oracle的共享存储挂了，整个集群就挂了。而Mysql pxc中任何一台机器挂了，集群照常运转，因为节点间并不共享磁盘。）。 建议的配置至少有3个节点，但也可以有2个节点。 每个节点是一个常规的MySQL服务器实例（例如，Percona服务器）。 您可以将现有的MySQL服务器实例转换为节点，并使用此节点作为基础运行群集。 也可以从群集中分离任何节点，并将其用作常规MySQL服务器实例。

官方文档：https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html

二、特点

1.优点

• 多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的。
• 同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失。
• 并发复制：从节点在APPLY数据时，支持并行执行，有更好的性能表现。
• 故障切换：在出现数据库故障时，因为支持多点写入，切得非常容易。
• 热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小。
• 自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，PXC会自动拉取在线节点数据，最终集群会变为一致。
• 对应用透明：集群的维护，对应用程序是透明的，几乎感觉不到。

以上几点，足以说明PXC是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案。

2.缺点

• 配置新节点的开销。 添加新节点时，必须从现有节点中的一个复制完整数据集。 如果是100GB，则复制100GB。
• 这不能用作有效的写入缩放解决方案。 当您将写入流量运行到2个节点，而将所有流量运行到1个节点时，写入吞吐量可能会有所改善，但您不能期望太多。 所有写入仍然必须在所有节点上进行。
• 重复的数据，3个节点就会有3个重复的数据。

3.使用限制

• 复制只适用于InnoDB存储引擎。任何写入其他类型的表，包括系统(mysql.*)表复制。由于pxc只作用于innodb引擎，而mysql自带的系统库(mysql)里面有些表是MyISAM的存储引擎，因此不能直接对系统库(mysql)的表进行dml操作，比如INSERT INTO mysql.user…。而是使用CREATE USER…，这个是没有问题的，而且也是正确的方式。
• 不支持的查询：（不支持LOCK TABLES和UNLOCK TABLES语句）

– LOCK TABLES and UNLOCK TABLES is not supported in multi-master setups

– Lock functions, such as GET_LOCK(), RELEASE_LOCK(), and so on

• 查询日志不能定向到表格。如果启用查询日志记录，则必须将日志转发到文件：log_output = file （参数不能是TABLE）
• 允许的最大事务大小由wsrep_max_ws_rows和wsrep_max_ws_size变量。 LOAD DATA INFILE处理将每隔10 000行提交一次。所以大transactions由于LOAD DATA将被拆分为一系列小型transactions。
• 由于可能的提交回滚，XA(分布式)事务不受支持。
• 由于集群级乐观并发控制，事务发出COMMIT可能仍会中止阶段。
• 整个集群的写入吞吐量受最弱节点的限制。如果一个节点变慢，则整个集群变慢。
• 群集的最小建议大小是3个节点（不超过8个节点）。第三个节点可以是一个arbitrator。
• 不支持binlog_rows_query_log_events变量。
• 在SST或XtraBackup中使用的备份锁可能会崩溃。
• 新建表必须要有主键，否则对表进行dml操作会报以下错误：ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (hello.world) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER

4.与MySQL Replication区别

Percona XtraDB Cluster与MySQL Replication区别在于：

分布式系统的CAP理论：

• C— 一致性，所有节点的数据一致。

• A— 可用性，一个或多个节点失效，不影响服务请求。

• P— 分区容忍性，节点间的连接失效，仍然可以处理请求。

任何一个分布式系统，需要满足这三个中的两个：

• MySQL Replication: 可用性和分区容忍性；

• Percona XtraDB Cluster: 一致性和可用性；

因此MySQL Replication并不保证数据的一致性，而Percona XtraDB Cluster提供数据一致性。

Percona XtraDB Cluster组件：

Percona XtraDB Cluster基于XtraDB的Percona Server以及包含写复制集补丁，使用Galera 2.x library，事务型应用下的通用的多主同步复制插件。

三、原理介绍

PXC可以实现集群中数据的高度一致性，并且在每个节点上，生成的Binlog顺序都是一样的，这与Galera内部，实现的并发控制机制是分不开的。所有的上层到下层的同步、复制、执行、提交都是通过并发控制机制来管理的。这样才能保证上层的逻辑性，下层数据的完整性等。

当多个事务同时操作相同的数据资源时，这个资源在集群中是不受任何一个Session影响的，直到有一个Session对这个数据资源进行了成功的Commit操作，这时，其他的Session的所有操作实际上已经不可能成功了，当其他的事务尝试做Commit，会直接返回一个因为deadlock事务失败回滚的信息。

这与mysql默认的机制不同，在mysql innodb默认的情况下，当我们在其他事务中对某个id的数据进行update；此时我们发起一个事务对这个数据进行需要获得排它锁的操作，操作将会进行等待，直到超时失败或者现在持有排它锁的事务提交，当前事务将继续。

原理分析：

1.当client端执行dml操作时，将操作发给server，server的native进程处理请求2、client端收到ok,执行commit，server将复制写数据集发给group(cluster)，cluster中每个动作对应一个GTID

2.其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理

3.当前server节点验证通过后，执行commit_cb，并返回，若没通过，执行rollback_cb

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

四、搭建PXC时注意点

首先要规范集群中节点的数量，整个集群中节点数控制在最少3个、最多8个范围内。最少3个节点是为了防止出现脑裂现象，因为只有在两个节点下才会出现此现象。脑裂现象的标志就是输入任何命令、返回结果都是unkown command，节点在集群中，会因为新节点的加入或者故障，同步失效等而发生状态的切换。

--节点状态变化阶段：

open：节点启动成功，尝试连接到集群。

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

joiner：节点处于等待接收同步文件时的状态。

joined：节点完成数据同步的工作，尝试保持和集群进度一致。

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

doner：节点处于为新加入的节点提供全量数据时的状态。

注意：doner节点就是数据的贡献者，如果一个新节点加入集群，此时又需要大量数据的SST传输，就有可能因此而拖垮整个集群的性能。所以在生产环境中，如果数据量小，还可以使用SST全量传输，但如果数据量很大就不建议使用这种方式了。可以考虑先建立主从关系，再加入集群。

五、端口说明

3306：数据库对外服务端口

4444：SST(State Snapshot Transfer )全量传输端口, 即数据镜象传输，可配置:xtrabackup , rsync ,mysqldump

4567：成员通信端口

4568：IST(Incremental State Transfer )增量传输端口(相对于SST的增量)，只能配置xtrabackup。