PostgreSQL 迁移至 OceanBase MySQL 兼容模式的最佳实践

随着业务系统规模扩大，传统单机或主备架构逐渐难以满足高可用性、弹性扩展和成本控制的综合需求。OceanBase 提供 MySQL 兼容模式，在分布式架构、高可用能力以及存储压缩方面具备明显优势，成为 PostgreSQL 用户进行数据库架构升级的重要选择。本文基于某保险行业核心业务系统的真实迁移案例，总结从 PostgreSQL 迁移至 OceanBase MySQL 兼容模式过程中需要重点关注的技术差异、风险点及应对策略，形成一套可复用的迁移实践参考。

迁移案例概述

本次迁移对象为某保险行业订单中台系统，其数据库承载核心交易与订单数据，对系统稳定性和数据一致性要求极高。迁移需在保证业务连续性的前提下完成，并支持快速回滚能力。本次迁移涉及到的数据规模与对象范围如下：

源端数据库：PostgreSQL 13.2
数据规模：约 8 TB，约 5 亿行
迁移表数量：30+ 张
分表合并为单表：10+ 张

说明

原 PostgreSQL 业务中同一逻辑表按规则拆分为多张结构一致的物理表（如 `table_0`、`table_1`、...、`table_n`），迁移至 OceanBase MySQL 兼容模式时，将这些分表数据统一合并至单一目标表进行存储与管理。
分区表：5+ 张
普通表：10+ 张

迁移过程中既包含普通业务表，也涉及分区表以及历史分表合并为单表的场景，对迁移方案的完整性与适配能力提出了较高要求。

迁移评估：明确改造成本与风险边界

在启动 PostgreSQL 向 OceanBase MySQL 兼容模式的迁移前，需对数据库对象的兼容性与改造风险进行评估，以降低迁移过程中的不确定性。本案例中，通过 OceanBase 提供的迁移评估工具 OMA，对源端 PostgreSQL 数据库中的表、索引、视图、序列、存储过程等对象进行自动化评估。用户仅需提供数据库连接信息，即可生成数据库对象兼容性评估报告。

以下为 OMA 输出的评估报告示例：

SCHEMA : test    评估耗时 : 47895 ms

+-------------------------------------------------------------------+
| schema: schema  | source: sourceDB      | target: targetDB      |
+-----------------+---------+---------+---------+---------+---------+
| Object Type     | pass    | convert | failure | total   | percent |
+-----------------+---------+---------+---------+---------+---------+
| TABLE           | 186     | 0       | 1       | 187     | 99.5%   |
| PROCEDURE       | 4       | 0       | 0       | 4       | 100.0% |
| TRIGGER         | 0       | 0       | 1       | 1       | 0.0%   |
| PACKAGE         | 1       | 0       | 0       | 1       | 100.0% |
| SEQUENCE        | 2       | 0       | 0       | 2       | 100.0% |
| INDEX           | 127     | 0       | 0       | 127     | 100.0% |
| VIEW            | 9       | 0       | 0       | 9       | 100.0% |
| PACKAGE BODY    | 1       | 0       | 0       | 1       | 100.0% |
+-------------------------------------------------------------------+

说明

上述评估结果仅用于展示 OMA 的评估能力和报告形式，非本案例真实生产数据。实际结果以用户自身数据库评估结果为准。

通过该评估报告可快速了解不同对象类型的整体兼容情况，并识别需要人工处理的对象，为迁移方案制定提供参考。

同时需要注意的是，OMA 当前针对 PostgreSQL 的评估范围仅限于数据库对象层面，不包含应用侧 SQL 语句的兼容性分析。因此，在迁移评估阶段，除通过 OMA 进行对象兼容性评估外，还需同步开展应用 SQL 的兼容性分析，为后续迁移实施和适配改造提供稳定、可控的输入条件。

迁移实施总体思路

本案例在正式执行迁移前，通过充分的准备与校验，确保迁移过程可控、可回滚，并将业务影响降至最低。整体迁移流程采用 “准备 → 迁移 → 校验 → 切换” 的实施思路。

迁移前准备工作

迁移前准备是保障迁移顺利实施的前提，主要包括环境准备、权限配置以及同步前置条件确认。

环境准备

在本案例中，源端、目标端及迁移工具环境满足如下基本要求：

类别	要求
源端 PostgreSQL	版本 ≥ 10.x wal_level 设置为 logical，以支持逻辑复制集群大小为 64C * 6，并采用双活 + 主备 + 灾备部署，具备较高可用性
目标端 OceanBase	创建 MySQL 兼容模式租户集群大小为 96C * 4，采用多 Zone 部署，满足高可用与扩展性要求
迁移工具（OMS）	使用 OMS v4.2.5 BP1 集群化部署支持结构迁移、全量迁移、增量同步、数据校验及反向同步能力

