数据库高可用架构的尽头是RAC吗?

前阵子和几个国产数据库厂商的朋友谈到高可用架构的时候，有朋友说数据库高可用架构的尽头是RAC，今后所有的国产集中式数据库必须做RAC功能。我问说这话的朋友，你认为的高可用尽头的RAC，看中了哪方面的能力呢？他说某个节点故障，另外一个节点照样跑，应用可以快速通过TAF切换到活着的节点，在业务完全不中断、数据0丢失下实现高可用切换，基本上就能够满足用户的需求了。

干了三十多年IT，亲眼目睹了IT技术发展的滚滚洪流，我已经对顶峰、尽头之类的词免疫了。未来如何，我是没有能力去感知的，我只了解历史和现状。能够把现状搞明白七八成已经是十分高的认知程度了。如果RAC这个诞生于上世纪90年代的数据库高可用架构就已经是数据库高可用架构的尽头了，这三十年来，数据库从业者都白活了。

事实上，那个朋友说的Oracle RAC的故障切换技术是快30年前的技术了，而这些年中，Oracle在高可用技术方面的技术进步可能已经完全超出了那位朋友的想象了。这些年Oracle 的业务连续性解决方案已经从TAF发展到了FCF(快速连接故障切换），FCF把TAF的分钟级故障切换缩短到亚秒级，这个技术是Oracle 10g开始支持的，至今已经21年多了。十年前我在对某个行业的Oracle用户调研的时候，几乎100%的用户还在使用TAF，压根儿不知道还有FCF这个技术。这说明TAF对他们来说已经够用了，实际上他们的系统并无更高高可用的需求。

2013年的12C，Oracle又推出了GDS和应用连续性解决方案AC。不仅把高可用切换扩展到了Oracle RAC之外的GoldenGate和ADG环境，还提出了一个故障切换应用不失败的解决方案。在2018年的18C中，AC又升级到TAC，让应用连续性方案变得对应用更加透明。在随后的19C中，TAC方案扩展到了ADG。

实际上信息化这几十年来，人们对系统高可用的需求是不断提升的。随着数据存储与数据处理越来越集中，系统故障所带来的的负面影响就越来越大，于是关键业务系统对数据库系统高可用的需求就越来越高了。实际上业务连续性的数据库解决方案的发展目前还是没有看到尽头了。只是目前国产数据库在这方面与最先进的技术之间还存在好几代的代差。

数据库业务连续性解决方案的技术发展方向是对应用越来越透明，对应用影响越来越小。Oracle对业务连续性的解决方案已经发展到了全局数据服务GDS，RAC只是其中的一个环节了。不过大多数国产数据库厂商还是没有看到这个技术趋势，还把实现RAC作为自己追求的终极目标，这个技术思路可能不一定是正确的。

共享存储多读多写数据库要想达到Oracle RAC水平相当困难，这不仅仅是投入研发经费的问题，底层存储架构如果没有优化好，哪怕做出了类似RAC的功能，在性能、故障切换的FREEZE时间等技术参数上与Oracle都会有相当大的差距，而且因为存储引擎的缺陷，这个差距是无法缩小的，这一点我不知道有多少数据库从业者认可。我交流过的国产数据库厂商中，好像只有一家和我持相同的观点。

RAC只是实现较高的业务连续性的一种技术方案，并不是全部。GDS才是目前业务连续性解决方案中相对前沿的技术方案。我建议需要给用户提供更高业务连续性解决方案的厂商去研究一下。对于国产数据库厂商，我有一个十分不解的问题就是，似乎他们的产品经理都不去研究Oracle这个目前数据库中的遥遥领先者。周日和大学生朋友交流的时候，南科大的一位同学问我融合数据库需要具备哪些能力。我说一两句话说不清楚，你去下载一套Oracle 23ai研究一下，我觉得目前能力最强的融合数据库就是这个，这也代表了融合数据库的技术发展方向。

回到应用连续性和高可用的话题。数据库的高可用技术是为应用服务的，用户对此的要求是越透明越好，对应用影响越小越好，使用成本越低越好。技术上限会随着软硬件技术的发展而不断进步，我们目前离最高水平差距还相当远。谈哪个地方是尽头还是早了点。

作者丨白鳝

来源丨公众号：白鳝的洞穴（ID：baishan755）

*仅为提供参考和学习交流，不代表dbaplus社群立场！dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn