mysq集群原理之Galera replication

前言：网上总结的个人感觉要不太细，要不太粗，自己总结一下

传统的2pc提交同步过程

1. 2PC 事务结束时，所有节点数据达到一致
2. 协调者与参与者之间通信，参与者之间无连接
3. 受网络状态影响较大
4. 两次通信，需要得到每个参与者的反馈后才能决定是否提交事务

mysql的主从复制

主从复制的延时不好控制。

mysql多主复制

  每个库上的主键ID生成要不冲突，这样主主复制才不会冲突，一般都通过应用层来控制，对开发人员来说不透明，一般采用按照节点取模来生成。

Galera replication原理

原理
1、从客户端看整体的流程

其中对应的角色分为2个：协调者和参与者
2、从存储引擎看，Galera相当于嵌入到提交事务中的一个plug模块

协调者：
1、 接收客户端请求
2、 广播请求到其他参与者（包括自己）
3、 作为参与者进行数据更新
4、更新失败或者成功返回给客户端

参与者
1、接收协调者的广播请求，然后进行数据库的更新

时序图

关键技术
1、全局唯一ID生成，保证ID的唯一和递增
2、协调者自己也是通过广播接收后进行的数据库业务操作，各个节点平等，保证了并发
3、事务传输要么成功传给了所有节点，要么都失败
4、事务在所有节点中的顺序一致
5、每个节点知道所有节点的状态（通过广播实现)

优点
1. 同步复制，主备无延迟
2. 支持多主同时读写，保证数据一致性
3. 集群中各节点保存全量数据
4. 节点添加/删除，自动检测和配置
5. 行级别并行复制
6. 不需要写binlog

缺点
1、每个节点独立、异步执行会导致节点不一致性（每个节点其实是维护一个队列），为了保证各个节点的最终一致性，必须使用类tcp的滑动窗口来进行限制，实现原理如下：
  整个galera cluster中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个FC_PAUSE消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，galera cluster数据同步又开始恢复
2、问题1导致的下一个问题是，节点中的最大的tps值取决于速度最慢的那个节点，所以各个节点的能力平衡很重要
3、由于galera同步复制在每个写事务提交时都增加了replicate trx和certification test的开销，因此性能远远低于异步MySQL实例（异步MySQL可以使用各种手段来提高提交tps）

总结
  Galera replication for MySQL是一个高可用的方案，在牺牲性能的情况下，适合于关键业务。实际上关于在提交和交互的过程中，异常部分处理还是需要深入研究的，需要参考对应论文来说明（待续）