如果我们失去RAC数据库架构怎么办？

 全球500强企业的案例说明，企业的OLTP关键系统是非常适合运行在RAC上的。但是也有很多大型企业没有使用RAC，尤其是在国外。10多年前，我在为美国第二的食品企业，以及欧洲某大型航运集团提供DBA服务的时候，就发现基本上所有的数据库都是运行在AIX上单机数据库。曾经展开过多次，采用RAC能否获得收益的内部会议，最后到我2013年离开该职位，也没有新增RAC。

但国内的使用情况，恰如其反，在大型企业中，一般80%甚至更多的系统，全部是RAC数据库。老外不用原因很简单，老外用一套买一套，他们买不起那么多RAC的软件和硬件。国内从技术角度来说，一般人都认为，贵=好，那么我就要使用更贵的产品。

在目前国内的信创浪潮中，大量的国产数据库，或者开源数据库，要替代O，则会面临大量的RAC数据库系统的替代，那么信创之路的第一个重大问题是，RAC怎么替代？

本探长一般把目前使用最多开源和国产数据库简单划分为2种流派，2种架构，（还有更细的分类，啥互联网派，学院派，实干派..）

2. 

架构分为，

这里只有达梦数据库提供类似RAC的架构，但是这里在网络上找不到大量市场和客户的案例来证明其是否满足关键系统的高可用性和高性能，这里无法进行评价。该产品的架构，技术路线和Oracle 11gRAC接近。

Oracle从12c开始Rac的代码又进行了大量改动更新，融入了大量的新特性，特别是应用连续性，高可用性，弹性伸缩等方面有重大的提升！可参考白皮书如下：DM作为能够自研出同类的架构能力，还是值得钦佩的。

其余的流派都没有RAC架构，替代方案要么就是分布架构，

要么主从高可用架构，读写分离。

关键点来了那么失去了Oracle RAC的架构，你会失去什么？

弱化计算节点的分布式一致性计算能力，影响大

这个能力简单来说，就是在多个节点或者副本，同时地写入，读取相同的数据区域，提供高并发，高性能和强一致性。

RAC可以多个节点承载业务，而且各节点之间是通过高速心跳网络来实现强一致性，MVCC。简单来说新一代的RAC分布式一致性是通过锁机制以及RDMA等高速网络实现的内存级访问di地一致性，分布式系统要保障分布式强一致性，计算层就是靠2PC， 存储靠raft等协议，例如理论和落地都相当复杂，而且必须在延迟和一致性上做折中。

它们两者最大差距，

1 ，分布式一致性和延迟，Oracle RAC跨节点的强一致性依赖高速心跳网络，在目前聚合无损交换网络的大量使用下，Oracle获取数据库最快方式，一是从本地内存，二就是从相邻实例，它的延迟已经小于从存储中获得数据（包括flashcache），延迟是us级。而分布式系统，要跨节点实现一致性，要么就是弱一致性，带来数据延迟。要么就是强一致性，带来更高的延迟，5ms起步，实际体验差异是100倍以上。

如果是写入，弱一致性是不允许写，会带来数据混乱。强一致性写，必然有全局事务ID，全局锁，采用2PC协议，带来更高的延迟，或者如Oceanbase的“DML重定向”。Oracle在cache fusion上已经深耕多年，最新已经引入RDMA等技术，RAC的这种机制可以成为原生分布式一致性。它在分布式强一致性在这个领域上遥遥领先。

2， 应用的复杂性，这些对企业应用都是很重要。Oracle的强一致性是透明的，无需管理的，用户感知不到各个节点有任何使用上的差异，所以这个特性是其它分布式数据库现阶段差距较大的。

3. 稳定性，有，但不一定稳定，Oracle RAC存在大量的性能优化，故障分析技术积累，而且目前其它分布式数据库大部分则还刚刚跳出鸿蒙阶段。但分布式有个天然区别，RAC不一致， CRASH!  分布式不一致，延迟，最终一致。这样分布式可以支持的跨站点距离更长。Extended RAC最多50公里。

4. 读取分离架构，Oracle的读写分类架构实际是ADG，RAC读写是不分离的，读也会可能产生跨节点流量。ADG异步模式实际有延迟，这一点分布式更适合弱一致性读写分类架构。

失去RAC的应对策略，高配置硬件单节点承载业务，业务分区分库，减少单节点算力需求。不要做跨分片计算请求，在应用逻辑里面处理。这也是目前分布式架构，事实上落地的方案。

计算节点的分布式并行计算能力，影响微小

这个能力，就是可以将聚合计算分布到多个节点运行，提高效率

RAC做OLAP的分布式特性基本是鸡肋。RAC的跨实例运行大型查询，更加需要一个非常好网络设施。现状是基本没有客户采用这个特性，分布式数据库的OLAP不要求强一致，读数据的比例远高于写比例，实际更加适合这个场景，可扩展性更好，节点数可以远远大于Oracle RAC。常见就是Hadoop等大数产品，以及国产的阿里 AnalyticDB 和华为的GaussDB 200等产品。

弱化了计算节点均衡负载能力，影响中

这个能力是，可以把应用的连接自动化的按照预定义的规则（轮询，基于负载，基于连接数）均衡负载到多个计算节点

由于当前分布式架构跑企业数据库一般都是单节点承载业务，均衡负载名存实亡，或者即使是均衡负载，又涉及强一致性和延迟，以及数据是否分片，基本和RAC Scan的均衡负载差异极大，业务需要适配的工作很多。

