RAC集群与服务高可用
Oracle RAC 通过多个实例访问同一个数据库实现节点级高可用和扩展能力。RAC 的关键不是多节点本身，而是全局缓存、服务管理、连接切换和应用感知故障。
# 1. 学习目标与定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 高可用到架构 |
| 核心目标 | 从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来 |
| 适合人群 | 开发人员关注服务名、连接故障和事务重试；运维人员关注 Clusterware、节点、全局缓存和服务资源。 |
# 2. 核心概念总览
RAC集群与服务高可用
├─ Clusterware
├─ RAC Instance
├─ Cache Fusion
├─ Global Cache Service
├─ VIP
├─ SCAN
├─ Service
├─ FAN
└─ TAF 与 Application Continuity
这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。
# 3. 底层原理详解
RAC 的多个实例共享同一套数据库文件，每个实例有自己的 SGA 和后台进程。多个实例要协调同一数据块的访问，这就需要 Global Cache Service 和 Cache Fusion。
Cache Fusion 通过集群互联在实例之间传递数据块，避免频繁落盘再读。但跨实例块传输不是免费午餐，热点块、跨实例写争用和应用服务分布不合理会让 RAC 性能变差。
RAC 高可用最终通过 Service、VIP、SCAN、FAN、TAF 或 Application Continuity 传递给应用。没有应用侧连接治理，RAC 只能保证数据库资源还在，不能保证业务无感。
# 4. 关键机制拆解
# 4.1. Clusterware 与资源管理
Clusterware 管理节点成员、网络、磁盘、数据库实例、监听、VIP、SCAN 和服务资源。它负责检测故障并按依赖关系拉起或迁移资源。
运维人员要理解 CRS 资源状态、投票盘、OCR、心跳和 fencing。集群故障往往不是数据库 SQL 问题，而是网络、存储或节点成员问题。
# 4.2. Cache Fusion 与全局缓存
当实例 A 需要实例 B 持有的块时，RAC 可以通过私有网络传递块镜像或授权，而不是强制从磁盘读取。这样提升共享数据库访问能力，但也引入 global cache waits。
应用如果把同一热点数据随机打到多个实例，会制造跨实例块争用。服务按业务域或数据亲和性划分，往往比盲目负载均衡更稳。
# 4.3. VIP、SCAN 与 Service
VIP 用于节点故障时快速让客户端感知连接失败，SCAN 提供集群级连接入口，Service 表达业务负载和实例偏好。应用应连接 Service，而不是固定实例。
服务设计要区分 OLTP、报表、批处理、管理任务和 PDB。不同服务可以配置不同首选实例和故障策略。
# 4.4. FAN、TAF 与 Application Continuity
FAN 让客户端快速获得服务上下线事件，TAF 可以在部分查询场景中故障转移，Application Continuity 尝试重放可重放请求。
这些能力不是开启即万能。应用事务、外部副作用、序列、临时状态和不可重放调用都可能影响故障透明度，需要实际验证。
# 5. 功能模块细节补充
本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。
# 5.1. Clusterware
Clusterware 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 5.2. RAC Instance
RAC Instance 是实例与数据库协作链路中的组成部分。实例侧负责运行时内存、进程和调度，数据库侧负责控制文件、数据文件和日志文件；该模块的异常通常会反映到启动阶段、后台进程等待、告警日志或恢复流程中。
# 5.3. Cache Fusion
Cache Fusion 是 RAC 的核心机制。多个实例访问同一数据库时，数据块可以通过集群私网在实例缓存之间传递；它减少磁盘往返，但热点块跨实例传递会形成 global cache 等待。
# 5.4. Global Cache Service
Global Cache Service 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 5.5. VIP
VIP 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 5.6. SCAN
SCAN 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 5.7. Service
Service 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 5.8. FAN
FAN 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 5.9. TAF 与 Application Continuity
TAF 与 Application Continuity 是高可用链路中的组成部分。它可能承担日志同步、角色切换、节点资源、服务发现、客户端通知或请求重放；高可用是否有效，最终要看数据库切换、应用重连、数据校验和回切演练。
# 6. 开发人员重点提醒
- 连接 RAC 使用 Service/SCAN，设置合理超时。
- 事务设计要支持重试和幂等，外部副作用不能被盲目重放。
- 高热点业务可按服务或数据域做实例亲和。
# 7. 运维人员重点提醒
- 监控 CRS 资源、节点、私网、global cache waits、服务分布和连接数。
- 定期演练节点故障、服务迁移和客户端重连。
- 不要把 RAC 当作线性扩容工具，先看全局缓存争用。
# 8. 典型问题与排查
- gc buffer busy 高：检查热点块、服务分布和 SQL 访问模式。
- 节点故障应用恢复慢：检查 VIP、SCAN、FAN、连接池超时。
- RAC 扩容后更慢：检查跨实例争用和负载亲和。
# 9. 实践建议与检查清单
- Service 设计清晰
- SCAN/VIP 可用
- FAN/TAF/AC 已验证
- 私网延迟有监控
- global cache waits 有基线
# 10. 阶段小结
本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。