高可用集群架构对比与迁移落地指南

1. 快速判定：心跳中断或实例探针异常后，立即进行初步判定，耗时≤1 秒；
2. 二次确认：通过备用检测通道对故障状态进行二次确认，耗时≤2 秒；
3. 自动切换：确认故障后，触发主备切换/实例重启，切换总耗时≤30 秒。

（3）多场景切换支持

• 实例故障切换：单个数据库实例挂掉，自动将该实例的连接切换到其他健康实例；
• 节点故障切换：整个数据库节点宕机，自动将该节点的所有业务切换到备节点；
• 存储故障切换：共享存储模式下共享存储故障，自动切换到备用共享存储；无共享模式下主节点存储故障，直接切换到备节点；
• 网络故障切换：私有网络故障，自动切换到公网心跳。

2.2 负载均衡

Oracle RAC 的负载均衡能力包括连接负载均衡和 TAF（透明应用故障转移）。金仓高可用集群实现了对这两大特性的完全兼容，还增加了客户端负载均衡。

（1）服务端连接负载均衡

金仓高可用集群的服务端负载均衡和 Oracle RAC 的实现逻辑完全一致，通过 KCM 集群管理工具收集各节点的运行状态，采用加权轮询 + 最小连接数的算法，将新的数据库连接分发到负载最低的节点。

（2）完全兼容 Oracle TAF 机制

金仓高可用集群对 Oracle TAF 机制做了 1:1 兼容，支持 TAF 的所有配置模式：

• SESSION 模式：会话级故障转移；
• SELECT 模式：查询级故障转移；
• PRECONNECT 模式：预连接模式。

原有应用的配置文件不用做任何修改，直接复用。例如，原有 Oracle RAC 的 TAF 配置：

ORCL_RAC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = rac1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = rac2)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orcl) (FAILOVER_MODE = (TYPE = SESSION) (METHOD = PRECONNECT) (RETRIES = 10) (DELAY = 5) ) ) ) 

迁移到金仓高可用集群后，只需修改 HOST 和 PORT 为金仓集群节点信息，其余配置完全不变。

（3）新增客户端负载均衡

金仓高可用集群还支持客户端负载均衡，通过在客户端配置多个节点地址，客户端会根据节点的负载状态主动选择空闲节点建立连接。

2.3 数据一致性

金仓高可用集群针对不同场景，提供了同步、半同步、异步三种复制模式。

（1）同步复制：数据零丢失

金仓的同步复制模式是为金融核心系统等对数据一致性要求极高的场景设计的，主节点执行的事务，必须等待备节点将重做日志同步到本地并持久化后，才向应用返回提交成功，确保主节点故障时，备节点拥有和主节点完全一致的数据。

（2）半同步复制：兼顾一致性和性能

半同步复制模式下，主节点执行的事务，只需等待至少一个备节点收到重做日志并确认后，即可向应用返回提交成功。

（3）异步复制：极致性能

异步复制模式下，主节点执行的事务无需等待备节点同步，直接向应用返回提交成功，适合跨机房容灾、异地备份等场景。

2.4 集群扩展

金仓高可用集群采用线性扩展设计，无论是共享存储模式还是无共享模式，集群节点数都可按需增加，无数量限制，且扩展过程无需停服，无需修改应用代码。

三、迁移前的核心规划

3.1 业务场景梳理

首先要梳理企业的核心业务场景，明确对高可用、性能、成本、容灾的诉求，从而选择合适的金仓高可用集群模式。

3.2 架构适配评估

梳理完业务场景后，需要对原有 Oracle RAC 的架构进行全面评估，包括节点数、存储类型、网络架构、负载均衡配置、TAF 配置、故障切换策略等，然后制定对应的金仓集群架构适配方案。

3.3 数据量与性能评估

核心系统对性能的要求极高，迁移前必须对原有 Oracle RAC 的运行状态进行全面的性能评估，精准测算数据量、并发量、交易响应时间、批量处理效率等核心指标，然后基于这些指标对金仓高可用集群进行性能压测。

（1）原有 Oracle RAC 性能数据采集

通过 Oracle 的 AWR、ASH 报告，采集以下核心性能数据：

• 日均/峰值数据量；
• 日均/峰值并发量；
• 核心业务响应时间；
• 资源使用率；
• 慢 SQL。

（2）金仓集群性能压测

基于采集的性能数据，使用专业的压测工具对金仓高可用集群进行压测，重点验证峰值并发下的 TPS/QPS、核心业务的响应时间、故障切换过程中的性能波动等。

3.4 应用与运维适配评估

迁移的核心目标是平滑切换，即最小化应用和运维的改动。

（1）应用适配评估

金仓数据库对 Oracle 的应用兼容度极高，尤其是基于 JDBC、ODBC、OCI 的应用，几乎无需修改代码。

