共计 4616 个字符，预计需要花费 12 分钟才能阅读完成。
PXC 简介：
galera 产品是以 galera cluster 方式为 MySQL 提高高可用集群解决方案的。galera cluster 就是集成了 galera 插件的 mysql 集群。galera replication 是 codership 提供的 mysql 数据同步方案，具有高可用性，方便扩展，并且可以实现多个 mysql 节点间的数据同步复制与读写，可保障数据库的服务高可用及数据强一致性。
PXC 属于一套近乎完美的 mysql 高可用集群解决方案，相比那些比较传统的基于主从复制模式的集群架构 MHA 和 MM+keepalived，galera cluster 最突出特点就是解决了诟病已久的数据复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，他们相互的关系是对等的。本身 galera cluster 也是一种多主架构。galera cluster 最关注的是数据的一致性，对待事物的行为时，要么在所有节点上执行，要么都不执行，它的实现机制决定了它对待一致性的行为非常严格，这也能非常完美的保证 MySQL 集群的数据一致性；
对 galera cluster 的封装有两个，虽然名称不同，但实质都是一样的，使用的都是 galera cluster。一个 MySQL 的创始人在自己全新的 MariaDB 上实现的 MAriaDB cluster；一个是著名的 MySQL 服务和工具提供商 percona 实现的 percona xtradb cluster，简称 PXC
要搭建 PXC 架构至少需要 3 个 mysql 实例来组成一个集群，三个实例之间不是主从模式，而是各自为主，所以三者是对等关系，不分从属，这就叫 multi-master 架构。客户端写入和读取数据时，连接哪个实例都是一样的。读取到的数据时相同的，写入任意一个实例之后，集群自己会将新写入的数据同步到其他实例上，这种架构不共享任何数据，是一种高冗余架构。
–：galera cluster 的功能有 7 点，如下：
①：多主架构：真正的多点读写集群，在任何时候读写的数据都是最新的；
②：同步复制：集群不同节点之间的数据同步，没有延迟，在数据库挂掉之后，数据不会丢失；
③：并发复制：从节点在 apply 数据时，支持并行执行，有更好的性能表现
④：故障切换：因为支持多点写入，所以在出现数据库故障时可以很容易的进行故障切换
⑤：热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少，在节点故障期间，节点本身对集群的影响非常小；
⑥：自动节点克隆：在新增节点或停机维护时，增量数据或基础数据不需要人工手动备份提供，galera cluster 会自动拉取在线节点数据，集群最终会变为一致；
⑦：对应用透明：集群的维护，对应用程序是透明的，几乎感觉不到；
–PXC 原理：
PXC 最常使用以下 4 个端口号：
3306- 数据库对外服务的端口号。
4444- 请求 SST 的端口（SST 是指数据库一个备份全量文件的传输。）
4567- 组成员之间进行沟通的一个端口号
4568- 用于传输 IST（相对于 SST 来说的一个增量）
PXC 的操作流程：
首先客户端先发起一个事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。在提交之前需要将产生的复制写集广播出去，然后获取到一个全局的事务 ID 号，一并传送到另一个节点上面。通过合并数据之后，发现没有冲突数据，执行 apply_cd 和 commit_cb 动作，否则就需要取消此次事务的操作。而当前 server 节点通过验证之后，执行提交操作，并返回 OK，如果验证没通过，则执行回滚。当然在生产中至少要有 3 个节点的集群环境，如果其中一个节点没有验证通过，出现了数据冲突，那么此时采取的方式就是讲出现不一致的节点踢出集群环境，而且它自己会执行 shutdown 命令，自动关机。
PXC 的优点：
①：实现 mysql 数据库集群架构的高可用性和数据的 强一致性。
②：完成了真正的多节点读写的集群方案。
③：改善了传统意义上的主从复制延迟问题，基本上达到了实时同步。
④：新加入的节点可以自动部署，无须提供手动备份，维护起来很方便。
⑤：由于是多节点写入，所以数据库故障切换很容易。
PXC 的缺点：
①：新加入的节点开销大，需要复制完整的数据。采用 SST 传输开销太大。
②：任何更新事务都需要全局验证通过，才会在每个节点库上执行。集群性能受限于性能最差的节点，也就是经常说的短板效应。
③：因为需要保证数据的一致性，所以在多节点并发写时，锁冲突问题比较严重。
④：存在写扩大问题，所有的节点上都会发生些操作。
⑤：只支持 innodb 存储引擎的表。
⑥：没有表级别的锁定，执行 DDL 语句操作会把整个集群锁住，而且也 kill 不了（建议使用 Osc 操作，即在线 DDL）
⑦：所有的表必须含有主键，不然操作数据时会报错。
PXC 搭建的注意点：
首先要规范集群中节点的数量，整个集群中节点数控制在最少 3 个、最多 8 个范围内。最少 3 个节点是为了防止出现脑裂现象，因为只有在两个节点下才会出现此现象。脑裂现象的标志就是输入任何命令、返回结果都是 unkown command，节点在集群中，会因为新节点的加入或者故障，同步失效等而发生状态的切换。
– 节点状态变化阶段：
open：节点启动成功，尝试连接到集群。
primary：节点已处于集群中，在新节点加入时，选取 donor 进行数据同步时会产生的状态。
joiner：节点处于等待接收同步文件时的状态。
joined：节点完成数据同步的工作，尝试保持和集群进度一致。
synced：节点正常提供服务的状态，表示已经同步完成并和集群进度保持一致。
doner：节点处于为新加入的节点提供全量数据时的状态。
注意：doner 节点就是数据的贡献者，如果一个新节点加入集群，此时又需要大量数据的 SST 传输，就有可能因此而拖垮整个集群的性能。所以在生产环境中，如果数据量小，还可以使用 SST 全量传输，但如果数据量很大就不建议使用这种方式了。可以考虑先建立主从关系，在加入集群。
PXC 有两种节点的数据传输方式：一种叫 SST 全量传输，另一种叫 IST 增量传输。
SST 传输有：xtrabackup、mysqldump 和 rsync 三种方法。而增量传输就一种方法就是 xtrabackup。但生产环境中一般数据量不大的时候，可以使用 SST 全量传输，但也只实现 xtrabackup 方法。
在 PXC 中还有一个特别重要的模块就是 GCache。它的核心功能就是每个节点缓存当前最新的写集。如果有新节点加入进来，就可以把新数据的增量传递给新节点，而不需要再使用 SST 方式了。这样可以让节点更快地加入集群中。涉及参数如下：
gcache.size：代表用来缓存写集增量信息的大小。它的默认大小是 128MB，通过 wsrep_provider_options 参数设置。建议调整为 2GB-4GB 范围，足够的空间便于缓存更多的增量信息。
gcache.mem_size：代表 gcache 中内存缓存的大小，适度调大可以提高整个集群的性能。
gcache.page_size：可以理解为如果内存不够用（gcache 不足），就直接将写集写入磁盘文件中。
–：PXC 的工作模式：
galera 的工作模式是——某个节点写入一个事务，它会广播到其他节点，而这个所谓的其他节点，也包括自己。也就说自己发出来的事务，自己也会收到，只是在收到并产生 GTID 之后，就被简单忽略了，而不会再去 apply 一次。
–：galera 的并发控制机制：
并发控制主要是在接口 galera_pre_commit 中完成的，这个接口是 galera 最重要的接口之一，这里面实现了最重要的复制、验证逻辑。目前，这个接口中包括的并发控制有以下几点：
①：数据复制：
目前的 galera 版本中，写集数据的发送是通过 asio 的异步方式将数据广播出去。这个发送是串行的，是一个临界区，因为在每次 发送前，逻辑上还需要分片，并且每次发送完成之后，需要等待一个 GTID 的值，所以为了保证数据的一致性，这个发送操作需要串行；
②：写集验证：
要求所有进入处理区的 GTID 必须是顺序的，因为 GTID 是顺序产生的，所以在顺序的基础上，同一时间必须只有一个事务可以进行处理，说白了就是串行；
受这种层次并发控制管理的操作主要有验证操作，因此说验证是串行的；
③：写集 apply
④：事务 commit
这个层次的并发控制机制，默认是 3，建议也是 3，就是串行提交，这样就保证了不管在主库还是从库，所有的节点产生的 binlog 都是完全相同的；
3、galera 接口：
—galera_init：
这个接口的作用是初始化一个 galera 节点，这是一个 PXC 节点调用的第一个 wsrep 接口，在启动服务器的时候初始化，将所有需要的参数和环境变量初始化。（如：集群名字，实例地址、需要这个接口做 binlog 的复制等）
—galera_connect：
这个接口是第二个调用的接口。这个接口的作用是将当前节点加入集群中。加入集群前会调用函数 wsrep_view_handler_cb 来判断新加入节点与集群的数据是否同步；
—galera_recv：
这个接口的作用是，在这个函数里阻塞式的接收其他节点及本节点发送的数据，并且调用复制 apply 函数执行复制操作。（这个接口实际上是可以并行存在的。它对应的是参数 wsrep_slave_threads 有多少个线程，就有多少个 galera_recv 的调用）
—galera_pre_commit：
这个接口是 galera 最重要的接口之一。它的作用包括两部分，首先是将当前指定的事务写集广播给整个集群节点，然后就是验证，如果验证成功，则将处理权交给上层，继续做数据库事务的提交操作；这个接口是在数据库事务提交时调用的，调用这个接口时，必须是本地事务已经执行完成；
—galera_replay_trx：
这个接口的作用及使用，就是在验证过程中，由于数据库锁的冲突，当前操作被其他线程自治县了 galera_abort_pre_com_mit，导致当前线程被强制中止，但是由于写集已经复制到其他节点，所以本节点这个事务必须要完成。通过这个接口，将这个事务的写集做一次 apply，所以就叫 replay；
—galera_append_key：
这个接口就是所谓的 galera 验证，被验证的对象实际上就是写集，而构成写集的内容，其实就是通过这个接口来完成的；
—galera_append_data：
这个接口是当前事务所生成的 binlog 内容，也就是说 key 在验证通过之后，使用 data 在从节点执行，即可做到数据同步；
—galera_post_commit：
这个接口是用来真正提交事务的。这个接口包括 4 个功能：更新状态参数 wsrep_last_committed 的值，表示当前事务已经真正提交了；更新参数 wsrep_local_commits 的值，表示本地又成功提交了一个事务；检查当前验证写集缓冲区是不是可以做 purge 操作；
—galera_to_execute_start:
这个接口专门用来处理 DDL 语句的执行；
—galera_to_execute_end：
这个接口实际上和 galera_post_commit 功能一样，成对出现，是为处理不同语句而设置的，主要就是为了从 commit 临界区中出来，从而让其他事务继续提交；
：
