活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# 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` 当字符串，一会儿又把换行拆坏了。

### 一个比较常见的导出示意

```sql
set global gbase_export_directory = off;

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

### 对应的加载示意

```sql
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 '&amp;|?'
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 服务配置。

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

```bash
#!/bin/bash
set -e

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

sftp gbase@${SRC_HOST} &lt;

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

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

评论

热门帖子