• 连接方式适配：原有应用基于 Oracle TNS 的连接方式，金仓完全兼容；
• TAF 配置复用：原有应用的 TAF 配置完全复用；
• SQL 语法兼容：金仓对 Oracle 的 SQL 语法兼容度达 99% 以上；
• 存储过程/函数兼容：金仓对 Oracle PL/SQL 的兼容度达 99% 以上。

（2）运维适配评估

金仓高可用集群的运维逻辑高度兼容 Oracle RAC。

• 集群管理工具适配：金仓 KCM 集群管理工具的操作逻辑对标 Oracle CRS；
• 监控体系适配：金仓支持 Prometheus、Grafana、Zabbix 等主流监控工具；
• 备份恢复体系适配：金仓的备份恢复策略和 Oracle 一致；
• 日常运维操作适配：金仓的日常运维操作和 Oracle 几乎一致。

3.5 迁移方案制定

迁移前最后一步，也是最关键的一步，是制定详细的迁移方案，明确迁移步骤、时间节点、责任分工、回滚策略、应急预案。

四、迁移落地全流程

4.1 第一步：测试环境验证

测试环境验证是迁移的基础，目的是在非生产环境中全面验证金仓高可用集群的功能、性能、兼容性。

（1）核心验证内容

• 功能验证：验证金仓集群的高可用功能；
• 应用兼容验证：将原有应用部署到测试环境；
• 性能验证：基于迁移前采集的性能数据进行压测；
• 故障切换验证：手动模拟各种故障场景；
• 备份恢复验证：验证金仓集群的备份恢复功能。

4.2 第二步：生产环境金仓集群部署

生产环境的金仓高可用集群部署，需严格按照迁移前制定的架构适配方案执行。

（1）核心部署操作

1. 硬件部署：根据选择的集群模式，部署金仓集群节点；
2. 系统环境配置：在金仓节点上安装操作系统，配置系统参数；
3. 金仓数据库安装：在各节点上安装 KingbaseES 数据库；
4. 集群配置：通过金仓 KCM 集群管理工具配置高可用集群；
5. 网络配置：配置金仓集群的私有网络和业务网络；
6. 监控和备份配置：配置金仓集群的监控体系和备份恢复体系。

4.3 第三步：全量 + 增量数据迁移

数据迁移是迁移的核心环节，金仓提供了 KDTS 高速数据迁移工具和 KFS 实时同步工具。

（1）全量数据迁移

使用金仓 KDTS 工具进行全量数据迁移，支持 Oracle RAC 的多节点数据迁移，核心优势包括智能数据类型映射、高速迁移、断点续传、数据校验。

（2）增量数据实时同步

全量数据迁移完成后，使用金仓 KFS 工具进行增量数据实时同步，能实时捕获 Oracle RAC 的事务级数据变更，通过 KSR 协议同步到金仓高可用集群。

4.4 第四步：业务灰度切换

增量数据同步稳定运行后，进入业务灰度切换阶段。

（1）灰度切换的核心步骤

1. 小流量切流：选择非核心的业务模块，将其流量从 Oracle RAC 切换到金仓集群；
2. 运行监控：切流后，实时监控金仓集群的运行状态；
3. 逐步放量：如果小流量运行稳定，逐步提升切流比例；
4. 核心业务验证：当切流比例达到 80% 后，将部分核心交易业务流量切换到金仓集群。

4.5 第五步：业务全量切换

当灰度切换验证通过，金仓集群能稳定承接 80% 以上的业务流量，且核心业务运行正常后，即可进行业务全量切换。

（1）全量切换的核心操作

1. 应用连接切换：修改应用的数据库连接配置，将所有应用的连接指向金仓高可用集群；
2. 流量验证：切换完成后，验证所有业务流量是否都已接入金仓集群；
3. 运行监控：全量切换后，进行 7×24 小时的全程监控。

4.6 第六步：集群割接

业务全量切换后，金仓高可用集群稳定运行一段时间，且无任何问题后，即可进行集群割接。

（1）集群割接的核心操作

1. 业务最终验证：割接前，对金仓集群的所有业务功能、性能、高可用能力进行最终验证；
2. 停止增量同步：停止金仓 KFS 工具的增量数据同步；
3. 下线 Oracle RAC：停止 Oracle RAC 集群的所有实例和服务；
4. 金仓集群优化：根据生产环境的运行状态，对金仓高可用集群进行最后的参数优化。

五、迁移后的运维适配

5.1 集群日常运维

金仓 KCM 集群管理工具的操作逻辑和 Oracle CRS 高度对标，原有 Oracle RAC 的常用运维命令，在金仓 KCM 中都有对应的命令。

除了命令行操作，金仓 KCM 还提供了可视化的 Web 管理界面。

5.2 监控体系适配

金仓高可用集群支持 Prometheus、Grafana、Zabbix、Nagios 等所有主流的监控工具，可直接复用原有 Oracle RAC 的监控平台。

5.3 备份恢复体系适配

