Oracle RAC环境使用及说明

Oracle RAC 全称 Real Application Clusters（真正应用集群），是 Oracle 数据库提供的企业级高可用与横向扩展架构。

简单来说：多个独立的服务器（节点）同时运行同一个 Oracle 数据库，所有节点共享同一份物理数据文件，对外表现为一个统一的数据库服务。

一、RAC 核心架构（5 大关键组件）

RAC 是一个 "多实例、单数据库" 的架构，与传统单实例数据库（一个实例对应一个数据库）有本质区别。

客户端 → 监听器(负载均衡) → 节点1实例/节点2实例/... → 共享存储(数据文件/控制文件/日志文件)
                ↓
          高速私有互联(Cache Fusion)

1、集群节点（Cluster Nodes）

• 2~100 + 台 独立的物理 / 虚拟服务器，每台称为一个 "节点"
• 每个节点运行自己的操作系统和 Oracle 数据库实例
• 节点之间通过高速私有网络（通常是万兆以太网或 InfiniBand）互联

2、Oracle Grid Infrastructure（集群件）

• RAC 的基础平台，必须单独安装在所有节点上
• 核心功能：集群节点管理、资源调度、故障检测、VIP 漂移、ASM 存储管理
• 包含两个关键服务：CRS（Cluster Ready Services）和 ASM（Automatic Storage Management）

3、共享存储（Shared Storage）

• 所有节点必须能同时访问的集中式存储
• 存储类型：SAN（存储区域网络）、NAS（网络附加存储）、Exadata 存储服务器
• 存储内容：数据文件、控制文件、联机重做日志、归档日志、SPFILE 参数文件
• 注意：只有数据是共享的，每个节点的内存和 CPU 是独立的

4、数据库实例（Database Instances）

• 每个节点运行一个独立的 Oracle 实例（内存 + 后台进程）
• 所有实例共同访问同一个物理数据库
• 每个实例有自己的 SGA（系统全局区）和后台进程
• 实例之间通过 Cache Fusion（缓存融合） 技术同步数据

5、监听器与服务（Listeners & Services）

• 客户端通过数据库服务名连接，而不是直接连接某个节点
• SCAN（Single Client Access Name）监听器提供统一的连接入口
• 自动实现连接负载均衡和故障转移

二、RAC 核心技术：Cache Fusion（缓存融合）

这是 RAC 区别于其他集群数据库的最核心技术，也是 RAC 高性能的关键。

• 传统集群问题：多个节点修改同一数据时，需要频繁写入磁盘同步，性能极差
• Cache Fusion 解决方案：数据块直接在节点的内存之间通过高速私有网络传输，不需要写入磁盘

工作流程：

1. 节点 A 需要修改数据块 X，发现节点 B 的缓存中已经有该数据块
2. 节点 A 通过私有网络向节点 B 发送请求
3. 节点 B 将数据块 X 的最新版本直接发送给节点 A
4. 节点 A 修改数据块 X，然后通过私有网络通知其他节点该数据块已更新

三、RAC vs 单实例数据库对比

四、RAC 的主要优势

1、极致高可用性（99.99%+）

• 节点级故障自动转移：一个节点宕机，连接会自动切换到其他正常节点
• 滚动升级：可以逐个节点升级数据库和操作系统，不中断业务
• 计划内停机时间几乎为零

2、线性横向扩展

• 当业务量增长时，只需添加新的节点即可提升数据库性能
• 理论上可以扩展到上百个节点（实际生产环境通常 2~8 个节点）

3、负载均衡

• 连接时负载均衡：新连接自动分配到负载较轻的节点
• 运行时负载均衡：可以将不同的业务负载分配到不同的节点

4、资源管理

• 可以为不同的业务服务分配不同的节点和资源
• 避免关键业务被非关键业务影响

五、RAC 的适用场景与不适用场景

1、适用场景

• 核心 OLTP 系统：银行核心交易系统、电信计费系统、电商订单系统
• 需要 7×24 小时不间断运行的关键业务系统
• 业务量持续增长，单节点无法满足性能需求的系统
• 对计划内停机时间要求严格的系统

2、不适用场景

• 小型应用：单节点完全能满足需求，RAC 会增加不必要的复杂度和成本
• 大量长查询的 OLAP 系统：Cache Fusion 会产生大量的网络流量，反而降低性能
• 预算有限的项目：RAC 需要昂贵的共享存储和 Oracle 企业版许可证
• 缺乏专业 DBA 团队的企业：RAC 的管理和排错比单实例复杂得多

六、常见误解澄清

1. RAC 不是备份解决方案：RAC 只能防止节点级故障，不能防止数据损坏或误删除，仍然需要定期备份
2. RAC 不是性能万能药：如果应用设计不好（比如存在大量热点数据），RAC 性能可能比单实例还差
3. RAC 不能代替容灾：RAC 只能解决本地机房的节点故障，不能解决机房级灾难，需要配合 Data Guard 使用

七、总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论