Extend RAC对基础设施要求较高,在发生存储抖动的时候会影响双中心的应用服务,而存储抖动发生概率较高。我行目前是通过ADG做了读写分离,分担主库60%的查询交易,数据是三中心6副本。ADG同城双机房的延时是小于1秒,app自动检测到ADG数据延时较大时可以在1秒内完成只读回切读写库。
未来发展我们是预研Oceanbase和TiDB,真正的分布式数据库才是解决分布式核心的发展方向。
extend rac成本高,环境条件要求苛刻,并且需要存储双活配合,但这是真正意义上的数据库双活。
rac + adg严格意义不是双活是高可用容灾,adg端实现写操作还需人工干预,好处是成本低一点,只读操作就算是鸡肋也能有点用。
Oracle Extend RAC 是RAC的距离延伸,其优势在于常规的多节点A-A模式运行。oracle RAC+ADG按字面理解应该是本地RAC,远端ADG,那么常规情况下,远端能做到只读。但Oracle Extend RAC这种架构对延迟的高要求,其距离小于100公里,因此能够覆盖机房/建筑级别的灾害,但对于地区级(超过100公里)、逻辑级的灾害,例如地震/洪灾/人为误操作造成的灾害则无法覆盖。官方给出的文档描述如下:
Disasters such as earthquakes, hurricanes, and regional floods may affect a greater area. Oracle RAC on Extended Distance Clusters does not rotect from human errors or corruptions in the shared storage, either, as an Oracle RAC system,even on Extended Distance Clusters,is still a tightly coupled and enclosed system. For comprehensive data protection, including protection against corruptions and regional disasters, Oracle recommends using Oracle Data Guard together with Oracle RAC as building blocks of Oracle’s Maximum Availability Architecture(MAA)
ORACLE RAC+ADG不能实现RTO=0,也就不是真正的双活。Oracle Extend RAC属于真正的双活,但实现方式复杂,不管是建设、还是后期运维,都会比较复杂。从另一个方面看,实现真正的双活,除了关注RTO是否等于0这个硬指标外,还应该关注性能问题,怎么让EXADATA RAC既实现RTO=0,又能让数据跨越几十公里后仍然能支持大并发和一定的吞吐,这是个难点。
收起