GBase 8a 做数据迁移时，我一般先把导出、加载和校验拆开处理

我最近看 GBase 8a 这块资料时，一个感觉越来越明显：很多迁移项目最后出问题，不是卡在“不会迁”，而是卡在“迁得不稳”。表面上看，数据从 A 集群搬到 B 集群，好像无非就是导出再导入；但真正落到现场时，最容易把进度拖慢的，往往不是命令本身，而是格式没先对齐、字符集没先确认、加载链路没先压测、迁完也没把校验和回退动作提前写好。

GBase 8a 本身就有比较直接的迁移路径。按社区资料里的说法，常见做法大致可以分成两类：一类是通过 DataX 这类数据流转平台走 reader / writer 插件，一类是直接走 SELECT INTO OUTFILE 导出，再用 LOAD DATA 导入。前者更适合做流程编排和定时任务，后者更像数据库自带能力，路径更短，但对格式和执行位置要求也更明确。 我自己理解下来，这两类方案没有绝对高下，真正要紧的是：先把迁移目标、数据格式、执行窗口和校验办法定清楚，再选工具。

我一般先把 GBase 8a 迁移场景拆成这几类

场景	我更倾向的路线	原因
同构 8a 集群之间批量迁移	SELECT INTO OUTFILE + LOAD DATA	路径短、可控性强、适合脚本化
需要配合调度平台做周期同步	DataX / 平台化链路	编排、重试、调度更方便
一次性历史大表迁移	导出导入优先	吞吐更好，便于分批和断点规划
字符集改造或库重建	先导出，再重建，再导入	8a 数据库字符集创建后不能直接改
现场网络约束比较多	先验证协议链路再选 ftp / sftp / file	很多失败并不是 SQL 本身有问题

这个拆法不是唯一答案，但从落地角度看，它很适合 GBase 8a。因为 8a 做迁移，不只是“把数据搬过去”，而是要同时考虑加载链路、格式兼容和后续可运维性。

一、先决定走哪条路，别还没搞清目标就开始写脚本

社区里关于 8a 集群间迁移的资料其实已经把思路讲得比较清楚了：一种是 DataX 等数据流转平台，另一种是直接导出导入。 我自己现在接迁移任务，第一步通常不是写 LOAD DATA，而是先回答下面四个问题：

1. 这次是一次性全量，还是要长期周期同步。
2. 迁移过程中需不需要调度、重试、告警。
3. 数据格式能不能完全自己控住。
4. 对迁移窗口和回退速度有没有硬约束。

我自己更常用的判断表

维度	DataX 这类平台链路	导出导入链路
上手成本	中等，需要插件和作业配置	低，数据库和脚本就能做
流程编排	强	一般，更多靠 Shell 包装
大批量一次性迁移	能做，但不一定最省心	更直接
失败重试	平台能力更强	需要自己补脚本
格式控制	受插件实现影响	自己可完全定义
适合场景	周期同步、流程化任务	同构批量迁移、一次性搬迁

我个人更倾向于这么理解： 如果重点是“长期跑得稳”，平台链路更顺手；如果重点是“这次迁得快、格式可控、排障直接”，导出导入往往更实用。

二、直接走导出导入时，我一般先把格式协议定死

GBase 8a 社区给出的做法很直接：先在源集群用 SELECT ... INTO OUTFILE 导出，再在目标集群用 LOAD DATA 导入。这两步都要求通过服务器侧的 gccli 去执行，而且实际项目里通常会先把分隔符、换行符、NULL 表示统一定死，不让不同批次各写各的。 我自己在现场里，最怕的不是不会写导出语句，而是不同表、不同脚本、不同人写出来的格式不一致，最后导入端一会儿把 NULL 当字符串，一会儿又把换行拆坏了。

一个比较常见的导出示意

set global gbase_export_directory = off;

select *
from ods.lineorder_hist
into outfile '/data/migrate/ods_lineorder_hist_20260401.txt'
fields terminated by '&|?'
null_value 'gbasenull'
lines terminated by '=??=';

对应的加载示意

load data infile 'sftp://gbase:***@192.0.2.18//data/migrate/ods_lineorder_hist_20260401.txt'
into table ods.lineorder_hist
data_format 3
fields terminated by '&|?'
null_value 'gbasenull'
lines terminated by '=??=';

这里我一般会先把下面这几个点锁死：

项目	我更习惯怎么定	为什么
fields terminated by	用业务数据里极少出现的分隔符	减少字段内容撞分隔符
null_value	明确指定，比如 gbasenull	避免空串、NULL 混淆
lines terminated by	显式定义	避免跨平台换行差异
文件命名	带库表名和批次时间	回溯和重跑方便
执行入口	统一走 gccli 脚本	降低人工误操作

很多迁移项目后面要返工，真不是 LOAD DATA 慢，而是最开始没把格式约定写成模板。

三、协议能通不代表链路就稳，ftp / sftp / file 我一般先做一轮最小验证

社区里关于 8a 导入的例子已经把几种常见协议列出来了，实际能见到的主要还是 ftp://、sftp:// 和 file://。我自己的经验是，这几种协议不要一上来就拿全量表试。先拿小文件做一轮连通性和权限验证，后面能省很多时间。

三种常见方式我怎么选

方式	我更常用的场景	要特别注意什么
sftp://	默认优先考虑	权限、并发连接、sshd_config
ftp://	历史环境较多时会遇到	服务要先可用，账号权限要清楚
file://	只在路径已经打通、目标机器明确时用	一般要求文件直接落到目标可访问位置

尤其是 sftp，社区资料里提到过一个很实在的坑：当集群并发加载任务数和单任务最大加载机数都比较大时，sftp 可能因为 SSH 未认证连接数限制而失败，这时 MaxStartups 这种系统参数就得跟着调整。 这个点我特别认同，因为现场里大家很容易把导入失败直接归到数据库头上，但实际上链路瓶颈常常在 SSH 服务配置。

我比较习惯先做的最小验证

#!/bin/bash
set -e

SRC_HOST="192.0.2.18"
SRC_FILE="/data/migrate/check_lineorder.txt"

sftp gbase@${SRC_HOST} <