Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2758249
  • 博文数量: 389
  • 博客积分: 4177
  • 博客等级: 上校
  • 技术积分: 4773
  • 用 户 组: 普通用户
  • 注册时间: 2008-11-16 23:29
文章分类

全部博文(389)

分类: Mysql/postgreSQL

2014-11-24 12:27:07

                       MySQL Galera集群和ORACLE RAC的实现原理比较

  

    MySQL Galera(以下简称MG)是通shared nothing结构,整个cluster中每个节点都有一个单独的数据拷贝.而
RAC是shared everything的结构,集群中所有的结点共享一份数据.

   对于MG中的一条数据修改,必须要有一定的手段传播到其他的节点上,这个过程通过分发binlog来实现.而RAC是
只有一份数据,所以不需要对修改的数据传播到其他节点的开销.


  MG采用了两阶段提交协议,在一个节点上对事务进行提交之前,需要在其他的节点进行相应的提交请交,等
到其他节点上都准备好了以后,再开始提交.而RAC没有这种开销或是开销极少。因此事务响应的时候受网络或
其他节点的影响较大.

  对IO的开销,我们知道MG是通过同步复制实现集群的数据一致性,假设一个事务写一次磁盘操作,集群中有三个
节点,而每一次提交一个事务都会在每个节点上产生一次IO操作,整个集群的IO开销是3次,而在RAC中,只需要1次
IO操作就可以了。这也是造成MG的开销很大的基本原因。使MG的集群并不能很好的进行写扩展,同时也使整个MG的
性能受到最差配置的节点的影响.


    因此我更愿意把MG看作是一种高可用性的方案,比如某系统对高可用性要求非常高,这时候做两个到三节点的
集群,平常只在一个节点上写入,而其他的节点做成只读查询.前端通过haproxy或是lvs转发,当一个节点挂点后,另一个节点
可以实现无缝使用.而不会有MHA+mysql异步复制带来的可能数据丢失的问题.但是当一个节点写入,同时还要写到其他
的节点上,而其他的节点上还需要进行只读查询,可能影响对来自写节点提交确认的响应,不过我们可以通过使用SSD之类的方案
来减少响应的时间.

   Mysql cluster的基本实现原理和MG也很类似,但是只支持ndb,而不像MG一样只支持innodb,考虑到ndb太多的缺
陷,所以很少去讨论了.

阅读(5932) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~