MySQL高可用――PXC解说

2024-07-24 12:31:30

字体：大中小

来源：转载

供稿：网友

galera产品是以galera cluster方式为mysql提高高可用集群解决方案的。galera cluster就是集成了galera插件的mysql集群。galera replication是codership提供的mysql数据同步方案，具有高可用性，方便扩展，并且可以实现多个mysql节点间的数据同步复制与读写，可保障数据库的服务高可用及数据强一致性。

要搭建PXC架构至少需要3个mysql实例来组成一个集群，三个实例之间不是主从模式，而是各自为主，所以三者是对等关系，不分从属，这就叫multi-master架构。客户端写入和读取数据时，连接哪个实例都是一样的。读取到的数据时相同的，写入任意一个实例之后，集群自己会将新写入的数据同步到其他实例上，这种架构不共享任何数据，是一种高冗余架构。

--：galera cluster的功能有7点，如下：

①：多主架构：真正的多点读写集群，在任何时候读写的数据都是最新的；

②：同步复制：集群不同节点之间的数据同步，没有延迟，在数据库挂掉之后，数据不会丢失；

③：对应用透明：集群的维护，对应用程序是透明的，几乎感觉不到；

首先客户端先发起一个事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。在提交之前需要将产生的复制写集广播出去，然后获取到一个全局的事务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的工作模式：

  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_replay_trx：

   这个接口的作用及使用，就是在验证过程中，由于数据库锁的冲突，当前操作被其他线程自治县了galera_abort_pre_com_mit，导致当前线程被强制中止，但是由于写集已经复制到其他节点，所以本节点这个事务必须要完成。通过这个接口，将这个事务的写集做一次apply，所以就叫replay；

---galera_append_key：

   这个接口就是所谓的galera验证，被验证的对象实际上就是写集，而构成写集的内容，其实就是通过这个接口来完成的；

---galera_append_data：

   这个接口是当前事务所生成的binlog内容，也就是说key在验证通过之后，使用data在从节点执行，即可做到数据同步。