galera cluster

galera cluster是基于同步复制的多master集群，能保证数据不丢失并。
特点：
1同步复制
2多master
3在集群任意的节点上读写
4自动成员控制，失败节点的剔除
5自动节点添加
6在行级别的并行复制
7没有slave延迟
8不丢事务
9读写扩展能力
10很少的客户端延时

galera的复制是发生在事务提交的时候通过广播事务写集合到cluster去应用。
通常异步复制的实现方式是2阶段提交，或分布式锁，这种情况下都是比较慢的。
galera的复制使用的是组通讯和事务排序的技术，是基于认证的复制
复制是使用了galera 复制插件去管理的。write-set，不仅仅包含了复制的行，也包含了事务中所有的锁信息。在应用队列中，每个节点都会去确认复制的write-set,在没有冲突的情况下才会去应用。这个方法是虚拟的同步复制，实际的写入提交的发生是独立的。基于认证的复制需要下面的条件：
1事务数据库2原子改变3全局排序

节点的失败检测也是跟别的数据库一样的方式，通过集群投票，集群的大部分节点认为这个节点不可达，那么这个节点就是故障节点。
是通过接收网络包去判断是否存活的。
这个跟mysql5.7上的组复制方式一样。galera cluster使用一个成为流量控制的反馈机制来管理复制进程，流量控制能让节点按需暂停，开启复制，这样就使得节点在复制上不会落后别的节点太多。
节点接收write-set并全局排序，节点在集群上接收到的事务，如果没有被使用，那么会放在接收队列中，当接收队列达到了指定的大小，会触发流量控制，节点会停止复制，解决接收队里，当大小在一个可管理的大小后，节点恢复复制。
主要有4中流量控制方式：
1no flow control
当节点在open或primary状态下，no flow control会生效，在这种状态下不会被认为是集群的一部分，这些节点不会被允许复制，应用或缓存write-set.

2write-set缓存
当节点的状态是joiner或donor的状态时，这个控制策略生效。
这个状态下的节点不能应用write-set，必须缓存他们

3catching up
当节点在joined状态下时候生效。这个状态下的节点可以应用write-set,会确保write-set缓存不会增长。

4cluster sync
节点在synced状态时，这个类型会生效。这个状态下的节点，流量控制会保持从库的队列最小化。
节点状态的改变

The node starts and establishes a connection to the Primary Component.

When the node succeeds with a state transfer request, it begins to cache write-sets.

The node receives a State Snapshot Transfer. It now has all cluster data and begins to apply the cached write-sets.

Here the node enables Flow Control to ensure an eventual decrease in the slave queue.

The node finishes catching up with the cluster. Its slave queue is now empty and it enables Flow Control to keep it empty.

The node sets the MySQL status variable wsrep_ready to the value 1. The node is now allowed to process transactions.

The node receives a state transfer request. Flow Control relaxes to DONOR. The node caches all write-sets it cannot apply.

The node completes the state transfer to joiner node.