关于Oracle的rac集群和mysql Galera Cluster的想法

时间:2022-09-19 19:42:00

到了新公司,公司用的是rac,我比较熟悉mysql第三方的集群方案Galera Cluster这类多主集群,

下面是我参考了他人对rac的介绍,然后和mysql方案进行的臆测级别的分析对比。

rac和mysql Galera Cluster(mgc)的对比,

1、实施和运维,rac是商业方案系统化性当然强点,mgc大多使用各种开源高可用负载均衡器,部署起来对实施人员的要求rac比较低,废话。。。rmb都给了甲骨文了,如果是自行配制弄得不好性能2台还不如一台,其实运维方面来说体量大了都一样;

2、相通性,都是多点事务方案,事务可以在事务节点集群中的任何一个开始,理论上将中间失败也可以自动去另一个节点继续,提交事务是到每台节点上同步,看有没有一个节点上因为锁出现不能提交,那样就事务回滚了,

3、不同性,rac事务节点集群跟数据节点集群分离,数据默认并不冗余,只有事务在运行状态下在事务节点冗余,当然有的时候都在一台机器上,但是至少是不同进程,而包mysql在内的其他主流sqldb的事务、数据似乎都在一起,是真正的多主,冗余量高,而rac应该算事务节点冗余,数据不冗余,如果不从底层数据节点做游离于rac架构之外的底层数据节点冗余,那么rac怎么都不可能比同样节点数量的单机甲骨文实例要性能高,

这样产生的优缺点:

1、rac的数据节点当然首先节省硬盘空间,理论上可以针对库、表、表分区级别进行选择物理不同的数据节点、硬盘进行冗余进行底层冗余,不像mgc要么都冗余,要么都不冗余

2、mysql每个节点 同时是适合写和读的,所以mgc的多主不仅提高了事务的并发能力,更同时增加了不上读锁的数据的读取并发能力,这点远超rac

3、rac本身虽然是高可用方案,故障转移方案,有很高的运维上的可用性要求,层次过多,运维要求很高,当然你可以全交给dba和甲骨文付费服务,自己弄要求非常高,这方面mysql的因为层次少些相对容易运维,当然前提是你的运维人员本来就对mysql集群方案玩的很溜,否则你如果是个产品经理或者项目经理只能觉得mysql不好搞

4、mgc同时抱有对读写、事务的性能提升,并且直接是高可用的,结构简单,单点问题比rac,因为层次少了,所以应该会少,

5、rac得益于甲骨文的天生特效,更适合统计类、bi类,这方面mysql没辙,比不了

6、mgc适合主热数据的读写,不太适合做复杂的关联查询,应该比较适宜业务偏简单的互联网应用

 

本质上,很多人用甲骨文的原因仅仅是不敢把宝押在开源和名声稍有问题的mysql上。企业应用用甲骨文 实在多少有点冤大头 哈哈哈

互联网就该考虑mysql,如果要兼容并联查询能力 实施pgsql吧