PXC入门探索

一、Galera Cluster

源于：https://galeracluster.com/products/`

何谓Galera Cluster？就是集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster（也成PXC）及MariaDB Cluster，都是基于Galera的，所以这里都统称为Galera Cluster了，因为Galera本身是具有多主特性的，所以Galera Cluster也就是multi-master的集群架构，如图`

1.优点

1> 真正的多主，群集随时读取和写入任何节点。
2> 同步复制没有从属滞后，在节点崩溃时不会丢失任何数据。
3> 紧密耦合所有节点都保持相同状态。节点之间不允许有分散的数据。
4> 对于任何工作量，使用多线程从站可以获得更好的性能。
5> 没有主从故障转移操作或VIP使用。
6> 热备在故障转移期间没有停机时间（因为没有故障转移）。
7> 自动节点置备无需手动备份数据库并将其复制到新节点。
8> 支持InnoDB。
9> 对应用程序透明对应用程序无要求（或进行最小的更改）。
10> 无需读写拆分。
11> 易于使用和部署

2.Galera复制

Galera复制在事务提交时发生，方法是将事务写集广播到群集以进行应用
客户端直接连接到DBMS，并且体验接近本机DBMS的行为
wsrep API（写集复制API），定义Galera复制和DBMS之间的接口

3.同步与异步复制

同步复制和异步复制之间的基本区别在于，

“同步”可确保如果更改在集群的一个节点上发生，则更改将在“其他”节点上发生。
“异步”不保证在“主”节点上应用更改与将更改传播到“从”节点之间的延迟。延迟可能是短暂的，也可能是较长的–这是运气的问题。这还意味着，如果主节点崩溃，则一些最新更改可能会丢失。

理论上，同步复制比异步复制具有许多优点：

1> 它始终是高度可用的（当其中一个节点崩溃时，数据不会丢失，并且数据副本始终是一致的）
2> 事务可以在所有节点上并行执行。
3> 它可以保证整个集群的因果关系（在事务T之后发出的SELECT S将始终看到事务的效果，即使它在另一个节点上执行也是如此）

但是，实际上，同步数据库复制传统上是通过所谓的“两阶段提交”或分布式锁定来实现的，事实证明这很慢。同步复制的低性能和复杂性实施导致异步复制仍然是数据库性能可伸缩性和可用性的主要手段。广泛采用的开源数据库（例如 MySQL 或 PostgreSQL） 仅提供异

步复制解决方案。

4.基于认证的复制方法

基于认证的复制的主要思想是，假定没有冲突，事务将按常规执行直到到达提交点为止。这称为乐观执行。

实现原理：

1> 当客户端发出COMMIT命令时，但在实际提交之前，由事务和已更改行的主键对数据库所做的所有更改都将收集到一个写集中。然后，数据库将此写集发送到所有其他节点。

2> 然后，使用主键对写集进行确定性认证测试。这是在群集中的每个节点上完成的，包括源自写集的节点。它确定节点是否可以应用写集。

3> 如果认证测试失败，则节点将丢弃写集，并且群集将回滚原始事务。如果测试成功，则提交事务，并将写集应用于集群的其余部分。

许多研究人员提出了一种使用组通信和事务排序技术的同步数据库复制的替代方法（例如， 数据库状态机方法 和“ 不要懒”，“保持一致”），并且原型实现已显示出很大的希望。我们将同步数据库复制方面的经验与该领域的最新研究相结合，创建了Galera Replication Toolkit。

Galera复制是 用于应用程序集群的 高度透明和可扩展的同步复制解决方案，以实现高可用性和改进的性能。基于Galera的集群为：

高度可用
高度透明
高度可扩展（取决于应用程序，可以达到接近线性的可扩展性）

5.一些use case

1> read master

但对于Galera而言，所有“从”节点始终都是有能力的主节点，只有应用程序将它们视为从属节点。Galera复制可以确保此类安装的从站延迟为0，并且由于并行应用从站，因此群集的吞吐量要好得多。

2> 写可扩展性

在群集中分布写入将利用从属节点中的CPU功能，以更好地用于处理客户端写入事务。由于基于行的复制方法，将仅复制在客户端事务期间进行的更改，并且在从属应用程序中应用此类事务比处理原始事务要快得多。因此，群集可以在许多主节点之间分配繁重的客户端事务处理，从而总体上产生更好的写入事务吞吐量。

3> 广域网集群

同步复制可以在WAN网络上正常工作。将存在与网络往返时间（RTT）成比例的延迟，但它只会影响提交操作

4> 灾难恢复

灾难恢复是WAN复制的子类。在这里，一个数据中心是被动的，仅接收复制事件，但不处理任何客户端事务。这样的远程数据中心将始终保持最新状态，并且不会丢失任何数据。在恢复过程中，备用站点仅被指定为主站点，并且应用程序可以正常运行，故障转移延迟最小。

5> 延迟橡皮擦

借助WAN复制拓扑，群集节点可以放置在靠近客户端的位置，因此在本地节点连接下所有读写操作都将非常快。与RTT相关的延迟将仅在提交时经历，并且即使那时它也可以被最终用户普遍接受，通常，最终用户体验的杀戮在于缓慢的浏览响应时间，并且读取操作尽可能快。

二、PXC是什么

源自：https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html

PXC全称为Percona XtraDB Cluster

1. Percona XtraDB群集的功能包括：

1> 同步复制

数据同时写入所有节点，或者即使在单个节点上失败也不会写入。

2> Multi-master复制

任何节点都可以触发数据更新。

3> 真正的并行复制

从属服务器上的多个线程在行级别执行复制。

4> 自动节点配置

您只需添加一个节点，它就会自动同步。

5> 资料一致性

不再有未同步的节点。

6> PXC严格模式

避免使用实验性和不受支持的功能。

7> ProxySQL的配置脚本

Percona为ProxySQL软件包提供了proxysql-admin自动配置Percona XtraDB Cluster节点的工具。

8> 自动配置SSL加密

Percona XtraDB Cluster包含pxc-encrypt-cluster-traffic启用S​​SL加密自动配置的变量。

9> 优化性能

Percona XtraDB群集性能经过优化，可以随着不断增加的生产工作量进行扩展。

2.关于Percona XtraDB群集

集群节点，其中每个节点包含相同的一组节点同步的数据。推荐的配置是至少有3个节点，但是您也可以有2个节点。每个节点都是常规的MySQL Server实例（例如，Percona Server）。您可以将现有的MySQL Server实例转换为一个节点，并以该节点为基础运行集群。您还可以从群集中分离任何节点，并将其用作常规MySQL Server实例。

好处：

1> 执行查询时，它在本地节点上执行。所有数据都在本地可用，无需远程访问。
2> **没有中央管理。**您可以在任何时间点松开任何节点，群集将继续运行而不会丢失任何数据。
3> 扩展读取工作负载的好解决方案。您可以将读取查询放入任何节点。

缺点：

1> 设置新节点的开销。添加新节点时，它必须从一个现有节点中复制完整的数据集。如果是100GB，它将复制100GB。
2> 这不能用作有效的写扩展解决方案。当您运行到2个节点的写流量相对于所有到1个节点的写流量时，写吞吐量可能会有所改善，但是期望不高。所有写入仍必须在所有节点上进行。
3> 您有几个数据重复项，对于3个节点，您有3个重复项。

3.组件

Percona XtraDB群集基于与XtraDB存储引擎一起运行的Percona Server。它使用Galera库，该库是Codership Oy开发的写集复制（wsrep）API的实现。推荐的默认数据传输方法是通过Percona XtraBackup，其他的传输方式还有mysqldump、rsync。

4.Percona XtraDB群集限制

以下限制适用于Percona XtraDB群集：

1> 复制仅适用于InnoDB存储引擎。mysql.*不会复制对其他类型的表（包括系统（）表）的任何写操作。但是，DDL语句是在语句级别（statement）对mysql.*复制的，对表的更改将以这种方式复制。因此，您可以放心发行，但不会重复发行。您可以使用变量启用实验性MyISAM复制支持。CREATE USER…INSERT INTO mysql.user…wsrep_replicate_myisam

2> 不支持的查询：

–表锁 ：LOCK TABLES并且在多主机设置中不受支持UNLOCK TABLES
锁定功能，如GET_LOCK()，RELEASE_LOCK()等
查询日志无法定向到表。如果启用查询日志记录，则必须将日志转发到文件：log_output = FILE
使用general_log和general_log_file选择查询日志记录和日志文件名。

–允许的最大交易规模由wsrep_max_ws_rows和wsrep_max_ws_size变量定义 。 处理将每10000行提交一次。因此，由于要 进行的大笔交易将分成一系列小笔交易。LOAD DATA INFILELOAD DATA

**–由于群集级别的乐观并发控制，COMMIT在此阶段可能仍中止事务发布。**可以有两个事务写入同一行并在不同的Percona XtraDB Cluster节点中提交，而其中只有一个可以成功提交。失败的将被中止。对于集群级中止，Percona XtraDB集群返回死锁错误代码：

（错误： 1213 SQLSTATE ： 40001 （ER_LOCK_DEADLOCK ）
不支持XA事务，因为可能会在提交时回滚。

–整个群集的写入吞吐量受最弱节点的限制。如果一个节点变慢，则整个群集会变慢。如果您需要稳定的高性能，则应由相应的硬件支持。

–建议的最小群集大小为3个节点。第三节点可以是仲裁器。

–不支持InnoDB伪造更改功能。

enforce_storage_engine=InnoDB与wsrep_replicate_myisam=OFF（默认）不兼容 。

在群集模式下运行Percona XtraDB群集时，请避免工作量。如果未在所有节点上同步执行，则可能导致节点不一致。ALTER TABLE … IMPORT/EXPORT

–所有表必须具有主键。 这样可以确保相同的行以相同的顺序出现在不同的节点上。DELETE没有主键的表不支持该语句。

三、安装PXC

参考官网：https://www.percona.com/doc/percona-xtradb-cluster/LATEST/install/yum.html#yum