mysq集群原理之Galera replication

比眉伴天荒 2022-07-24 08:06 185阅读 0赞

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

# 传统的2pc提交同步过程 #

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

# mysql的主从复制 #

![主从复制结构][20160517191325725]  
主从复制的延时不好控制。

# mysql多主复制 #

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

# Galera replication原理 #

**原理**  
1、从客户端看整体的流程  
![同步基本原理][20160517183748045]  
其中对应的角色分为2个：协调者和参与者  
2、从存储引擎看，Galera相当于嵌入到提交事务中的一个plug模块

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

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

**时序图**  
![同步时序图][20160517184903521]

**关键技术**  
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是一个高可用的方案，在牺牲性能的情况下，适合于关键业务。实际上关于在提交和交互的过程中，异常部分处理还是需要深入研究的，需要参考对应论文来说明（待续）

[20160517191325725]: /images/20220722/0c849c7e662b44c8b82d2f535297337d.png
[20160517183748045]: /images/20220722/81c9f902e98a4ec2a7a608cdda256d24.png
[20160517184903521]: /images/20220722/a1ca3e7add9f4622ab3e8ed6b52829d0.png