用户权限与同步前置条件
- 源端 PostgreSQL 迁移用户需有数据库访问权限，并具备逻辑复制（REPLICATION）相关权限等必要权限。
- 目标端 OceanBase 需为 OMS 创建具备目标库访问权限的用户。

此外，为确保 UPDATE / DELETE 操作能够被正确同步，迁移表需满足复制标识（REPLICA IDENTITY）要求：

表需存在主键，或
设置 REPLICA IDENTITY = FULL

在实践中，建议对所有迁移表统一开启 FULL 模式，以避免增量同步阶段出现数据缺失问题。

迁移实施流程概述

本案例的迁移实施采用 OMS 提供的标准流程，整体分为以下几个阶段：

结构迁移：由 OMS 自动迁移基础表结构、索引等对象；对于工具不支持的对象（如部分分区表），在目标端手动创建并调整。
全量迁移：将 PostgreSQL 中的历史数据一次性导入 OceanBase，并在此过程中持续拉取源端增量日志。
增量同步：基于 PostgreSQL WAL 日志进行实时同步，确保迁移期间源端与目标端数据持续一致。
数据校验：使用 OMS 内置校验能力，多轮比对源端与目标端数据，逐步消除差异。
切换与反向同步：在业务低峰期完成正向切换，该过程会产生一小段可控的业务停机时间。切换完成后开启反向增量同步链路，为回滚预留安全窗口。

上述流程已在多个生产场景中得到验证，能够在保障数据一致性的同时，支持低风险切换与快速回滚。具体的实施步骤与参数配置可参考官方文档：迁移 PostgreSQL 数据库的数据至 OceanBase 数据库 MySQL 兼容模式。

说明

在 PostgreSQL 迁移至 OceanBase MySQL 兼容模式的过程中，部分数据类型会发生映射或语义上的调整，例如：PostgreSQL BIGINT → OceanBase MySQL BIGINT、PostgreSQL BIGSERIAL → OceanBase MySQL BIGINT（结合 AUTO_INCREMENT 实现自增语义）。此类映射通常不会影响数据存储范围，但可能对自增行为、默认值或应用侧依赖逻辑产生影响，需在迁移完成后进行验证。完整的数据类型映射关系及说明，请参考本文附录：PostgreSQL 与 OceanBase MySQL 兼容模式数据类型映射表。

迁移过程中的适配与改造挑战及解决方案

本章结合实际迁移案例，重点总结 PostgreSQL 迁移至 OceanBase MySQL 兼容模式过程中，在机制差异、工具限制和运行行为方面需要重点关注的适配问题，并给出对应的处理建议。这些问题若在迁移前未充分评估，可能对数据一致性、业务稳定性和回滚能力产生影响。

Schema、自增列与数据类型转换

问题点	问题描述	解决方案
自增列不生效	PostgreSQL 中的 int 自增列在迁移后未自动递增。	经实践确认，自增列未生效主要有两类原因： PostgreSQL 使用 nextval() 实现自增，当前 OMS 版本未自动转换；OMS 4.3.2 版本起将支持将该模式自动转换为 AUTO_INCREMENT。 PostgreSQL 使用字符类型（如 VARCHAR）实现自增，该用法 OMS 暂不支持，需在目标端人工调整字段类型或自增逻辑。
时间字段默认值异常	`DEFAULT 'now'::text::...` 被迁移为普通字符串。	在当前版本中，需手动将默认值统一调整为 MySQL 兼容写法 `CURRENT_TIMESTAMP()`；后续 OMS 4.3.2 版本将补充对该类时间默认值的自动转换支持。
分区表无法直接迁移	源端 PostgreSQL 分区表需在 OceanBase 中重新定义。	在 OceanBase 侧手动创建分区表结构，再执行数据迁移。
不支持 DEFAULT USER	PostgreSQL 系统函数在 MySQL 模式下不可用。	改为使用静态默认值或通过触发器实现等效逻辑。

PostgreSQL 与 MySQL SQL 语法差异

问题点	问题描述	解决方案
函数与表达式差异	如 `uuid_generate_v4()`、`string_agg()` 等 PostgreSQL 特有函数在 MySQL 模式下不支持。	替换为 OceanBase MySQL 兼容模式支持的等价函数或写法。
Upsert 语法不兼容	PostgreSQL 的 `ON CONFLICT` 语法不可用。	改写为 `INSERT ... ON DUPLICATE KEY UPDATE` 实现相同语义。
`ON CONFLICT DO NOTHING` 不支持	MySQL 不支持对应语法。	使用 `INSERT IGNORE INTO` 实现“冲突时忽略”的行为。

同步机制相关问题

