MySQL集群之Galera Cluster

mysql cluster集群

Galera Cluster：集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，Galera本身是具有多主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案如下图所示：三个节点组成了一个集群，与普通的主从架构不同，它们都可以作为主节点，三个节点是对等的，称为multi-master架构，当有客户端要写入或者读取数据时，连接哪个实例都是一样的，读到的数据是相同的，写入某一个节点之后，集群自己会将新数据同步到其它节点上面，这种架构不共享任何数据，是一种高冗余架构

主要功能:

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

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

并发复制：从节点APPLY数据时，支持并行执行，更好的性能

故障切换：在出现数据库故障时，因支持多点写入，切换容易

热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小

自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致

对应用透明：集群的维护，对应用程序是透明的

缺点：

每个节点独立、异步执行会导致节点不一致性（每个节点其实是维护一个队列），为了保证各个节点的最终一致性，必须使用类tcp的滑动窗口来进行限制，实现原理如下：

整个galera cluster中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个FC_PAUSE消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，galera cluster数据同步又开始恢复

问题1导致的下一个问题是，节点中的最大的tps值取决于速度最慢的那个节点，所以各个节点的能力平衡很重要

由于galera同步复制在每个写事务提交时都增加了replicate trx和certification test的开销，因此性能远远低于异步MySQL实例（异步MySQL可以使用各种手段来提高提交tps）

Galera集群的复制功能基于Galeralibrary实现,为了让MySQL与Galera library通讯，特别针对MySQL开发了wsrep API。

Galera插件保证集群同步数据，保持数据的一致性，靠的就是可认证的复制，工作原理如下图：

当客户端发出一个commit的指令，在事务被提交之前，所有对数据库的更改都会被 write-set 收集起来,并且将write-set 纪录的内容发送给其他节点。

write-set 将在每个节点进行认证测试，测试结果决定着节点是否应用write-set更改数据。

如果认证测试失败，节点将丢弃 write-set ；如果认证测试成功，则事务提交。

（可以自动解决同时写入相同数据的冲突问题，和自动增长id问题）