前言

YMatrix 与 Greenplum 兼容性是 100%，在保障业务“无感切换”的前提下，于维护窗口内把 Greenplum 全量/增量搬到 YMatrix。

MatrixShift 采用 Segment-to-Segment 并行架构，充分“吃满”集群带宽与算力，相比 pg_dump/pg_restore/gpcopy 等传统方案，迁移更快、更稳、更可控。

01MatrixShift 是什么？

MatrixShift 是一款面向 Greenplum / YMatrix → YMatrix 的整库迁移工具，用于把 Greenplum 数据库平滑迁移至 YMatrix。相比 pg_dump 等传统方案，MatrixShift 采用 Segment-to-Segment 的并行迁移架构，最大化利用源端与目标端的资源，显著提升迁移速度。

当前已支持的能力

• 全量迁移：以数据库为单位，从 Greenplum/YMatrix 集群并行迁移目标数据库的表结构（DDL）与数据至新的 YMatrix 集群；

• 增量迁移：以表为单位，从 Greenplum 5/6/7 或 YMatrix 集群并行迁移新增表的 DDL 与数据至新的 YMatrix 集群；

• 条件迁移：支持通过 WHERE 子句进行数据的条件迁移；

• 数据分布策略：支持哈希分布、随机分布、复制表（REPLICATED）以及 Master-only。

目前支持如下数据库：

注：不同版本的对象类型与扩展支持范围以实际工具版本发布说明为准。

02为什么选择 MatrixShift？

在 Greenplum 走到性能天花板、或需要统一 OLAP 技术栈到 YMatrix 时，如何在短维护窗口内完成整库迁移、并确保业务无感？传统 pg_dump/pg_restore 往往受制于单点瓶颈、网络带宽利用率低、需要额外的空间来临时存储数据等问题，迁移时间较长，迁移窗口相对不可控。

MatrixShift 的优势

• 高并行：Segment-to-Segment 传输，利用各 Segment 的计算力与所在服务器带宽；

• 高可控：可按库/表维度拆分批次，支持条件迁移、增量迁移与并发重建索引；

• 高可靠：行数+哈希双重校验，失败可断点续传，保证数据一致性。

功能对比

gpcopy 是 Greenplum 生态中用于整库迁移的工具。

性能对比

在实际场景中，gpcopy 有一个影响迁移速度的缺陷，即先跑 DDL（包含创建索引），然后迁移数据，这会影响数据的迁移速度，并会让索引大小膨胀。

测试信息如下：带索引的分区表，总大小 30G，互联带宽是 1000 Mbps，并行度设置为 8。

表信息如下： 

可以看出来 mxshift 在迁移过程中相较于 gpcopy 性能更优，策略更好。

总结：mxshift 相较于其他的迁移工具，策略更优，配置项更丰富，性能更好。

03MatrixShift 能跑多快？

研发团队陆陆续续针对 MatrixShift 做了一些性能测试，然而由于产品随着项目实施不断改进，所以 MatrixShift 的性能上限是 ----- 未测得。

至于“未测得”的原因，是因为软件性能总是受限于硬件性能水平，这里主要指 CPU，网络 IO，和硬盘 IO。在目前的项目实施过程中， MatrixShift 总是能将其中一项资源的利用到 100% 的水平，也就是这项资源成为了性能瓶颈；而如果能够继续提升这项资源的能力，那么 MatrixShift 的效率还能进一步提升。

以下是部分项目迁移速度：

04实战案例｜某钢铁厂迁移实战

背景与目标

• 原平台：Greenplum 6.16.2，查询性能偏慢、压缩率较低；生产数据约 2 TB，两个 Segment 主机，每个 Segment 主机部署了两个 Primary ，每个 Segment 主机挂载一块数据盘，磁盘最大顺序读写速度 200 MB/s，内网有效带宽约为 2.5 Gbps。

• 目标平台：YMatrix 6.4.1，两个 Segment 主机，每个 Segment 主机部署两个 Primary，磁盘最大顺序读写速度为 200 MiB/s，内网有效带宽 2.5 Gbps

• 迁移目标：本次迁移，磁盘速度拖累整体的迁移速度，客户期望在 ≤ 6 小时的维护窗口内整库迁移至 YMatrix，业务无感切换，并显著改善查询性能与存储成本。

方案

• 架构与工具：MatrixShift Segment-to-Segment 并行迁移，充分利用各节点带宽与算力。

• 迁移策略：先迁数据与表定义，索引在数据落盘后并发重建，避免迁移阶段写放大与索引膨胀。

• 校验与切换：基于行数与哈希的双重校验，窗口内完成连接切换与关键报表回归。

实施与结果

• 用时：约 2 小时完成 2 TB 数据迁移与校验，整体切换在窗口内顺利收口，显著压缩停机时间。

• 性能与成本： 业务典型查询性能提升 100-500%（依查询类型与数据模型而定）； 压缩率明显提升，存储占用约为原本的 1/10。

