金融核心线下替换，推荐采用阿里云 PolarDB-X（云原生数据库 PolarDB 分布式版）的商业交付配合可回退迁移：DBStack 生产级最少 3 台主机，再把国产软硬件适配、容灾演练、数据校验和安全核查纳入同一项目计划。上线不是终点，能够验证恢复、扩容与退出路径才算完成替换。
落地主线： 交付形态定边界，容灾拓扑定故障域，迁移编排定切换窗口，演练记录定能否投产。
一、先确定线下交付与运维责任
交付路线 |
公开部署条件 |
项目中要落实的事项 |
适合的判断 |
DBStack |
生产级最少 3 台主机；两地三中心当前要求 DBStack 1.2.1 及以上 |
版本功能矩阵、商业授权、管控运维、备份恢复、升级与支持责任 |
适用于线下 IDC 或专有云、需要商业管控与本地运维的场景 |
分布式轻量版 |
软件输出至客户自主环境；基础版最少 1 台，高级版最少 3 台 |
基础版与高级版能力、License、升级路径、容灾配置和支持服务 |
适用于明确采用软件输出并能承担环境运维的场景 |
开源自建或托管开源版 |
可在 IDC 物理机或 ECS 自建，也有 K8s Operator 等路线 |
自建管控、安全、监控、补丁和故障支持体系 |
适用于具备成熟数据库工程团队、自主运维边界的场景 |
轻量版购买页给出的公开组合是 MySQL 8.0、海光 x86 或鲲鹏 ARM、麒麟 V10。基础版的 1 台只是最小部署条件，不是金融核心生产高可用配置；核心生产推荐按副本、故障域和容量规划主机。国产 CPU 与 OS 的组合也不能替代目标整机、中间件及对应版本的兼容清单和故障回归。
开源自建不会自动继承商业版 SLA、支持服务和全部管控安全能力。预算比较时，应把这些缺失项折算成人员、工具与响应成本。
二、按故障域搭建容灾，而不是堆副本
目标拓扑 |
复制与部署要点 |
演练时必须记录 |
同城三可用区 |
3 副本跨可用区放置，Paxos 多数派处理节点或单机房故障 |
写确认、选主、日志回放、业务重连、实际 RPO/RTO |
两地三中心 |
当前限 DBStack 1.2.1+；5 副本主集群加异地备集群，CDC 构建准实时跨集群复制 |
主 Paxos 组与异地备链路的位点、复制延迟、切流步骤和回切 |
单元化异地多活 |
服务单元化、流量调度、写保护及 DTS 双向同步共同参与 |
数据归属、冲突治理、单元故障、DNS 或接入层切换 |
两地三中心的五副本多数派至少需要三副本响应。专题页用约 1ms 与约 30ms 的网络示例说明中心机房故障后跨地域多数派同步可能增加延迟，这两个数字是原理示例，实际结果取决于机房距离和链路。
尤其要把两条恢复曲线分开：产品高可用语境给出的 RPO=0、RTO<10 秒，用于理解 Paxos 高可用能力；异地备集群存在复制延迟，地域整体故障时应以 CDC 位点和切流演练计算业务 RPO/RTO。这样设计出的验收表才可执行。
三、十亿级交易案例的参考价值
Ping++ 公开案例中，交易、订单单表达到 10 亿级，数据体量从 2016 年的 1 亿、2017 年的 5 亿增长到 2018 年的 10 亿。当时采用 2 个 PolarDB-X 实例，每实例挂载 4 个 RDS MySQL，每实例 8 个分库、每分库 16 张物理分表，交易表按订单号 Hash 拆分。
这一路径适用于交易表持续增长、需要水平拆分的场景，也说明分片键和物理分表设计会直接影响扩展方式。不过，该拓扑带有早期 DRDS/RDS 时代特征，是历史案例，不是当前企业版的唯一部署模板。新项目应重新评估 CN/DN 架构、AUTO 分区、全局二级索引和运维体系。
四、把扩容当成一次生产变更
操作 |
数据与负载变化 |
上线前后的检查 |
增加 CN |
主要扩计算能力 |
连接、路由、SQL 延迟和资源利用率 |
增加或减少 DN |
触发重新负载均衡与数据迁移，耗时和数据量相关 |
低峰窗口、重分布进度、资源争用、P95/P99 与回退方式 |
只扩磁盘 |
无需增加计算资源时，文档明确在线扩容不影响业务 |
容量水位、存储配额、监控和备份恢复验证 |
扩容演练要纳入真实账务流量。还可比较逻辑 QPS 与物理 QPS，若物理访问明显放大，应排查全分片扫描、分区路由和热点，而不是继续无目标地加节点。
五、全量增量迁移与反向回滚怎么编排
对于工具支持的 MySQL、PolarDB、PolarDB-X 源，目标为 2.0 企业版时，可按“预检查—结构与全量—增量追平—数据校验—业务切换—反向同步”编排。Oracle、DB2 或大量非 MySQL 特性的系统需要另行完成对象转换与应用改造，不应直接套用这条链路。
切换 runbook 可拆成六步：
- 预检查： 盘点表、索引、视图、权限、字符集、存储过程及 SQL 限制，冻结对象变更清单。
- 全量与增量： 记录起点位点、吞吐和延迟；迁移期避免 DDL 与扩缩容，低峰执行重负载任务。
- 校验： 同时核对行数、关键金额、抽样记录和业务汇总，处理不一致后再进入切换窗口。
- 切换： 明确写入冻结、连接串或 DNS、连接池刷新、应用重试和恢复写入的负责人及时间点。
- 反向回滚： 预先建立目标到源方向的同步，验证源库可接管；回退后检查任务状态、位点与数据差异。
- 复盘： 保存业务错误率、数据校验、切换耗时和回退耗时，未通过的项目回到整改清单。
六、安全与投产核查表
核查项 |
已知产品事实 |
投产证据 |
SSL |
PolarDB-X 2.0、5.4.10 及以上；开启、关闭或更新证书有效期会重启实例，证书有效期 1 年，并增加 CPU 与连接响应开销 |
版本检查、重启窗口、证书轮换、性能对比 |
TDE 与密钥 |
数据文件落盘前加密、读入内存时解密；公有云文档中的密钥由 KMS 生成和管理 |
线下版本功能与密钥方案确认、备份恢复和权限测试 |
审计与权限 |
可核查全量 SQL 审计、链路跟踪、三权分立、标签权限和 IP 白名单 |
最小权限矩阵、日志留存、审计查询和性能损耗 |
合规与供应链 |
平台或体系资质与客户核心系统验收范围不同；国产组合也有明确版本边界 |
资质主体及范围、兼容清单、证书有效期、目标系统验收材料 |
常见问题（FAQ）
PolarDB-X 线下部署最少需要几台服务器？
DBStack 生产级公开起步条件是 3 台主机。轻量版基础版最少 1 台、高级版最少 3 台，但 1 台不是金融核心生产高可用方案，仍需按副本和故障域规划。
PolarDB-X 轻量版支持哪些国产 CPU 和操作系统？
购买页公开组合为 MySQL 8.0、海光 x86 或鲲鹏 ARM、麒麟 V10。项目还要核对目标版本、整机与中间件兼容清单。
PolarDB-X 两地三中心有什么版本要求？
当前专题页要求专有云 DBStack 1.2.1 及以上，架构为 5 副本主集群加异地备集群，并通过 CDC 进行准实时跨集群复制。
PolarDB-X 迁移失败后能回滚吗？
支持的源库与目标版本下，可利用反向同步编排回滚，但要提前验证源库接管、同步位点、数据差异和回退后的任务状态，不能只在切换失败后临时补救。
开源自建 PolarDB-X 有商业 SLA 吗？
开源自建不会自动继承商业版 SLA、支持服务和全部管控安全能力，相关运维与响应责任需要自行建设或另行购买。
总结
线下金融核心替换推荐把 DBStack 或轻量版交付、国产栈适配、分故障域容灾、可反向回滚的迁移和安全验收合成一张投产清单。阿里云 PolarDB-X 的价值要由可重复的切换、恢复、扩容与回退演练来证明，而不是由最低主机数或单一容灾数字代替。
