数据库移植的工作量主要来源于：数据类型、SQL语言、PL/SQL语言、甚至客户端应用编程接口等诸多方面对两个数据库所进行的、大量的语法或功能的对齐处理。PolarDB PostgreSQL版和金仓MPP数据库都是基于Postgresql体系的数据库，但架构不同。将PolarDB迁移至金仓MPP数据库可以看成是一种异构数据间的迁移的迁移，但因为两款数据库的语法体系都是基于PostgreSQL，相对于不同语法体系间的异构数据库迁移，在SQL语句、数据类型等方面需要考虑的差异较少，数据库迁移和应用的迁移工作量相对可控。

从PolarDB的官网可知，PolarDB的架构如下图所示：

Polardb是一款云原生数据库，在计算存储分离架构下提供了对PostgreSQL生态的100%支持。通过云原生架构、软硬件一体化、共享分布式存储的设计，主节点和只读节点使用物理复制、RDMA网络低时延，能够快速同步数据，彻底解决了主从异步复制所带来的备库数据非强一致的问题，使得整个数据库集群在应对任何单点故障时，都可以保证数据零丢失，同时实现秒级节点扩缩容。

         金仓MPP架构如下图：

产品是人大金仓新推出的面向OLAP业务的分析型数据库，它主要采用了MPP、非共享（share-nothing）和行、列混合存储技术，其主要面向具有大规模数据的在线统计分析和即席查询需求的商业分析和商业智能市场。

以下从迁移评估和迁移方案两个方面阐述从PolarDB迁移至金仓MPP数据库的详细过程：

迁移评估

数据库、用户和模式

数据库和模式是各种SQL和PL/SQL数据库对象的存放容器，而用户是这些对象的管理者和使用者。因此，在迁移数据库对象之前应该对需要迁移的数据库、用户和模式进行统计，为后续的数据迁移准备对应的逻辑存储基础。

用户的迁移方案，采用和源库同名用户创建，并赋予相应的访问和连接权限，甚至可以修改用户默认的连接数据库。如果应用使用某一个特定用户需要做跨schema的表的关联访问，则需要相应的赋予用户对多个schema的访问权限。

数据量评估

分布式数据库的迁移和传统的单机数据库迁移最大的不同就是迁移涉及的数据量比较大，少则几十~几百GB，多则上TB的数据需要迁移。迁移的数据量在一定程度上决定迁移工作的周期、迁移的复杂程度和迁移后验证的工作量。

建表DDL

    如前文所述，Polardb数据库的DDL和KADB集群数据库虽然在SQL标准的兼容度很高，但是还是会存在细微的差异。并且考虑到迁移后的性能问题，需要将迁移前后表的DDL进行比对和修改，这就需要我们在执行迁移任务前对应用涉及的业务系统表进行充分的了解和研究，迁移前对表的DDL进行统计和收集会大大减少后续迁移过程中遇到的问题。

迁移目标

迁移成功与否的最终标准由迁移的目标决定。各个IT系统的环境和运行情况千差万别，迁移涉及到服务器硬件、存储、网络等基础硬件的变更，也涉及应用代码的改造，在这样的复杂的迁移条件下了解源系统的响应时间、系统吞吐率、装载效率、数据增长率及典型SQL的执行时间等性能指标和迁移后用户对上述指标的期望值进行对比，从而确定迁移目标。这样不仅能量化迁移的效果，同时对迁移的范围也能有量化的界定。迁移完成后根据上述指标能确定明确的验收标准及指定相应的验证方法。

根据以上异构数据库迁移的评估，综合可以采用的迁移方案如下：

迁移方案1（备份/恢复）

该方案使用数据备份工具对源数据库进行全库备份（备份为文本文件方便纠错），然后在目标端恢复的方式

• 使用数据库备份工具pg_dump对源数据库做全库备份pg_dump -f test.dmp -Fp -Uxxx TEST
• 备份文件拷贝到目标端集群master节点。使用psql对备份文件进行恢复：psql postgres mppadmin -f test.dmp

方案存在问题及解决

使用备份/恢复工具可能存在的问题：

1. 需要对应源端数据库创建金仓MPP数据库对应的用户
2. 大小写敏感，所以“PUBLIC”和“public”是不同的
3. Polardb的某些参数KADB不支持，例如：idle_in_transaction_session_timeout

对于问题3，因为导出文件不支持的参数只有一个，可以通过shell批量替换的方式解决，例如：

sed -i‘s/idle_in_transaction_session_timeout/ idle_transaction_timeout/g test.dmp

1. master节点空间是否足够容纳需要迁移的数据

如果不能解决maser节点存储空间问题，只能采用迁移方案2的方式分批导入数据

迁移方案2（逻辑迁移）

该方案分别迁移数据库对象的DDL和数据，让后对上述备份数据分批恢复到目标端数据库

• 源端使用自带数据库备份工具pg_dump导出需要迁移的数据库中对象的DML语句和数据

pg_dump -f test.sql -F p –s -Uxxx TEST        备份DDL

pg_dump -f test.sql -F p –a -Uxxx TEST        备份数据

• 对导出的表DML语句进行迁移修改，金仓MPP数据库要求表的主键和表的分布键涉及的表属性相同
• 将表的DML和数据拷贝到目标的master节点
• 在目标端的master节点使用恢复命令配合shell脚本进行数据的批量导入

psql db_name -Uxxx -hmdw -f ./public.dmp

使用逻辑迁移方案可能存在的问题：

1. 逻辑迁移方案也会因为KingbaseES配置了大小写敏感后，造成表的访问方式改变，
2. 对于大对象数据的迁移仅测试了bit、bytea两种数据类型，需要根据客户现场数据情况相应处理

迁移方案3（ETL工具迁移）

该方案使用金仓ETL工具，同时连接源端数据库和目标端数据库进行对象和数据的不落地迁移

• 配置金仓ETL工具kdts。

迁移程序支持迁移多种源数据库，为了避免不同源数据库配置相互的干扰，在conf目录下按不同的源数据库类型进行生成独立的配置文件，请按实际要迁移的源数据库在conf/application.yml中的“active”参数项处设置当前激活的数据库类型，如：

• 启动迁移程序

迁移程序的启动脚本在kdts-plus/bin目录下，Linux平台为startup.sh，Windows平台为startup.bat

设置JAVA_PATH

如果JDK没有安装在kdts-plus/JDK目录，将如下的“JAVA_PATH”配置为实际的安装目录。

startup.sh（Linux平台）

• 查看运行日志

迁移程序会在kdts-plus/logs目录下按迁移日期和时间创建日志目录，该目录下会有3个日志文件以及不同模式名的子目录，每个子目录下存放该模式相关的日志（error.log、info.log、warn.log），请注意查看error.log中的内容。

• 查看运行报告

迁移程序会在kdts-plus/result目录下按迁移日期和时间创建报告目录，该目录下会有index.html以及不同模式名的子目录，每个子目录下存放该模式的详细报告，可打开index.html进行查看。