• 业务影响：切换过程对上层系统基本无感，生产报表与接口按期出数。

说明：以上为单个项目结果，实际表现取决于数据规模、网络链路、对象复杂度与并行策略等因素。

05如何使用

首先准备一份 mxshift 的配置文件，示例如下：

## 数据库配置
[database]
        ## 源数据库配置
        [database.source]
        ## 数据库名称
        db-database= "testdb"
        ## 数据库主机名
        db-host="sdw3"
        ## 数据库密码
        db-password="xxxx"
        ## 数据库端口
        db-port=54322
        ## 数据库用户名
        db-user="gpadmin"
        ## 数据库安装目录
        install-dir="/usr/local/greenplum-db-6.7.1"

        ## 目标数据库配置
        [database.target]
        ## 数据库名称
        db-database="destdb"
        ## 数据库主机名
        db-host="172.16.100.32"
        ## 数据库密码
        db-password="yyyy"
        ## 数据库端口
        db-port=5432
        ## 数据库用户名
        db-user="mxadmin"
        ## 数据库版本（请使用 'SELECT version();' 的结果作为值）
        db-version="PostgreSQL 12 (MatrixDB 6.5.0-enterprise) (Greenplum Database 7.0.0+dev.17410.gedbdb5ef84 build dev) on arm-apple-darwin21.5.0, compiled by Apple clang version 13.0.0 (clang-1300.0.27.3), 64-bit compiled on Sep  5 2025 15:45:24"

## 迁移范围配置
[scope]
## 是否禁用连接器
disable-connector=false
## 数据传输压缩方法，可选值：0/gzip/lz4/zstd
compress-method="zstd"
## 数据传输模式，可选值：normal/dryrun/fetch/motion
## normal: 正常模式，完整迁移数据
## dryrun: 仅执行DDL，不传输数据
## fetch: 从源数据库获取数据后丢弃
## motion: 从源数据库获取数据，重新分发后丢弃
mode="normal"
        ## 包含的表列表
        [[scope.table-list]]
                schema="test_schema_1"
                name="table_001"
        [[scope.table-list]]
                schema="test_schema_2"
                name="table_002"
        ## 排除的表列表
        [[scope.exclude-table-list]]
                schema="test_schema_3"
                name="table_003"
## 包含的schema列表
schema-list=["test_schema_1", "test_schema_2"]
## 排除的schema列表
exclude-schema-list=["test_schema_5", "test_schema_8"]

## 日志配置
[log]
## 日志级别，可选值：debug/verbose/info
log-level="info"

## 控制器配置
[controller]
## 是否双向传输，默认从最大表开始，设置为true时同时从最大和最小表开始
both-way=true
## 并发传输表的数量
concurrency=3

## 传输配置
[transfer]
## 是否验证每个表的记录数
verify=true
## 是否传输索引
with-index=true

## DDL配置
[ddl]
## 是否启用DDL迁移
enabled=true
## 是否仅迁移DDL
only-ddl=false
        ## DDL替换配置
        [[ddl.replace]]
         ## 替换表 owner
                category="role"
                ## 替换规则
                [[ddl.replace.pairs]]
                        old="gpadmin"
                        new="mxadmin"

## 验证配置
[verify]
## 是否启用数据验证
enabled=true
## 行数校验模式
mode="simple-count"

mxshift 的配置文件用于定义源数据库与目标数据库的信息，并控制迁移过程中的行为。例如：

• 仅迁移指定的 schema，或排除某些 schema；
• 是否连同索引一并迁移；
• 设置迁移并行度；
• 配置 DDL 替换（DDL Replace），如调整表的 owner、目标 schema 等；
• 仅导出 DDL，或仅迁移数据；
• 细粒度配置数据校验策略。

通过上述配置，mxshift 可灵活满足不同场景下的数据库迁移与校验需求。

当配置完成后使用如下命令即可启动 mxshift 开始迁移工作

mxshift -c config.toml

在 mxshift 迁移过程中，可以在另一个会话中使用如下参数来查看迁移进度。

mxshift -c config.toml -I

对于 mxshift 来说，如果源数据库和目标数据库的拓扑结构一致，那么源数据库 Segment 1:1 映射到目标数据库的 Segment。

那如果拓扑结构不一致呢？mxshift 会统计两者差异，最后计算一个比例，将源端数据按照 Segment 等比例映射过去，映射示例图如下：

06 FAQ

1. 迁移支持的对象有哪些？

表、分区表、索引、视图、序列、函数、权限等均可纳入清单；具体以工具版本发布说明为准。

2. 迁移过程中可以动态调整并发度吗？

可以，当在配置文件调整并发度以后，可以发 reload 信号，让 mxshift reload 即可修改并行度。

3. 如何查看迁移进度？

在 mxshift 提供了查看迁移进度的参数，可以清晰的看到迁移进度；日志中也包含了进度信息。