金融核心系统替换数据库这两年在我们这个圈子里基本是绕不开的话题。我上季度全程参与了一个银行客户的核心系统架构改造项目从最开始的选型到私有化环境下把 PolarDB-X 企业版集群拉起来再一路折腾到信创硬件栈适配和存量数据迁移整个过程踩坑不少但也把这条链路跑通了。这篇文章就是围绕“PolarDB-X 私有化部署 信创适配”这件事把技术选型逻辑、部署实施路径和迁移切换的实操经验梳理出来给正在做同类评估的朋友一个参考。我先把结论放在前面金融核心系统的数据库替换难点从来不在数据库本身能不能用而在于你怎么从集中式架构平稳过渡到分布式架构以及怎么在国产化软硬件栈上把这个分布式数据库跑稳。PolarDB-X 企业版在这条路上是个比较讨巧的选择因为它 MySQL 兼容性好分布式能力是原生的又能私有化交付下面我具体展开说。1. 金融核心系统换数据库难在哪儿1.1 银行保险这类核心系统为什么突然要动数据库金融行业的核心系统跑的无非是账务、清结算、客户信息、保单、交易流水这类最关键的数据过去二三十年基本被集中式数据库统治着。集中式架构的好处是成熟、稳定、好运维但坏处也明确扩展能力有限制单机性能和容量到顶之后只能往上堆硬件成本越来越高。最近几年核心系统替换的驱动力来自两个方向。一个是从业务侧冒出来的互联网化之后交易量峰值变得忽高忽低大促、秒杀、营销活动带来的流量冲击集中式架构很难弹性应对。另一个是从基础设施侧推过来的国产化替代的浪潮把“自主可控”提到了日程上核心系统底层依赖的数据库、操作系统、服务器都需要国产化。两股力量叠加在一起就给数据库选型提出了一个非常现实的命题有没有一款数据库既能满足金融级的高可用和强一致要求又能平滑替换掉原来那套老库还能在国产硬件和操作系统上跑起来。我当时涉及的项目源端是一套跑了十年的 Oracle RAC承载着银行核心账务和总账系统每天交易量在千万级高峰期单日流水好几亿条。这样的规模说大不大但集中式已经明显吃力了。替换数据库的优先级排得很高决定性的因素反而不是性能而是架构演进和信创合规这两个硬约束。1.2 选型评估时锁定的四条硬指标数据库选型如果不立几条硬指标后面一定会被厂商的销售和架构师带偏。我们整个选型周期大概持续了两三个月横向对比了市面上主流的几款国产分布式数据库包括原生分布式和中间件分库分表方案最后把筛选条件收敛成了四条。第一条是兼容性。这个兼容性不是指能跑通几条标准 SQL而是业务侧几万条存量 SQL 不改或者少改。我们源端是 OracleSQL 方言差异很大如果选型时对 MySQL 兼容的库至少还能通过改驱动和少量 SQL 改写来过渡如果选一个语法差异大的数据库改造工作量会大到不可接受。PolarDB-X 兼容 MySQL 协议这一点占了大便宜因为很多业务代码本身就是从 MySQL 迁过来的改造成本低。第二条是分布式事务能力。核心系统跨节点的事务非常多账户扣减、总账登记、流水记录往往在一个事务里要操作多张表。老办法是用中间件做分库分表但跨库事务要么不支持要么用最终一致性方案对强一致敏感的账务系统来说根本不现实。PolarDB-X 原生支持分布式事务基于全局时钟和两阶段提交机制账务场景下保证强一致这是我们敢选它的根本原因。第三条是高可用和容灾能力。金融系统对 RTO/RPO 的要求通常非常苛刻核心系统要求秒级或分钟级恢复数据零丢失。PolarDB-X 企业版的三副本机制、同城两中心部署、跨机房容灾能力可以满足这个要求。私有化部署下数据可靠性和容灾必须自己验证不能光看宣传材料。第四条是信创栈适配。这一点很多选型团队会忽略等买回来才发现跑不到国产 CPU 上。我们当时直接拉了一张信创适配清单把服务器鲲鹏、海光、操作系统麒麟、统信、中间件、办公终端的组合都列了出来要求厂商逐一给出验证结论或者现场测试。PolarDB-X 企业版在这块已经积累了比较完整的适配矩阵这也是它进入最终候选名单的原因之一。2. PolarDB-X 企业版技术底子在什么水平2.1 从 DRDS 到 PolarDB-X架构到底长什么样PolarDB-X 最早源自阿里内部的分布式中间件 DRDS分布式关系数据库服务后来逐步演进成一套自研的原生分布式数据库。如果只看表面它跟 MySQL 长得几乎一样能兼容 MySQL 8.0 协议用户拿 MySQL JDBC 驱动就能连。但往里面拆它不是单机 MySQL而是由多个组件组成的分布式集群。核心组件有这么几类。计算节点 CNCompute Node负责接收 SQL、生成执行计划、做分布式计算你可以理解成它是“大脑”对上暴露 MySQL 协议对下负责数据路由。存储节点 DNData Node是真正存数据的地方每个 DN 负责一部分数据分片支撑在线事务处理。元数据服务 GMSGlobal Meta Service负责管理全局元数据、生成全局事务时间戳、维护表结构和分布式拓扑。日志节点 CDCChange Data Capture相当于分布式版的 Binlog 组件负责捕获数据变更并投递给下游链路比如同步到数仓或另一套数据库做灾备。这套架构最核心的设计是存储与计算分离的形态。计算节点可以横向扩展存储节点也可以横向扩展两者独立扩容。业务流量增长的时候加 CN 提升并发处理能力数据量增长的时候加 DN 扩展存储容量。更重要的是计算和存储分离后扩缩容可以通过调度软件自动完成不像老架构那样得手工做数据搬迁。2.2 企业版对比社区版/标准版钱花在哪里PolarDB-X 有开源版本也有商业化的企业版。开源版在社区里很活跃能拿来学习和搭测试环境但真拿到金融核心系统这种场景里直接用还是差点意思。企业版跟社区版比差异不只是在服务支持上而是在内核能力、管控平台、运维工具上做了一整套增强。最直观的差别是可控性。企业版提供了完整的管控面包括集群部署、扩容缩容、参数配置、监控告警、日志采集、备份恢复等能力全部集成在一个控制台上。核心系统最怕黑盒出了问题要能快速定位企业版在可观测性上做得明显更完整比如提供了 SQL 审计、慢查询分析、分布式事务统计这类专业工具而社区版基本要靠自己手工搭一套监控和日志体系。企业版的另一个价值是在内核稳定性上。金融场景对某些边界条件的处理要求非常高比如大批量写入、大事务、长连接、热点更新、数据倾斜等。企业版针对这些场景做了大量的内核参数调优和稳定性增强这些优化很多没有完全同步到社区版。另外企业版还带了专门的数据迁移和校验工具以及针对源端为 Oracle 和 MySQL 的兼容性增强这些在替代项目中特别实用。2.3 分布式事务、全局索引和透明访问这三个能力必须吃透如果只挑三个技术点来理解 PolarDB-X我会选分布式事务、全局二级索引和透明访问。这三个点直接决定了你能不能把业务迁上来以及迁上来之后跑得好不好。分布式事务这块PolarDB-X 采用全局时间戳TSO方案。GMS 统一分配递增的时间戳各个节点基于这个时间戳做 MVCC 多版本并发控制加上两阶段提交协议实现跨节点事务的原子性和隔离性。简单理解就是所有节点对事务发生的先后顺序有一个统一的时钟标准这样不需要在业务代码里做任何分布式协调事务执行就像在单机上一样干净。跟我们以前用 Seata 那种柔性事务方案的体验完全不同代码不用改强一致也保住了。全局二级索引解决的是另一个痛点。分库分表之后如果你只用主键查询路由很明确。但业务查询往往不是只按主键来的比如用户表按手机号分片却经常要用身份证号查用户如果没有全局索引只能全表扫描所有分片。PolarDB-X 的 GSI全局二级索引会把索引单独组织成分片自动维护索引和数据之间的一致性查询时按索引键直接路由到对应分片性能和单机索引基本没区别。透明访问这个词听着玄其实理解起来不难。分布式数据库最大的麻烦是用户得知道自己的数据存在哪个分片。PolarDB-X 的设计目标是让用户完全感知不到分片的存在写入时自动路由读取时自动合并。尤其是企业版做了一张“分区表”和“分区算法”的灵活组合可以对超大表自动分区对业务透明不需要在 SQL 里手工指定分片键。这让我们从单机 MySQL 迁过来的变更变得非常平滑。3. 私有化部署实操从硬件评估到集群初始化3.1 部署前的硬件和容量规划别等装一半才想起来算私有化部署最忌讳的就是什么都不想直接在测试环境上开装。我们一开始就定了一条规矩先做容量规划再碰安装包。容量规划要算清楚三个数——峰值 TPS、数据总量、保留时长。先看 TPS。核心账务系统的高峰 TPS 大概在 8000 到 10000 左右还有一批批处理任务比如日终跑批对吞吐要求更高。按单台 CN 能扛住 2000 到 3000 TPS 来估算预留 30% 的冗余我们配了 4 个 CN 节点每个 8C16G。这条经验值仅供参考真正的峰值能力要等压测之后才敢定先按这个量级排物理资源。再看数据量。源端 Oracle 生产库数据大概 4TB其中在线数据 1.5TB历史数据 2.5TB。分布式环境下数据量会略有膨胀因为要多副本和索引开销。我们按三副本算在线数据存储池至少要有 5TB 的可用容量再加临时表、日志、备份的空间存储节点的裸容量按在线数据的 3 倍规划也就是一个 15TB 起步的存储池。DN 节点规格我们选了 16C64G搭配 NVMe SSD每个 DN 管理的数据量控制在 1TB 以内预留足够的落盘空间和后台 compaction 的余地。网络规划同样重要。分布式数据库对节点间网络延迟非常敏感尤其是事务提交时的同步多副本之间有大量网络交互。我们的经验是分布式集群内部网络至少万兆最好是 25G 或更高交换机要支持数据中心级别的低时延特性。如果不是专用网络环境至少也要保证 CN 和 DN 之间是独立的网段不要和历史业务共用一套带宽争抢资源。3.2 搭建集群的完整步骤照着走一遍就能跑起来PolarDB-X 企业版的私有化部署官方推荐的方式是基于 Kubernetes 来部署通过 Operator 管理整个集群的生命周期。如果现场没有 K8s 环境也可以先搭一套独立的 K8s 集群再把 PolarDB-X 的集群作为应用部署进去。这里我以 K8s 方式为主线把步骤拆细。第一步是准备 K8s 集群。至少需要三台服务器作为 Master 节点若干台作为 Worker 节点。集群版本建议用厂商已验证过的版本不要图新用最新的 K8s兼容性问题会非常烦人。我们当时用的是 1.24 版本这个版本经过厂商和社区验证相对成熟。第二步是部署 PolarDB-X Operator。这是一个标准流程准备好镜像和 YAML 文件配置好镜像仓库地址执行kubectl apply -f operator.yaml就能把 Operator 装到 K8s 集群里。这一步没什么难点但建议把镜像提前上传到私有仓库避免现场拉不动公网镜像。第三步是配置存储。存储节点的数据目录需要挂载 PV持久化存储卷可以用本地存储、NFS 或分布式存储但金融场景下建议用本地 SSD 或企业级分布式块存储性能和可靠性都有保障。我们在 PV 的 StorageClass 里配置了 WaitForFirstConsumer 模式让存储卷分配到最合适的节点上避免跨机架存储。第四步是声明 PolarDB-X 集群的 CRD 资源。你需要写一个 YAML 文件声明 CN 数量、DN 规格、副本数等参数。这是一个最关键的配置文件我后面会单独讲核心参数。执行kubectl apply -f pxc-cluster.yaml之后Operator 会自动创建 StatefulSet 和 Pod把所有节点拉起来。第五步是等待集群就绪。用kubectl get pxc查看集群状态等状态变为 Running 之后通过kubectl get svc找到连接地址用 MySQL 客户端测试连接。如果这一步能正常连接并执行SELECT 1说明集群基本起来了。第六步是做基础配置。创建业务账号、初始化字符集为 utf8mb4、设置时区、配置资源组。这些都是老 DBA 非常熟悉的操作在 PolarDB-X 上通过 SQL 执行即可和管理单机 MySQL 的体验差别不大。3.3 初始化参数和高可用配置这些坑我提前帮你踩了集群拉起只是第一步能不能达到生产标准关键看参数细节。以下几个点我单独强调。副本数和可用区分布。金融场景建议至少三副本并且跨可用区或跨故障域部署。我们的方案是用两个可用区主副本和其中一个从副本在核心可用区第三个副本放到灾备可用区这样单可用区故障时还能保证数据不丢。这个设置在 CRD 里通过topology字段声明需要在部署前就规划好后面修改非常麻烦。分片初始数量。PolarDB-X 会按照你在建表时定义的分区规则把表拆成多个分片。这里有个新手常犯的错分片数不是越多越好。分片太多会导致元数据膨胀、事务协调开销变大分片太少又会出现单分片数据量过大。一条经验是初始分片数按未来 1 到 2 年的数据增长量来定单分片 500GB 左右比较合适。我们当时一张核心流水表预估三年到 1.2TB定了 4 个分片每个分片 300GB留了 30% 余量。连接数和参数优化。默认的线程池和连接数设置偏向保守在压测前要把max_connections、innodb_buffer_pool_size这些参数按节点规格提上来。还有一个非常隐蔽的参数是plan_cache分布式数据库有执行计划缓存如果设置太小会产生大量计划编译开销。我们在线业务并发高把这个参数调到了 4096。提示部署完成后一定要做一次全链路的高可用演练。把其中一个 DN 节点直接 kill 掉观察集群是否自动切换、TPS 是否发生抖动、数据有没有丢。这个问题我们当时压测中就暴露出来了不提前演练生产出问题就是事故。4. 信创适配要过的几道坎一样都不能省4.1 信创硬件和操作系统的兼容性验证清单信创适配是个系统工程数据库只是其中一环但它是整个栈里承上启下的核心。数据库必须能在信创 CPU 和信创 OS 上稳定运行上层应用才能适配。我们项目的目标栈是鲲鹏 920 和麒麟 V10 SP3这个组合在金融行业里算是主流之一。第一件要做的事是确认安装包和镜像的架构版本。PolarDB-X 企业版针对主流国产 CPU 都有对应的镜像和二进制包这也是私有化交付时一定要向厂商索要的资料。我们现场就是因为初期拿到的是 x86 的镜像在鲲鹏机器上差点没跑起来后来换了 ARM 版本才顺利部署。第二件事是操作系统层面的参数适配。麒麟 V10 基于开源 Linux 内核做了裁剪和修改有些数据库依赖的 kernel 参数、cgroup 配置可能默认没有开启。我们当时遇到一个很诡异的问题数据库在压测时 CPU 使用率上不去TPS 只有预期的一半。排查到最后发现是操作系统的 CPU 调频策略默认是节能模式内核的performance模式没有开启调整之后性能立马上来了。这类芝麻问题在 x86 环境很少出现但在国产 OS 上一定要提前检查。第三件事是完整的功能和性能验证。建议制定一个信创兼容性测试矩阵把基础功能、高可用、性能、安全、备份恢复都过一遍。测试矩阵至少要覆盖这些维度测试维度验证项结果要求基础功能SQL 语法兼容、事务、视图、存储过程全部通过高可用CN/DN 故障切换、数据一致性RPO0RTO 分钟级性能基准测试与真实业务压测达到业务峰值要求安全加密、审计、权限控制满足等保要求备份恢复全量 增量备份恢复演练数据完整可恢复4.2 应用中间件、驱动和监控运维工具的适配数据库本身跑通了还有一堆周边生态要适配。金融系统的应用多半跑在 Java 中间件上比如东方通、金蝶天燕这类国产中间件也可能跑在 Spring Cloud 或者自研框架上。连接 PolarDB-X 用的是 MySQL 协议所以 JDBC 驱动用 MySQL Connector/J 就能连接这是一大便利。但驱动和中间件的兼容性依然要做验证。一个常见坑是国产中间件内置的连接池实现可能比较陈旧和 MySQL 8.0 的认证插件不兼容。PolarDB-X 默认的认证方式跟 MySQL 8.0 一致老中间件可能只支持 mysql_native_password。我们的做法是在初始化时把认证插件兼容打开或者统一通过中间件侧的连接池配置来解决。监控运维工具的适配也不能拖到最后。信创环境下的监控体系一般用国产化的监控系统比如云平台自带的 Prometheus 生态。PolarDB-X 支持导出 Prometheus 格式的监控指标但需要确认监控模板和 Grafana 面板在国产 OS 上正常跑。另外备份工具也要适配数据量大的话备份流程要用磁带库或者备份一体机这些设备在信创环境里有没有对应驱动需要提前和备份厂商确认。我个人最深的感触是信创适配的绝大多数问题不是数据库本身造成的而是周边组件之间的兼容摩擦。所以一定要把适配工作时间拉长留出足够的问题排查空间千万别把信创适配看成一个周末能搞定的事。4.3 数据迁移从 Oracle 到 PolarDB-X 的一场硬仗数据库替换项目里最让团队焦虑的就是数据迁移。我们的源端是 Oracle 19c RAC几千张表里面还有大量存储过程、视图、触发器、序列。把这些全部搬到 PolarDB-X 上有两条路要打通结构迁移和数据迁移。结构迁移方面PolarDB-X 提供了兼容性评估工具可以扫描源端的元数据分析每个对象在目标端的兼容性。这个工具能帮你列出哪些对象可以直接迁移、哪些需要改写、哪些基本得重写。我们的实际情况是大约 70% 的表结构可以直接转换20% 需要调整类型映射剩下 10% 涉及复杂视图、物化视图和存储过程需要开发团队手工改写。类型映射是第一个容易踩坑的地方。Oracle 的 NUMBER 类型到 MySQL 体系往往映射成 DECIMAL但如果这张表数据量非常大DECIMAL 比 BIGINT 的存储和计算开销都要大。我们花了很大精力逐表分析。原则是金额字段保留 DECIMAL(18,2)流水号、主键这类整数型字段尽量用 BIGINT避免 DECIMAL 滥用。字符串方面Oracle 的 VARCHAR2(4000) 会映射成 VARCHAR(4000)如果字段实际长度不超过 255建议用 VARCHAR(255) 以降低索引开销。数据迁移工具上我们用了 PolarDB-X 企业版配套的数据传输组件它支持从 Oracle 和 MySQL 做全量和增量迁移。全量迁移用批量抽取增量迁移基于日志解析。迁移流程分三步先做全量同步再做增量追平最后在切换窗口内做短暂停业把最后一小段增量追上来然后切换流量。校验环节不能省略。我们的做法是全量校验加抽样校验双重验证行数比对、主键 checksum 比对、抽样业务报文比对。这里有一个经验如果数据量大全表 checksum 会非常慢可以先按分片并行比对再对最核心的几张表做逐行比对。第一批切换前我们花了三个晚上的时间做校验和演练才敢在正式切换窗口动手。5. 常见问题与排查经验项目里真实踩过的坑5.1 高频问题速查对照表就能解决大部分问题部署和适配过程中我们遇到了一堆问题其中不少有代表性。我把高频问题整理成一张速查表方便同行们少走弯路。现象可能原因排查和处理方式集群部署后 CN 启动失败镜像架构不对x86 镜像跑到 ARM检查镜像架构换对应 ARM 版本连接后执行 SQL 报“多分片路由失败”分区键没有作为查询条件为常用查询字段增加全局二级索引压测时 TPS 上不去CPU 利用率低操作系统 CPU 调频模式为节能模式检查并调整为 performance 模式大数据量导入时速率慢目标表没有关闭自动增量同步或缺少批量参数导入前临时关闭 CDC 增量同步导入后恢复跨分片 JOIN 性能差关联字段未做协同分区使用分区对齐策略或改为应用层 join备份任务失败提示存储路径不存在备份目录权限或挂载路径不对检查备份目录的挂载和权限设置Oracle 迁移到目标库后日期字段差 8 小时时区参数不一致统一 PolarDB-X 时区为 Asia/Shanghai并设置 session 变量热点账户更新导致锁等待严重单账户所在分片并发过高拆分热点账户或通过异步队列削峰快速扩容后数据分布不均扩容策略未考虑数据倾斜使用分裂或重分布工具均衡分片5.2 复盘之后最想提醒后来者的三件事第一件分区键设计要提前做不要等上线前才改。分区键决定了数据的物理分布一旦上线再改就是一次数据重分布的大工程。我们后期有几张表因为最初分区键选得不好导致跨分片 JOIN 频繁性能和开发效率都受影响。分区键的选择要跟业务查询模式绑定优先选“查询频率高 分布均匀”的字段比如客户号、账号而不是订单号、时间字段。第二件不要把全文检索、复杂分析查询硬塞给分布式交易库。PolarDB-X 的定位是 OLTP 在线交易虽然也支持一定的分析能力但重分析的场景应该交给数仓或列存引擎。我们项目里一开始有人想把领导驾驶舱的报表直接跑在核心库上生成的 SQL 复杂到人看了都头大性能和资源消耗全乱套。后来把这些报表场景全部剥离到单独的分析链路核心库的计算压力降了 60% 以上。第三件切换方案要准备了再准备回切也要演练。我们主流方案是Oracle 库作为备库继续保留PolarDB-X 作为新主库承接生产流量数据通过双向同步或者单向实时同步保持两侧一致。因为做足了回切预案第一次切换时遇到一个下游系统连不上新库的兼容问题我们果断触发回切整个过程业务影响控制在 15 分钟内。这个 15 分钟不是赌来的是反复演练出来的。5.3 关于团队协作和项目节奏也说几句实在话这类项目技术选型和部署只是前 20% 的工作量剩下 80% 的时间都消耗在业务适配、数据迁移联调、性能调优和信创兼容验证上。项目排期一定要给足缓冲尤其是信创适配这块供应商承诺的兼容性和实际环境的表现经常有差距需要大量时间去验证和推动解决。跨团队协作的沟通成本也比想象的更高。数据库团队、应用开发团队、运维团队、信创厂商、硬件厂商五个团队之间如果有一个人没对齐就可能造成连锁返工。我们的做法是每周固定开一次技术评审会把架构变更、参数调整、问题单都放到会上同步避免各做各的。另外有一点容易被低估文档建设。我们整个项目下来产出了厚厚一沓文档包括环境规划手册、部署操作手册、参数配置基线、高可用演练报告、信创适配矩阵、数据迁移手册、切换方案和回切方案。这些文档在项目初期可能看不见价值但在问题排查和后续运维中价值不可估量。坚持把每一步操作、每一个关键决策和决策理由都记录下来等半年后再看你会感谢当时的自己。最后再聊一个很实际的小技巧在整个实施周期里建议把生产环境的“黄金配置”单独打成一份基线文档。PolarDB-X 的参数非常多我们在测试环境调过无数次每次调完就记录一次。到了上线前这份基线文档直接变成了交付物运维团队拿到之后可以照着配不用再从零摸索。如果你也在做类似的项目尽早开始积累这份基线别等到上线前才临时抱佛脚。
金融核心系统替换数据库这两年在我们这个圈子里基本是绕不开的话题。我上季度全程参与了一个银行客户的核心系统架构改造项目从最开始的选型到私有化环境下把 PolarDB-X 企业版集群拉起来再一路折腾到信创硬件栈适配和存量数据迁移整个过程踩坑不少但也把这条链路跑通了。这篇文章就是围绕“PolarDB-X 私有化部署 信创适配”这件事把技术选型逻辑、部署实施路径和迁移切换的实操经验梳理出来给正在做同类评估的朋友一个参考。我先把结论放在前面金融核心系统的数据库替换难点从来不在数据库本身能不能用而在于你怎么从集中式架构平稳过渡到分布式架构以及怎么在国产化软硬件栈上把这个分布式数据库跑稳。PolarDB-X 企业版在这条路上是个比较讨巧的选择因为它 MySQL 兼容性好分布式能力是原生的又能私有化交付下面我具体展开说。1. 金融核心系统换数据库难在哪儿1.1 银行保险这类核心系统为什么突然要动数据库金融行业的核心系统跑的无非是账务、清结算、客户信息、保单、交易流水这类最关键的数据过去二三十年基本被集中式数据库统治着。集中式架构的好处是成熟、稳定、好运维但坏处也明确扩展能力有限制单机性能和容量到顶之后只能往上堆硬件成本越来越高。最近几年核心系统替换的驱动力来自两个方向。一个是从业务侧冒出来的互联网化之后交易量峰值变得忽高忽低大促、秒杀、营销活动带来的流量冲击集中式架构很难弹性应对。另一个是从基础设施侧推过来的国产化替代的浪潮把“自主可控”提到了日程上核心系统底层依赖的数据库、操作系统、服务器都需要国产化。两股力量叠加在一起就给数据库选型提出了一个非常现实的命题有没有一款数据库既能满足金融级的高可用和强一致要求又能平滑替换掉原来那套老库还能在国产硬件和操作系统上跑起来。我当时涉及的项目源端是一套跑了十年的 Oracle RAC承载着银行核心账务和总账系统每天交易量在千万级高峰期单日流水好几亿条。这样的规模说大不大但集中式已经明显吃力了。替换数据库的优先级排得很高决定性的因素反而不是性能而是架构演进和信创合规这两个硬约束。1.2 选型评估时锁定的四条硬指标数据库选型如果不立几条硬指标后面一定会被厂商的销售和架构师带偏。我们整个选型周期大概持续了两三个月横向对比了市面上主流的几款国产分布式数据库包括原生分布式和中间件分库分表方案最后把筛选条件收敛成了四条。第一条是兼容性。这个兼容性不是指能跑通几条标准 SQL而是业务侧几万条存量 SQL 不改或者少改。我们源端是 OracleSQL 方言差异很大如果选型时对 MySQL 兼容的库至少还能通过改驱动和少量 SQL 改写来过渡如果选一个语法差异大的数据库改造工作量会大到不可接受。PolarDB-X 兼容 MySQL 协议这一点占了大便宜因为很多业务代码本身就是从 MySQL 迁过来的改造成本低。第二条是分布式事务能力。核心系统跨节点的事务非常多账户扣减、总账登记、流水记录往往在一个事务里要操作多张表。老办法是用中间件做分库分表但跨库事务要么不支持要么用最终一致性方案对强一致敏感的账务系统来说根本不现实。PolarDB-X 原生支持分布式事务基于全局时钟和两阶段提交机制账务场景下保证强一致这是我们敢选它的根本原因。第三条是高可用和容灾能力。金融系统对 RTO/RPO 的要求通常非常苛刻核心系统要求秒级或分钟级恢复数据零丢失。PolarDB-X 企业版的三副本机制、同城两中心部署、跨机房容灾能力可以满足这个要求。私有化部署下数据可靠性和容灾必须自己验证不能光看宣传材料。第四条是信创栈适配。这一点很多选型团队会忽略等买回来才发现跑不到国产 CPU 上。我们当时直接拉了一张信创适配清单把服务器鲲鹏、海光、操作系统麒麟、统信、中间件、办公终端的组合都列了出来要求厂商逐一给出验证结论或者现场测试。PolarDB-X 企业版在这块已经积累了比较完整的适配矩阵这也是它进入最终候选名单的原因之一。2. PolarDB-X 企业版技术底子在什么水平2.1 从 DRDS 到 PolarDB-X架构到底长什么样PolarDB-X 最早源自阿里内部的分布式中间件 DRDS分布式关系数据库服务后来逐步演进成一套自研的原生分布式数据库。如果只看表面它跟 MySQL 长得几乎一样能兼容 MySQL 8.0 协议用户拿 MySQL JDBC 驱动就能连。但往里面拆它不是单机 MySQL而是由多个组件组成的分布式集群。核心组件有这么几类。计算节点 CNCompute Node负责接收 SQL、生成执行计划、做分布式计算你可以理解成它是“大脑”对上暴露 MySQL 协议对下负责数据路由。存储节点 DNData Node是真正存数据的地方每个 DN 负责一部分数据分片支撑在线事务处理。元数据服务 GMSGlobal Meta Service负责管理全局元数据、生成全局事务时间戳、维护表结构和分布式拓扑。日志节点 CDCChange Data Capture相当于分布式版的 Binlog 组件负责捕获数据变更并投递给下游链路比如同步到数仓或另一套数据库做灾备。这套架构最核心的设计是存储与计算分离的形态。计算节点可以横向扩展存储节点也可以横向扩展两者独立扩容。业务流量增长的时候加 CN 提升并发处理能力数据量增长的时候加 DN 扩展存储容量。更重要的是计算和存储分离后扩缩容可以通过调度软件自动完成不像老架构那样得手工做数据搬迁。2.2 企业版对比社区版/标准版钱花在哪里PolarDB-X 有开源版本也有商业化的企业版。开源版在社区里很活跃能拿来学习和搭测试环境但真拿到金融核心系统这种场景里直接用还是差点意思。企业版跟社区版比差异不只是在服务支持上而是在内核能力、管控平台、运维工具上做了一整套增强。最直观的差别是可控性。企业版提供了完整的管控面包括集群部署、扩容缩容、参数配置、监控告警、日志采集、备份恢复等能力全部集成在一个控制台上。核心系统最怕黑盒出了问题要能快速定位企业版在可观测性上做得明显更完整比如提供了 SQL 审计、慢查询分析、分布式事务统计这类专业工具而社区版基本要靠自己手工搭一套监控和日志体系。企业版的另一个价值是在内核稳定性上。金融场景对某些边界条件的处理要求非常高比如大批量写入、大事务、长连接、热点更新、数据倾斜等。企业版针对这些场景做了大量的内核参数调优和稳定性增强这些优化很多没有完全同步到社区版。另外企业版还带了专门的数据迁移和校验工具以及针对源端为 Oracle 和 MySQL 的兼容性增强这些在替代项目中特别实用。2.3 分布式事务、全局索引和透明访问这三个能力必须吃透如果只挑三个技术点来理解 PolarDB-X我会选分布式事务、全局二级索引和透明访问。这三个点直接决定了你能不能把业务迁上来以及迁上来之后跑得好不好。分布式事务这块PolarDB-X 采用全局时间戳TSO方案。GMS 统一分配递增的时间戳各个节点基于这个时间戳做 MVCC 多版本并发控制加上两阶段提交协议实现跨节点事务的原子性和隔离性。简单理解就是所有节点对事务发生的先后顺序有一个统一的时钟标准这样不需要在业务代码里做任何分布式协调事务执行就像在单机上一样干净。跟我们以前用 Seata 那种柔性事务方案的体验完全不同代码不用改强一致也保住了。全局二级索引解决的是另一个痛点。分库分表之后如果你只用主键查询路由很明确。但业务查询往往不是只按主键来的比如用户表按手机号分片却经常要用身份证号查用户如果没有全局索引只能全表扫描所有分片。PolarDB-X 的 GSI全局二级索引会把索引单独组织成分片自动维护索引和数据之间的一致性查询时按索引键直接路由到对应分片性能和单机索引基本没区别。透明访问这个词听着玄其实理解起来不难。分布式数据库最大的麻烦是用户得知道自己的数据存在哪个分片。PolarDB-X 的设计目标是让用户完全感知不到分片的存在写入时自动路由读取时自动合并。尤其是企业版做了一张“分区表”和“分区算法”的灵活组合可以对超大表自动分区对业务透明不需要在 SQL 里手工指定分片键。这让我们从单机 MySQL 迁过来的变更变得非常平滑。3. 私有化部署实操从硬件评估到集群初始化3.1 部署前的硬件和容量规划别等装一半才想起来算私有化部署最忌讳的就是什么都不想直接在测试环境上开装。我们一开始就定了一条规矩先做容量规划再碰安装包。容量规划要算清楚三个数——峰值 TPS、数据总量、保留时长。先看 TPS。核心账务系统的高峰 TPS 大概在 8000 到 10000 左右还有一批批处理任务比如日终跑批对吞吐要求更高。按单台 CN 能扛住 2000 到 3000 TPS 来估算预留 30% 的冗余我们配了 4 个 CN 节点每个 8C16G。这条经验值仅供参考真正的峰值能力要等压测之后才敢定先按这个量级排物理资源。再看数据量。源端 Oracle 生产库数据大概 4TB其中在线数据 1.5TB历史数据 2.5TB。分布式环境下数据量会略有膨胀因为要多副本和索引开销。我们按三副本算在线数据存储池至少要有 5TB 的可用容量再加临时表、日志、备份的空间存储节点的裸容量按在线数据的 3 倍规划也就是一个 15TB 起步的存储池。DN 节点规格我们选了 16C64G搭配 NVMe SSD每个 DN 管理的数据量控制在 1TB 以内预留足够的落盘空间和后台 compaction 的余地。网络规划同样重要。分布式数据库对节点间网络延迟非常敏感尤其是事务提交时的同步多副本之间有大量网络交互。我们的经验是分布式集群内部网络至少万兆最好是 25G 或更高交换机要支持数据中心级别的低时延特性。如果不是专用网络环境至少也要保证 CN 和 DN 之间是独立的网段不要和历史业务共用一套带宽争抢资源。3.2 搭建集群的完整步骤照着走一遍就能跑起来PolarDB-X 企业版的私有化部署官方推荐的方式是基于 Kubernetes 来部署通过 Operator 管理整个集群的生命周期。如果现场没有 K8s 环境也可以先搭一套独立的 K8s 集群再把 PolarDB-X 的集群作为应用部署进去。这里我以 K8s 方式为主线把步骤拆细。第一步是准备 K8s 集群。至少需要三台服务器作为 Master 节点若干台作为 Worker 节点。集群版本建议用厂商已验证过的版本不要图新用最新的 K8s兼容性问题会非常烦人。我们当时用的是 1.24 版本这个版本经过厂商和社区验证相对成熟。第二步是部署 PolarDB-X Operator。这是一个标准流程准备好镜像和 YAML 文件配置好镜像仓库地址执行kubectl apply -f operator.yaml就能把 Operator 装到 K8s 集群里。这一步没什么难点但建议把镜像提前上传到私有仓库避免现场拉不动公网镜像。第三步是配置存储。存储节点的数据目录需要挂载 PV持久化存储卷可以用本地存储、NFS 或分布式存储但金融场景下建议用本地 SSD 或企业级分布式块存储性能和可靠性都有保障。我们在 PV 的 StorageClass 里配置了 WaitForFirstConsumer 模式让存储卷分配到最合适的节点上避免跨机架存储。第四步是声明 PolarDB-X 集群的 CRD 资源。你需要写一个 YAML 文件声明 CN 数量、DN 规格、副本数等参数。这是一个最关键的配置文件我后面会单独讲核心参数。执行kubectl apply -f pxc-cluster.yaml之后Operator 会自动创建 StatefulSet 和 Pod把所有节点拉起来。第五步是等待集群就绪。用kubectl get pxc查看集群状态等状态变为 Running 之后通过kubectl get svc找到连接地址用 MySQL 客户端测试连接。如果这一步能正常连接并执行SELECT 1说明集群基本起来了。第六步是做基础配置。创建业务账号、初始化字符集为 utf8mb4、设置时区、配置资源组。这些都是老 DBA 非常熟悉的操作在 PolarDB-X 上通过 SQL 执行即可和管理单机 MySQL 的体验差别不大。3.3 初始化参数和高可用配置这些坑我提前帮你踩了集群拉起只是第一步能不能达到生产标准关键看参数细节。以下几个点我单独强调。副本数和可用区分布。金融场景建议至少三副本并且跨可用区或跨故障域部署。我们的方案是用两个可用区主副本和其中一个从副本在核心可用区第三个副本放到灾备可用区这样单可用区故障时还能保证数据不丢。这个设置在 CRD 里通过topology字段声明需要在部署前就规划好后面修改非常麻烦。分片初始数量。PolarDB-X 会按照你在建表时定义的分区规则把表拆成多个分片。这里有个新手常犯的错分片数不是越多越好。分片太多会导致元数据膨胀、事务协调开销变大分片太少又会出现单分片数据量过大。一条经验是初始分片数按未来 1 到 2 年的数据增长量来定单分片 500GB 左右比较合适。我们当时一张核心流水表预估三年到 1.2TB定了 4 个分片每个分片 300GB留了 30% 余量。连接数和参数优化。默认的线程池和连接数设置偏向保守在压测前要把max_connections、innodb_buffer_pool_size这些参数按节点规格提上来。还有一个非常隐蔽的参数是plan_cache分布式数据库有执行计划缓存如果设置太小会产生大量计划编译开销。我们在线业务并发高把这个参数调到了 4096。提示部署完成后一定要做一次全链路的高可用演练。把其中一个 DN 节点直接 kill 掉观察集群是否自动切换、TPS 是否发生抖动、数据有没有丢。这个问题我们当时压测中就暴露出来了不提前演练生产出问题就是事故。4. 信创适配要过的几道坎一样都不能省4.1 信创硬件和操作系统的兼容性验证清单信创适配是个系统工程数据库只是其中一环但它是整个栈里承上启下的核心。数据库必须能在信创 CPU 和信创 OS 上稳定运行上层应用才能适配。我们项目的目标栈是鲲鹏 920 和麒麟 V10 SP3这个组合在金融行业里算是主流之一。第一件要做的事是确认安装包和镜像的架构版本。PolarDB-X 企业版针对主流国产 CPU 都有对应的镜像和二进制包这也是私有化交付时一定要向厂商索要的资料。我们现场就是因为初期拿到的是 x86 的镜像在鲲鹏机器上差点没跑起来后来换了 ARM 版本才顺利部署。第二件事是操作系统层面的参数适配。麒麟 V10 基于开源 Linux 内核做了裁剪和修改有些数据库依赖的 kernel 参数、cgroup 配置可能默认没有开启。我们当时遇到一个很诡异的问题数据库在压测时 CPU 使用率上不去TPS 只有预期的一半。排查到最后发现是操作系统的 CPU 调频策略默认是节能模式内核的performance模式没有开启调整之后性能立马上来了。这类芝麻问题在 x86 环境很少出现但在国产 OS 上一定要提前检查。第三件事是完整的功能和性能验证。建议制定一个信创兼容性测试矩阵把基础功能、高可用、性能、安全、备份恢复都过一遍。测试矩阵至少要覆盖这些维度测试维度验证项结果要求基础功能SQL 语法兼容、事务、视图、存储过程全部通过高可用CN/DN 故障切换、数据一致性RPO0RTO 分钟级性能基准测试与真实业务压测达到业务峰值要求安全加密、审计、权限控制满足等保要求备份恢复全量 增量备份恢复演练数据完整可恢复4.2 应用中间件、驱动和监控运维工具的适配数据库本身跑通了还有一堆周边生态要适配。金融系统的应用多半跑在 Java 中间件上比如东方通、金蝶天燕这类国产中间件也可能跑在 Spring Cloud 或者自研框架上。连接 PolarDB-X 用的是 MySQL 协议所以 JDBC 驱动用 MySQL Connector/J 就能连接这是一大便利。但驱动和中间件的兼容性依然要做验证。一个常见坑是国产中间件内置的连接池实现可能比较陈旧和 MySQL 8.0 的认证插件不兼容。PolarDB-X 默认的认证方式跟 MySQL 8.0 一致老中间件可能只支持 mysql_native_password。我们的做法是在初始化时把认证插件兼容打开或者统一通过中间件侧的连接池配置来解决。监控运维工具的适配也不能拖到最后。信创环境下的监控体系一般用国产化的监控系统比如云平台自带的 Prometheus 生态。PolarDB-X 支持导出 Prometheus 格式的监控指标但需要确认监控模板和 Grafana 面板在国产 OS 上正常跑。另外备份工具也要适配数据量大的话备份流程要用磁带库或者备份一体机这些设备在信创环境里有没有对应驱动需要提前和备份厂商确认。我个人最深的感触是信创适配的绝大多数问题不是数据库本身造成的而是周边组件之间的兼容摩擦。所以一定要把适配工作时间拉长留出足够的问题排查空间千万别把信创适配看成一个周末能搞定的事。4.3 数据迁移从 Oracle 到 PolarDB-X 的一场硬仗数据库替换项目里最让团队焦虑的就是数据迁移。我们的源端是 Oracle 19c RAC几千张表里面还有大量存储过程、视图、触发器、序列。把这些全部搬到 PolarDB-X 上有两条路要打通结构迁移和数据迁移。结构迁移方面PolarDB-X 提供了兼容性评估工具可以扫描源端的元数据分析每个对象在目标端的兼容性。这个工具能帮你列出哪些对象可以直接迁移、哪些需要改写、哪些基本得重写。我们的实际情况是大约 70% 的表结构可以直接转换20% 需要调整类型映射剩下 10% 涉及复杂视图、物化视图和存储过程需要开发团队手工改写。类型映射是第一个容易踩坑的地方。Oracle 的 NUMBER 类型到 MySQL 体系往往映射成 DECIMAL但如果这张表数据量非常大DECIMAL 比 BIGINT 的存储和计算开销都要大。我们花了很大精力逐表分析。原则是金额字段保留 DECIMAL(18,2)流水号、主键这类整数型字段尽量用 BIGINT避免 DECIMAL 滥用。字符串方面Oracle 的 VARCHAR2(4000) 会映射成 VARCHAR(4000)如果字段实际长度不超过 255建议用 VARCHAR(255) 以降低索引开销。数据迁移工具上我们用了 PolarDB-X 企业版配套的数据传输组件它支持从 Oracle 和 MySQL 做全量和增量迁移。全量迁移用批量抽取增量迁移基于日志解析。迁移流程分三步先做全量同步再做增量追平最后在切换窗口内做短暂停业把最后一小段增量追上来然后切换流量。校验环节不能省略。我们的做法是全量校验加抽样校验双重验证行数比对、主键 checksum 比对、抽样业务报文比对。这里有一个经验如果数据量大全表 checksum 会非常慢可以先按分片并行比对再对最核心的几张表做逐行比对。第一批切换前我们花了三个晚上的时间做校验和演练才敢在正式切换窗口动手。5. 常见问题与排查经验项目里真实踩过的坑5.1 高频问题速查对照表就能解决大部分问题部署和适配过程中我们遇到了一堆问题其中不少有代表性。我把高频问题整理成一张速查表方便同行们少走弯路。现象可能原因排查和处理方式集群部署后 CN 启动失败镜像架构不对x86 镜像跑到 ARM检查镜像架构换对应 ARM 版本连接后执行 SQL 报“多分片路由失败”分区键没有作为查询条件为常用查询字段增加全局二级索引压测时 TPS 上不去CPU 利用率低操作系统 CPU 调频模式为节能模式检查并调整为 performance 模式大数据量导入时速率慢目标表没有关闭自动增量同步或缺少批量参数导入前临时关闭 CDC 增量同步导入后恢复跨分片 JOIN 性能差关联字段未做协同分区使用分区对齐策略或改为应用层 join备份任务失败提示存储路径不存在备份目录权限或挂载路径不对检查备份目录的挂载和权限设置Oracle 迁移到目标库后日期字段差 8 小时时区参数不一致统一 PolarDB-X 时区为 Asia/Shanghai并设置 session 变量热点账户更新导致锁等待严重单账户所在分片并发过高拆分热点账户或通过异步队列削峰快速扩容后数据分布不均扩容策略未考虑数据倾斜使用分裂或重分布工具均衡分片5.2 复盘之后最想提醒后来者的三件事第一件分区键设计要提前做不要等上线前才改。分区键决定了数据的物理分布一旦上线再改就是一次数据重分布的大工程。我们后期有几张表因为最初分区键选得不好导致跨分片 JOIN 频繁性能和开发效率都受影响。分区键的选择要跟业务查询模式绑定优先选“查询频率高 分布均匀”的字段比如客户号、账号而不是订单号、时间字段。第二件不要把全文检索、复杂分析查询硬塞给分布式交易库。PolarDB-X 的定位是 OLTP 在线交易虽然也支持一定的分析能力但重分析的场景应该交给数仓或列存引擎。我们项目里一开始有人想把领导驾驶舱的报表直接跑在核心库上生成的 SQL 复杂到人看了都头大性能和资源消耗全乱套。后来把这些报表场景全部剥离到单独的分析链路核心库的计算压力降了 60% 以上。第三件切换方案要准备了再准备回切也要演练。我们主流方案是Oracle 库作为备库继续保留PolarDB-X 作为新主库承接生产流量数据通过双向同步或者单向实时同步保持两侧一致。因为做足了回切预案第一次切换时遇到一个下游系统连不上新库的兼容问题我们果断触发回切整个过程业务影响控制在 15 分钟内。这个 15 分钟不是赌来的是反复演练出来的。5.3 关于团队协作和项目节奏也说几句实在话这类项目技术选型和部署只是前 20% 的工作量剩下 80% 的时间都消耗在业务适配、数据迁移联调、性能调优和信创兼容验证上。项目排期一定要给足缓冲尤其是信创适配这块供应商承诺的兼容性和实际环境的表现经常有差距需要大量时间去验证和推动解决。跨团队协作的沟通成本也比想象的更高。数据库团队、应用开发团队、运维团队、信创厂商、硬件厂商五个团队之间如果有一个人没对齐就可能造成连锁返工。我们的做法是每周固定开一次技术评审会把架构变更、参数调整、问题单都放到会上同步避免各做各的。另外有一点容易被低估文档建设。我们整个项目下来产出了厚厚一沓文档包括环境规划手册、部署操作手册、参数配置基线、高可用演练报告、信创适配矩阵、数据迁移手册、切换方案和回切方案。这些文档在项目初期可能看不见价值但在问题排查和后续运维中价值不可估量。坚持把每一步操作、每一个关键决策和决策理由都记录下来等半年后再看你会感谢当时的自己。最后再聊一个很实际的小技巧在整个实施周期里建议把生产环境的“黄金配置”单独打成一份基线文档。PolarDB-X 的参数非常多我们在测试环境调过无数次每次调完就记录一次。到了上线前这份基线文档直接变成了交付物运维团队拿到之后可以照着配不用再从零摸索。如果你也在做类似的项目尽早开始积累这份基线别等到上线前才临时抱佛脚。
