mysq集群原理之Galera replication

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

传统的2pc提交同步过程

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

mysql的主从复制

mysq集群原理之Galera replication_第1张图片
主从复制的延时不好控制。

mysql多主复制

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

Galera replication原理

原理
1、从客户端看整体的流程
mysq集群原理之Galera replication_第2张图片
其中对应的角色分为2个:协调者和参与者
2、从存储引擎看,Galera相当于嵌入到提交事务中的一个plug模块

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

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

时序图
mysq集群原理之Galera replication_第3张图片

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

你可能感兴趣的:(mysql,通信,事务)