问题点	问题描述	解决方案
反向同步自增冲突	目标端自增列写入后，反向同步至 PostgreSQL 可能触发主键冲突。	在源端 PostgreSQL 取消自增限制：`ALTER TABLE ... DROP IDENTITY`，由 OceanBase 统一生成主键。
DDL 自动同步受限	OMS 在结构迁移与全量迁移阶段不支持部分 DDL 自动同步。	在迁移前后由人工同步 DDL 变更，避免迁移过程中执行结构调整。

字符集与大小写敏感性问题

问题点	问题描述	解决方案
双引号字段查询异常	使用 `"a"` 查询时行为与预期不一致。	统一采用小写、无引号字段名，避免依赖 PostgreSQL 标识符规则。
大小写敏感行为差异	PostgreSQL 默认区分大小写，OceanBase MySQL 模式默认不区分。	建表时显式指定 `CHARSET=utf8mb4 COLLATE=utf8mb4_bin`，确保大小写敏感一致。

其他迁移实践中的注意事项

问题点	问题描述	解决方案
多表写入单表的反向同步不支持	OMS 无法识别分表合并后的写入逻辑。	由应用层负责将目标端变更写回源端 PostgreSQL。
增量同步出现数据缺失	UPDATE 被拆分为 DELETE + INSERT，同步失败。	将表级复制标识统一设置为 `REPLICA IDENTITY FULL`。
JDBC 超时参数差异	PostgreSQL 使用秒，MySQL 使用毫秒。	调整应用侧连接参数，统一超时语义。

迁移后的验证与运行效果评估

数据一致性验证策略

为确保迁移数据的完整性与准确性，本次迁移采用多层验证策略：

OMS 内置全量校验工具，对表行数和字段值进行对比
多轮校验执行，逐步修复并收敛差异
对关键业务表进行人工抽样核查

在正式切换前，所有校验差异均已收敛至 0。

投产后运行情况

系统切换完成并稳定运行后，关键指标如下：

反向同步延迟：小于 5 秒
CPU 使用率：平均约 7%，峰值约 17%
QPS 峰值：12,616
TPS 峰值：12,285
存储占用：
- PostgreSQL 约 24 TB
- OceanBase 约 8 TB
- 压缩比约 1:3

迁移后系统运行稳定，未出现慢查询或异常事务。

可复用的迁移经验总结

关键成功因素

充分的前期评估：对象、SQL、权限、WAL 配置逐项确认
差异提前适配：自增、默认值、语法、分区策略提前改造
严格的数据校验：多轮全量校验结合人工抽查
平滑的切换机制：通过反向增量保障回滚能力
应用侧协同改造：SQL、连接参数、驱动配置同步调整

主要风险提示

OMS 不支持多表写入单表场景的反向同步
字符集与大小写差异可能引发业务逻辑异常
自增与序列处理不当易导致主键冲突

总结

PostgreSQL 迁移至 OceanBase MySQL 兼容模式是一项涉及数据库、工具、应用协同的系统工程。迁移成功的关键不在于“是否能够迁移”，而在于是否在迁移前充分识别差异、明确风险边界并提前做好适配。通过标准化迁移流程与关键问题前置控制，可以实现”数据零丢失、业务低中断、切换可回滚“的平滑迁移，为后续系统扩展和性能优化奠定基础。

附录：PostgreSQL 与 OceanBase MySQ 兼容模式数据类型映射表

PostgreSQL 数据库	OceanBase 数据库 MySQL 兼容模式
bigint	BIGINT
bigserial	BIGINT
bit [ (n) ]	BIT
boolean	TINYINT(1)
box	POLYGON
bytea	LONGBLOB
character [ (n) ]	CHAR LONGTEXT
character varying [ (n) ]	VARCHAR MEDIUMTEXT LONGTEXT
cidr	VARCHAR(43)
circle	POLYGON
date	DATE
double precision	DOUBLE
inet	VARCHAR(43)
interval [ fields ] [ (p) ]	TIME
json	LONGTEXT JSON
jsonb	LONGTEXT JSON
line	LINESTRING
lseg	LINESTRING
macaddr	VARCHAR(17)
money	DECIMAL(19,2)
numeric [ (p, s) ]	DECIMAL
path	LINESTRING
real	FLOAT
smallint	SMALLINT
smallserial	SMALLINT
serial	INT
text	LONGTEXT
time [ (p) ] [ without time zone ]	TIME
time [ (p) ] with time zone	TIME
timestamp [ (p) ] [ without time zone ]	DATETIME
timestamp [ (p) ] with time zone	DATETIME
tsquery	LONGTEXT
tsvector	LONGTEXT
uuid	VARCHAR(36)
xml	LONGTEXT
point	POINT
linestring	LINESTRING
polygon	POLYGON
multipoint	MULTIPOINT
multilinestring	MULTILINESTRING
multipolygon	MULTIPOLYGON
geometrycollection	GEOMETRYCOLLECTION
triangle	POLYGON
tin	MULTIPOLYGON