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

                       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太多的缺
陷，所以很少去讨论了.