4.Galera 库与复制
Galera库是wsrep提供者，运行依赖于wsrep的API接口。Wsrep API定义了相应的回调和复制调用功能，来实现事务数据库同步写集(writeset)复制。虽然这个接口的主要目标是基于认证的多主复制，但同样适用于异步和同步的主从复制。
其通过将事务写入集合广播到集群中各个节点以进行相应的操作，Galera复制数据发生在事务提交时。
wsrep API（写集复制API）定义了Galera复制和DBMS之间的接口。
同步复制和异步复制之间的基本区别：
“同步”保证如果数据在集群中的一个节点上发生了变化，那么它们在其他节点上也同时发生。
“异步”对于在“主”节点上数据的更改将其复制到“从”节点的传播之间中有延迟的，时间是无法确定的。延迟时间可短或可长。这意味着如果主节点崩溃，一些数据的更改可能会丢失。
理论上，同步复制比异步有许多优点：
* 它总是高度可用（如果集群中一个节点崩溃，但是其他节点上的数据依然存在，因为节点互为各自的一个副本，不会造成数据丢失），可以在所有节点上并行执行事务
在实践中，同步数据库复制传统上是通过“两阶段提交”或分布式锁定实现的，这被证明是非常慢的。
同步复制的低性能和复杂性实现导致异步复制仍然是数据库性能可扩展性和可用性的主要手段。
像我们广泛采用的开源数据库如MySQL或PostgreSQL仅提供异步复制解决方案。
于是出现了基于认证的复制方法。
基于认证的复制方法
许多研究人员提出了使用组通信和事务排序技术的同步数据库复制的方法 ，
事务在单个节点中执行，然后在提交时，运行协调的认证机制来强制执行全局一致性。它通过在并发事务之间建立全局总顺序的广播服务来实现全局协调。
基于认证的复制的要求
要求数据库是事务性的。比如说，数据库可以回滚未提交的更改。
原子更改要求复制事件以原子方式更改数据库。例如，一系列数据库操作要么全部发生要么全部不发生。
全局排序要求全局排序复制事件。具体来说，它们以相同的顺序应用到所有的各集群节点。
基于认证的复制的工作原理
当客户端发出COMMIT命令实际提交发生之前，事务和更改的行的主键对数据库所做的所有更改都将被收集到写入集合中。然后，组通信将此写集合广播到所有其他节点。
然后，各节点使用主键进行确定性认证测试。此认证在集群中的每个节点上完成，包括发起写集的节点，用于确定节点是否可以应用写入集。
如果认证失败，则节点丢弃写入集群，并且集群回滚原始事务。如果认证成功，则事务提交，写入集合将应用到集群的各节点上。
Galera Cluster中基于认证复制的实现取决于交易的全局排序。
Galera Cluster在复制期间为每个事务分配全局序数序列号。当事务到达提交点时，节点将检查序列号与上一次成功事务的顺序号。
检查此时间间隔内的所有事务与所涉事务的主要冲突。如果检测到冲突，则认证失败。
该过程是确定的，而且所有的副本以相同的顺序接收数据。因此，所有节点都对交易结果达成相同的决定。
基于此产生了Galera复制工具包，Galera主要应用于集群，以实现高可用性和改进的性能。
Galera复制库
Galera复制功能为共享库，可以与实现了wsrep API钩子(这里介绍的Percona XtraDB数据库即实现了该接口)的任何事务处理系统进行通信。
Galera是提供用于复制和应用事务写入集的功能的复制库。
Galera提供 wsrep Api，复制等一系列功能。
Galera内部架构围绕四个部分组成：
数据库管理系统（DBMS）在各个节点上运行的数据库服务器。
wsrep API 为数据库服务器和复制操作提供程序的接口，包括：
wsrep hooks与数据库服务器引擎集成在一起,其实现了wsrep API钩子函数
，dlopen，为Galera提供程序可用于wsrep钩子函数。Galera复制插件启用认证，写入复制集功能的插件。
gcomm和spread为组通信插件，用于向集群各节点发送广播通信。
在数据库集群中，各个节点总是具有相同的状态。它们通过以相同的串行顺序复制和应用状态更改来相互同步。
从技术的角度来看，Galera Cluster在以下过程中处理状态更改：
在集群中的一个节点上数据库发生状态更改。
在数据库中，wsrep hook将更改转换为write-set。
dlopen，可用于galera 复制的钩子。
Galera Replication插件处理对集群的写入认证和复制。
对于集群中的每个节点，应用程序进程由高优先级事务发生。
参考：
http://galeracluster.com/documentation-webpages/architecture.html