应对的策略：也是业务分区分库，单节点承载业务，减少均衡负载能力的需求。

降低了计算节点高可用性能力RTO，影响大。

节点崩溃，其它节点可快速接管奔溃节点的应用连接

Oracle的单个实例crash，集群会快速自动的将crash实例的数据恢复到存活实例，而应用也可以快速的重连到存活实例，并且在故障实例恢复后，可以自然的重新加入集群提供服务。Oracle 19c提供了的内存级恢复服务，buddy recover，大大提升了该类故障的RTO。Oracle通过Scan来自动探活节点。

分布式数据库在解决多副本一致的方法上，业界的Paxos和Raft一致性协议，提供了很好的理论支持，特别是Raft协议，是一种易于理解和实现的分布式一致性协议，但raft算法也存在两方面性能瓶颈问题：一是每次日志写入后都需要刷盘才能返回成功，而刷盘是一个比较耗时的操作。另一是由于算法限制，所有的请求都由 Leader 处理，很难做到所有节点皆可提供服务。而Paxos协议的理论和实现都更加复杂。

虽然任一家数据库厂商都宣传它在应对这种故障场景时，都可以完美高效保障数据库可用性，但是即使是Oracle 19c数据库，我们都依然在优化此类故障带来的可用性影响。在这一点其它数据库和其实Oracle差距较大，不管是分布式架构，还是主从架构，基本发生了单节点故障，业务肯定会面临更长时间的中断。

下面这段话有夸大嫌疑，RTO最终要和应用场景适配，这样的宣传是惯用的手法。

应对的策略：业务要做好面对更长连接中断的场景的准备，以及丢失少量数据的数据校验和追补的预案。

失去计算节点的应用连续性能力，影响大。

这个能力简单说，就是节点CRASH，应用不中断，不报错

在RAC中，发生了单节点crash，或者在rolling维护的时候，TAF特性可以使查询不中断，TAC特性可以是的业务(DML)不中断，这一点其它分布式数据库和Oracle差距极大。简单来说，全局一致性是把维护了一个全局事务ID，而Oracle的应用连续性，还维护这个事务全生命周期的记录，使得它可以在存活节点进行回放。其它类型的数据库基本没有看到类似特性的研发成果。对于金融等，对连续性追求极致的数据库系统来说，失去该特性，是技术的倒退的。

应对的策略：要在其它层面加大HA投资，增加其它层面组件可用性，尽量避免单点故障，应用也要做好新架构下可用性的极致研究。分区分库，尽量控制单点故障的最小影响范围。技术的倒退，不一定是业务的倒退和用户体验的倒退。

另外，其实还有一个选择，就是采用类似的“RAC架构”  DM共享集群，但这里无法进行评论。

看到这里，大家可能觉得，前路艰难吗？其实未必。

如果说有人问我，是否要安装RAC，我的一般建议是：小系统不要使用 RAC，它被过度使用了。我多次向RAC 用户询问：“您是否评估通过 RAC 获得的可用性或者计算能力的收益？” 我很少获得过客户发自内心的答案。

如上所述，RAC 可以在计划停机，单计算实例故障等方面提供全局可用性收益，以及分布式计算能力的收益，但RAC数据库对数据的保障，主要只能通过 Dataguard 获得。

而且你要充分获得RAC的收益，需要你非常富有，即采购非常高端的硬件，特别当然最好的平台是Exadata，能够充分发挥RAC数据库的强大能力。

普通的数据库系统选择使用 RAC，其实我是持有怀疑态度.根据过去的经验，留在旧 AIX 服务器上的单实例数据库相比，我们遇到的导致 RAC 数据库停机的事件其实更多。

原因很容易理解，但往往被忽视。单个O实例并不简单，但小系统上RAC彻底打破了KISS原则，部署和管理是一件复杂的事情（但是分布式数据库，同样也是这个问题非常突出）。您可以拥有任意数量的节点，Grid Infrastructure 本身将保持逻辑单点故障。每个软件都有错误，特别是如果它很复杂，网格基础设施也不例外。RAC 可以很好地检测和防止完全硬件故障，但如果你的硬件平台只是普通交换机，普通的存储，那么客户更容易受到间歇性故障和性能损失的影响。

例如，集群网络上的性能问题可能会使整个事情变慢，大量企业的内部交换网络不支持MTU9000，导致在19c存在大量心跳故障的隐患。以前经常有需要关闭一个节点来临时解决没有经验的客户在 RAC 上的性能问题，关闭一个节点，性能反而上升。其实也就说明了，单节点时间更适合运行。其实矛盾的是，这意味着您需要拥有完美的存储、完美的网络等，才能通过 RAC 实现高可用性，高性能，高弹性。但事实上，如果一切都完美的话……最后还是会有SPOF 将是 RAC 软件本身。

结论其实就是大量的小型系统，可以改造为其它架构，没有必要采用RAC架构。单节点HA主机架构，主从架构，可能都是可行的选择。当然应用系统架构也需要考虑，进行相应的HA改造。

最后关于本文，会是一个系列的开始，数据库涅槃之路，会从数据库关键特性的所有层面来详细分析这个过程的取舍和代价。

市面上的数据库产品在整体特性上，和Oracle其实差距较大

但是并不是所有的特性，都对企业是至关重要的，王探长分享的目的是：

告诉您真实的世界

欢迎关注西区重案实录