MYSQL-galera多主集群

随风飞世

　　前言：网上总结的个人感觉要不太细，要不太粗，自己总结一下
　　原贴：http://blog.csdn.net/everlasting_188/article/details/51438483
传统的2pc提交同步过程

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

mysql的主从复制

http://img.blog.csdn.net/20160517191325725

　　主从复制的延时不好控制。
mysql多主复制
　　每个库上的主键ID生成要不冲突，这样主主复制才不会冲突，一般都通过应用层来控制，对开发人员来说不透明，一般采用按照节点取模来生成。
Galera replication原理
　　原理
　　1、从客户端看整体的流程

http://img.blog.csdn.net/20160517183748045

　　其中对应的角色分为2个：协调者和参与者
　　2、从存储引擎看，Galera相当于嵌入到提交事务中的一个plug模块
　　协调者：
　　1、 接收客户端请求
　　2、 广播请求到其他参与者（包括自己）
　　3、 作为参与者进行数据更新
　　4、更新失败或者成功返回给客户端
　　参与者
　　1、接收协调者的广播请求，然后进行数据库的更新
　　时序图

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