Galera Cluster 架构
三个MySQL实例是对等的，互为主从，这被称为多主（multi-master）架构
MariaDB Galera 集群是 MariaDB 的一个实际上同步的多主集群。它只能在 Linux 上使用，并且只支持 InnoDB 存储引擎, 由wsrep插件和MariaDB server组成
当客户端读写数据时，可连接任一MySQL实例
- 对于读操作，从每个节点读取到的数据都是相同的。
- 对于写操作，当数据写入某一节点后，集群会将其同步到其它节点。
- 这种架构不共享任何数据，是一种高冗余架构
特性
- 多主架构：真正的多主多活群集，可随时对任何节点进行读写。
- 同步复制：集群不同节点之间数据同步，某节点崩溃时没有数据丢失
- 数据一致：所有节点保持相同状态，节点之间无数据分歧
- 并行复制：重放支持多线程并行执行以获得更好的性能。
- 自动控制，故障节点从集群中删除
- 自动节点连接
- 在行级别上进行真正的并行复制
Galera复制
同步复制 VS 异步复制
"同步"复制保证，如果在集群中的一个节点上发生了更改，那么更改将"同步"或同时发生在集群中的其他节点上
- 同步复制协议通常使用两阶段提交或分布式锁协调不同节点的操作 会存在性能的问题
"异步"复制不能保证在"主"节点上应用更改和将更改传播到"从"节点之间的延迟。
- 如果主节点在"异步"复制拓扑中崩溃，那么可能会丢失一些最新的更改
Galera复制
- 组通信（Group Communication）：定义了数据库节点间的通信模式，保证复制数据的一致性
- 写集（Write-sets）：将多个并发数据库写操作更新的数据，绑定到单个写集消息中，提高节点并行性
- 数据库状态机：数据库站点本地处理只读事务。更新事务首先在本地的"影子拷贝（shallow copies）"上执行，然后作为读集广播到其它数据库站点进行验证并提交
- 事务重排序：此操作在数据库提交事务并将其广播到其它站点之前重新排序事务，增加成功通过验证的事务数
同步复制比异步复制有许多优点
- 利用同步复制的集群始终是高可用的。如果其中一个节点崩溃了，那么就不会有数据丢失。此外，所有集群节点始终保持一致
- 利用同步复制的集群允许在所有节点上并行执行事务
同步 异步 半同步复制?
内部架构
Galera集群的内部架构包含四个组件:
- 数据库管理系统（DBMS）：在单个节点上运行的数据库服务器。Galera群集可以使用MySQL、Mariadb或Percona xtradb
- wsrep api：Galera与数据库服务器的接口，为上层提供了丰富的状态信息和回调函数。
- wsrep api由wsrep hooks、dlopen函数两部分组成。
- wsrep hooks钩子程序用于与数据库服务器引擎集成。
- dlopen函数使Galera插件中的复制程序对wsrep hooks可用
- Galera复制插件：实现写集复制功能的核心模块
- 组通信插件：Galera集群的组通信系统（Group Communication System，GCS），如GComm
wsrep api
wsrep api是数据库的通用复制插件接口，定义了一组应用程序回调和复制插件调用函数
工作流:
- 一个节点的数据库中发生状态更改。
- wsrep钩子将更改转换为写集。
- dlopen函数连接wsrep钩子与Galera复制插件。
- Galera复制插件处理写集验证，并将更改复制到集群中的其它节点
Generic Replication Library
Galera 复制功能是作为一个共享库实现的
Generic Replication Library 是一个协议栈，提供准备、复制和应用事务写集的功能
- wsrep API DBMS和复制提供程序的职责
- wsrep hooks
- replication 复制管理复制协议并提供总排序功能
- GCS framework GCS 框架为组通信系统提供了插件体系结构
全局事务ID（global transaction id，GTID）
-
MySQL社区中，GTID的概念并不新鲜，MySQL中的GTID由Master生成，是用于标记唯一事务并通过ID定位binlog位置的一种手段，从而有效解决了级联复制等场景中的各种问题。
-
对Galera Cluster而言，复制不基于binlog，而是通过Galera复制插件来保障。Galera的GTID同样也标记事务唯一性，wsrep api使用GTID识别状态更改
Galera Slave Threads
写集 write set被放置在节点上集群节点的接收队列中，最终由集群节点的 Galera Slave Threads 去应用
当一个集群节点的状态(如 wsrep_local_state_comments 所示)为 JOINED 时，增加从线程的数量可能有助于集群节点更快地赶上集群。
在这种情况下，将线程的数量设置为系统上 CPU 数量的两倍可能是有用的。
Streaming Replication 流式复制
使用 Streaming 复制，节点将巨大的事务分解成更小、更易于管理的片段，然后在工作时将这些片段复制到集群中，而不是等待提交。
一旦经过认证，片段就不能再被冲突的事务中止。
由于这可能在执行期间和回滚事件中都会产生性能影响，因此建议您只在不太可能发生冲突的大型事务中使用它
Group Commits 组提交
## Galera复制工作原理
基于 验证的复制 使用 组通信 和 事务排序技术 实现同步复制
事务在本节点乐观执行，然后在提交时运行一个验证过程以保证全局数据一致性
- 事务在一个节点提交时，被认为与其它节点上的事务没有冲突，首先在本地执行，
- 然后再发送到所有节点做冲突检测，无冲突时在所有节点提交，否则在所有节点回滚