---
title: "PostgreSQL 迁移至 OceanBase MySQL 兼容模式的最佳实践 - OceanBase 最佳实践 | OceanBase 文档中心"
description: PostgreSQL 迁移至 OceanBase MySQL 兼容模式的最佳实践 随着业务系统规模扩大，传统单机或主备架构逐渐难以满足高可用性、弹性扩展和成本控制的综合需求。OceanBase 提供 MySQL 兼容模式，在分布式架构、高可用能力以及存储压缩方面具备明显优势，成为 PostgreSQL 用户进行数据库…
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

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

更新时间：2026-07-28

[编辑](https://github.com/oceanbase/best-practices-doc/edit/master/zh-CN/300.migrations/700.pg-obmysql.md) 适用产品： OceanBase 数据库 适用场景： 数据迁移及导入  

随着业务系统规模扩大，传统单机或主备架构逐渐难以满足高可用性、弹性扩展和成本控制的综合需求。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 输出的评估报告示例：

```sql
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 提供的标准流程，整体分为以下几个阶段：

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

上述流程已在多个生产场景中得到验证，能够在保障数据一致性的同时，支持低风险切换与快速回滚。具体的实施步骤与参数配置可参考官方文档：[迁移 PostgreSQL 数据库的数据至 OceanBase 数据库 MySQL 兼容模式](https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000004023027)。

#### 说明

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

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

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

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

| 问题点 | 问题描述 | 解决方案 |
| --- | --- | --- |
| 自增列不生效 | PostgreSQL 中的 int 自增列在迁移后未自动递增。 | 经实践确认，自增列未生效主要有两类原因：   1. PostgreSQL 使用 nextval() 实现自增，当前 OMS 版本未自动转换；OMS 4.3.2 版本起将支持将该模式自动转换为 AUTO_INCREMENT。 2. 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 已开启 wal_level=logical
 - 迁移用户具备 REPLICATION 及必要权限
 - 所有迁移表设置 REPLICA IDENTITY FULL
 - OMS 已配置心跳表写入权限
 - 目标端无同名表冲突
 - 自增列、默认值、分区表已完成适配方案确认
 - 应用 SQL 与 JDBC 参数已完成兼容性调整
 - 反向增量同步链路已验证可用

## 总结

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 |

 上一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线