Cloudberry Database 作为 Greenplum 衍生版本和首选开源替代，由 Greenplum 原始团队成员创建，与 Greenplum 保持原生兼容，并能实现无缝迁移，且具备更新的 PostgreSQL 内核和更丰富的功能。
GitHub: https://github.com/cloudberrydb/cloudberrydb
GitHub 仓库：https://github.com/hashDataInc/cbcopy/
从今日起，大家可以访问 GitHub 仓库，获取 cbcopy 源代码以及快速使用指南，期待大家积极反馈使用过程中遇到的问题、以及期待的新增功能与优化。
背景
随着 Greenplum 走向闭源，Cloudberry Database 成为 Greenplum 的开源替代首选，同时众多开源 Greenplum 数据库用户也面临着将数据迁移至 Cloudberry Database 的迫切需求。部分用户会通过相关数据备份和恢复工具将数据先导出、再导入的方式进行数据迁移。然而，这种曲线方式的局限性在迁移数据量巨大时变得尤为突出——当数据量攀升至几 TB 乃至更高，迁移效率便成为了一个不容小觑的难题，往往耗时极长，甚至可能长达数天，这无疑给企业的业务连续性和数据管理能力带来了前所未有的挑战。
为了破解这一迁移瓶颈、提升迁移效率，我们推出了全新的开源数据迁移工具——cbcopy。cbcopy 专为解决大规模数据迁移中的效率难题而生，凭借其技术设计与深度优化，实现了 Greenplum 与 Cloudberry 之间数据的高效、稳定迁移。本文将剖析 cbcopy 的特点、功能及其在实际迁移场景中的表现，为正在寻求从 Greenplum 到 Cloudberry 数据迁移解决方案的社区成员提供参考。
什么是 cbcopy
cbcopy 是一款功能强大的数据迁移工具，支持将 Greenplum 数据库集群（包括元数据和数据）迁移到 Cloudberry 数据库集群，并支持在不同 Cloudberry 数据库集群之间进行数据迁移，从而满足灾难恢复、数据迁移以及特定版本升级等多种需求。cbcopy 具备高度的可扩展性、灵活性和性能优化能力，通过简化迁移流程、缩短迁移时间，cbcopy 助力用户实现业务连续性的最大化，同时降低迁移过程中的风险和成本。
cbcopy 支持从 Greenplum 4.x、5.x、6.x 迁移到 Cloudberry，并支持 Cloudberry 1.x 系列版本升级。
主要优势
更加稳定、高效的性能：相较于传统迁移工具，cbcopy 在迁移大数据量时表现更为出色，显著缩短迁移时间，降低迁移过程中的风险和成本。
灵活的架构设计：cbcopy 的架构设计兼顾灵活性与高效性，能够适配多样的迁移场景。无论是等量节点迁移、大集群至小集群的精简，还是小集群向大集群的扩展，cbcopy 都能通过智能的数据重分布机制，确保数据在新环境中的最优布局。
压缩传输，成本优化：cbcopy 内置多种高效压缩算法（如 snappy、zlib、zstd 等），有效减少传输数据量，降低对网络带宽的依赖。即使在带宽有限的环境下，也能保证迁移的高效与稳定，为用户节省宝贵的资源和成本。
智能的迁移策略：cbcopy 根据源集群的统计信息，智能判断表的大小，并选择最优的迁移策略。对于大表，利用计算节点的并行处理能力和通信带宽进行迁移；对于小表，则直接在 coordinator 节点之间传输数据。
工作原理
元数据迁移
cbcopy 的元数据迁移功能建立在 gpbackup 和 gprestore 的基础之上，与 GPDB 内置的 pg_dump 工具相比，cbcopy 展现出了显著的性能优势。其核心竞争力在于采用批量检索元数据的方式，而非 pg_dump 所使用的一行一行获取元数据的方法。这种批量处理方式，在迁移大量元数据时，能大幅度提升迁移效率。
数据迁移
在数据迁移方面，GPDB 和 CBDB 均支持通过 SQL 命令来启动程序，cbcopy 正是利用这一功能来实现高效的数据迁移。具体迁移过程中，cbcopy 会在目标数据库上启动程序以接收和加载数据，同时在源数据库上启动程序以卸载数据并将其发送到目标数据库的程序。
架构设计
cbcopy 的架构设计如下图所示，特别适用于源集群（如 Greenplum Database 集群）与目标集群（Cloudberry Database 集群）计算节点数量相同的情况。
由上图可以看到，cbcopy 架构设计直观明了，在源集群与目标集群的计算节点之间建立一一对应关系，直接实现数据的高效迁移，充分发挥所有计算节点的并行处理能力和通信带宽的优势。
cbcopy 内部支持三种表复制策略：
Copy On Coordinator：当表的统计值 pg_class->reltuples 小于 --on-segment-threshold 时，cbcopy 将采用此策略。这表示数据迁移仅限于通过协调节点在源数据库和目标数据库之间进行。
Copy On Segment：若表的统计量 pg_class->reltuples 大于 --on-segment-threshold，且源数据库与目标数据库版本相同且节点数量一致，cbcopy 将启用此策略。这意味着数据迁移将在所有 segment 节点上并行执行，无需数据重分布。
Copy on External Table：对于不满足上述两种策略条件的表，cbcopy 将采用此外部表复制策略。此策略下，数据迁移将在所有 segment 节点上并行执行并进行重分布。
功能实践
cbcopy 主要支持四种级别的数据库对象迁移：整个集群，指定数据库，指定命名空间和指定表。迁移过程包含两部分，首先是迁移元数据，也就是数据库对象的定义；其次是用户表数据的迁移。
集群迁移
复制
cbcopy --source-host=127.0.0.1 --source-port=15432 --source-user=cdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=cdw1 –full复制
| 参数项 | 说明 |
| source-host | 源集群的 coordinator 节点 IP 地址 |
| source-port | 源集群的 coordinator 节点端口号 |
| source-user | 连接源集群的用户名 |
| dest-host | 目标集群的 coordinator 节点 IP 地址 |
| dest-port | 目标集群的 coordinator 节点端口号 |
| dest-user | 连接目标集群的用户名 |
| full | 表示整集群迁移 |
数据库迁移
复制
cbcopy --source-host=127.0.0.1 --source-port=15432 --source-user=cdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=cdw1 --dbname="gpadmin" --truncate复制
重要参数说明：
| 参数项 | 说明 |
| dbname | 需要迁移的数据库名字 |
| truncate | 如果在目标集群数据库已存在同名表，则先执行truncate操作，清除已有数据 |
命名空间迁移
cbcopy --source-host=127.0.0.1 --source-port=15432 --source-user=cdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=cdw1 --schema="gpadmin.schema1" --truncate复制
| 参数项 | 说明 |
| schema | 需要迁移的命名空间 |
表迁移
将源集群的某些表迁移到另外一个集群，如果目标集群不存在同名表，则会创建新的表。以下为示意例子：
cbcopy --source-host=127.0.0.1 --source-port=15432 --source-user=cdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=cdw1 --include-table="gpadmin.public.aaa,gpadmin.public.bbb" --truncate复制
| 参数项 | 说明 |
| include-table | 需要迁移的表列表 |
更多配置详情与使用方法，欢迎访问 GitHub README 文档查看了解，期待大家积极分享使用体验与意见建议！
推荐阅读
引用链接
[1]
Github地址: https://github.com/hashDataInc/cbcopy/
[2]
《贡献指南》: https://cloudberrydb.org/contribute[3]
支持页面: https://cloudberrydb.org/support
👇🏻️扫码加入 Cloudberry Database 交流群👇🏻️