金仓的备份恢复策略和 Oracle 高度一致，支持全量备份、增量备份、归档日志备份、时间点恢复等所有备份恢复方式，可直接复用原有 Oracle RAC 的备份恢复脚本，只需将备份工具从 Oracle 的 RMAN 替换为金仓的 kbackup。

5.4 性能优化

金仓数据库的性能优化思路和 Oracle 高度一致，原有 Oracle RAC 的性能优化经验可直接复用。

（1）SQL 优化

金仓对 Oracle 的 SQL 优化器做了高度兼容，支持 Oracle 的执行计划、优化提示（HINT）。

（2）索引优化

金仓支持 Oracle 的所有索引类型，原有 Oracle RAC 的索引设计可直接复用。

（3）参数优化

金仓的核心数据库参数和 Oracle 的参数对应，原有 Oracle RAC 的参数优化经验可直接复用。

六、真实案例落地

6.1 案例 1：某股份制银行核心交易系统 Oracle RAC 迁移

（1）项目背景

该银行的核心交易系统基于 Oracle RAC 19c 搭建，采用 2 节点共享存储架构，支撑全行的存款、贷款、转账、清算等核心业务，TPS 峰值达 2 万。

（2）金仓解决方案

1. 集群模式选择：选择金仓无共享同步复制高可用集群，2 主 2 备架构；
2. 架构适配：金仓集群节点配置对标原有 Oracle RAC 节点；
3. 数据迁移：使用 KDTS 工具进行全量数据迁移，KFS 工具进行增量数据实时同步；
4. 应用适配：应用基于 JDBC 连接，TNS 配置文件仅修改节点地址；
5. 灰度切换：先将查询业务、报表业务切换到金仓集群，逐步将核心交易业务切换；
6. 运维适配：复用原有 Prometheus+Grafana 监控平台。

（3）项目效果

• 迁移过程：全程业务不中断，数据零丢失，应用零改造，迁移周期仅 30 天；
• 高可用能力：故障自动切换≤30 秒，比原有 Oracle RAC 的高可用能力更强；
• 性能表现：TPS 峰值达 2.5 万，比原有 Oracle RAC 提升 25%；
• 成本降低：摆脱 Oracle 专用共享存储依赖，硬件成本降低 60%，每年运维成本降低 50% 以上。

6.2 案例 2：某省级运营商计费系统 Oracle RAC 迁移

（1）项目背景

该运营商的计费系统基于 Oracle RAC 12c 搭建，采用 3 节点共享存储架构，支撑全省千万级用户的实时计费、月末批量出账、套餐抵扣等业务，数据量达 PB 级。

（2）金仓解决方案

1. 集群模式选择：选择金仓读写分离高可用集群，1 主 3 备架构；
2. 架构适配：金仓集群节点采用国产化鲲鹏服务器；
3. 数据迁移：使用 KDTS 工具进行全量数据迁移，KFS 工具进行增量数据实时同步；
4. 性能优化：对核心批量出账 SQL 进行优化，开启金仓的并行计算功能；
5. 全量切换：选择月末出账完成后的业务低谷期进行全量切换；
6. 集群扩展：迁移完成后，根据业务需求新增 2 个备节点。

（3）项目效果

• 集群扩展：实现线性扩展，无节点数限制，新增节点后整体性能提升 40%；
• 成本降低：摆脱 Oracle 共享存储和授权依赖，硬件成本降低 70%，每年节省 Oracle 授权和服务费超千万元；
• 高可用能力：故障自动切换≤30 秒，系统可用性从 99.99% 提升到 99.995%。

七、迁移常见坑点与避坑技巧

7.1 坑点 1：忽略共享存储兼容性

表现：选择金仓共享存储模式时，忽略金仓和原有 Oracle 共享存储（如 ASM）的兼容性，导致金仓节点无法正常访问共享存储。 避坑技巧：迁移前提前验证金仓和原有共享存储的兼容性，优先选择兼容列表中的存储设备。

7.2 坑点 2：网络规划不合理

表现：金仓集群的私有网络和业务网络共用，或私有网络带宽不足，导致节点间心跳中断、数据同步延迟。 避坑技巧：严格将金仓集群的私有网络（心跳/数据同步）和业务网络分离，私有网络采用高速网络，独立 IP 段，独立交换机。

7.3 坑点 3：数据迁移前未做数据清洗

表现：Oracle RAC 中存在大量的无效数据、脏数据、特殊字符数据，数据迁移时未做清洗，导致金仓集群中的数据错乱。 避坑技巧：数据迁移前对 Oracle RAC 的数据进行全面清洗，同时使用 KDTS 工具的数据校验功能。

7.4 坑点 4：未考虑大事务影响

表现：Oracle RAC 中存在大量的大事务，增量数据同步时，大事务会导致同步延迟飙升。 避坑技巧：迁移前对 Oracle RAC 中的大事务进行优化，拆分为多个小事务；增量同步时，避开大事务执行的高峰期。