金仓数据库逻辑备份：从全库导出到Schema替换闭环
来源：互联网 2026-07-01 08:46:00做运维这些年，备份的重要性不言而喻。逻辑备份看似简单，实际恢复时却会遭遇表名大小写、schema 变更、owner 不一致等种种陷阱，稍有不慎，恢复出的数据库便面目全非。 本文将深入讲解金仓数据库（KingbaseES）逻辑层面的备份与恢复，涵盖从全库导出到恢复时将旧 schema 干净替换为新 s
做运维这些年，备份的重要性不言而喻。逻辑备份看似简单，实际恢复时却会遭遇表名大小写、schema 变更、owner 不一致等种种陷阱，稍有不慎，恢复出的数据库便面目全非。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
本文将深入讲解金仓数据库（KingbaseES）逻辑层面的备份与恢复，涵盖从全库导出到恢复时将旧 schema 干净替换为新 schema 的完整流程。所有内容均源于实战踩坑与验证，旨在帮助你规避弯路。
一、金仓数据库逻辑备份的三种导出格式
金仓逻辑备份的核心工具是 sys_dump，支持三种导出格式，分别适配不同场景。首先明确格式差异，因为后续恢复命令的选择完全取决于初始导出格式。
1. 纯文本格式（-Fp）
参数 -Fp 导出一个普通的 .sql 文件，内含可读的 SQL 语句。最大优点是透明——可直接查看甚至用文本编辑器修改。示例：
复制代码# su - kingbase
$ mkdir -p /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)
$ sys_dump -h 127.0.0.1 -p 54321 -U system -d dbtest -f /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)/dbtest.sql
2. 自定义二进制格式（-Fc）
参数 -Fc 导出 .dmp 文件，经过压缩，体积小且恢复灵活度高，可选择性恢复部分对象。
复制代码# su - kingbase
$ mkdir -p /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)
$ sys_dump -h 127.0.0.1 -p 54321 -U system -d dbtest -Fc -f /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)/dbtest.dmp
3. 目录格式（-Fd）
参数 -Fd 将备份拆分为目录中的多个文件。这是唯一支持并行备份的格式，通过 -j 参数指定并行度，大库备份效率显著提升。
复制代码# su - kingbase
$ sys_dump -h 127.0.0.1 -p 54321 -U system -d dbtest -Fd -j 4 -f /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)
使用目录格式时需注意：若目标目录已存在，必须先删除再备份，否则会报错。
二、精细化备份：Schema 和单表导出
实际场景中，常需备份特定 schema 或关键表。sys_dump 通过 -n 指定 schema，-t 指定表。
备份指定 Schema
复制代码$ sys_dump -h 127.0.0.1 -p 54321 -U system -d dbtest -n public -f /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)/public.sql
备份指定表
复制代码$ sys_dump -h 127.0.0.1 -p 54321 -U system -d dbtest -t test -f /home/kingbase/backup/sys_dump_$(date +%Y%m%d%H)/test.sql
关键参数说明：-a 仅备份数据不包含结构，-s 仅备份结构不包含数据。此外，sys_dump 仅转储备份开始时刻的快照，备份过程中的数据变更不会被包含，这一机制保证了备份一致性，但需清楚边界。
三、典型坑点：表名大小写问题
使用 -t 指定表名时常遇“no matching tables were found”错误，即使表确实存在。根源不在数据库，而在于 Linux shell 语法。
首先了解金仓中表名存储规则。在大小写不敏感环境（enable_ci 为 on）下，不加双引号建表时，表名自动转为小写存入数据字典。
复制代码TEST=# create table dD (id int );
CREATE TABLE
TEST=# select relname from pg_class where relname='dd';
relname
---------
dd
(1 row)
若建表时加了双引号，表名则会原样保留大小写混合形态：
复制代码create table "gD" (id int );
TEST=# select relname from pg_class where relname='gD';
relname
---------
gD
(1 row)
此时若在 sys_dump 命令中写 -t "hGF"，双引号会被 shell 先行解析，实际传给 sys_dump 的仅为 hGF，而数据字典中存储了带引号语义的标识符，两者不匹配导致报错。
复制代码[kingbase2@localhost V8]$ sys_dump -U system -d test -p 2920 -FC -t "hGF" -f /opt/Kingbase/ES/V8/dd1.dmp
sys_dump: error: no matching tables were found
正确写法有两种，核心是让双引号逐层传递。方法一：使用转义符。
复制代码sys_dump -U system -d test -p 2920 -FC -t ""hGF"" -f /opt/Kingbase/ES/V8/db1.dmp
方法二：用单引号包裹双引号，因为 shell 中单引号内的内容为纯字符串，不进行解析。
复制代码sys_dump -U system -d test -p 2920 -FC -t '"hGF"' -f /opt/Kingbase/ES/V8/db2.dmp
简言之：shell 中单引号表示字面字符串，双引号会触发变量解析。因此涉及大小写混合表名时，要么使用转义，要么用单引号嵌套。
此外需注意大小写敏感与不敏感环境的差异。敏感环境（enable_ci 为 off）下，小写、大写、混合表名可以共存。而不敏感环境中，无论写 ag、Ag 或 AG，系统仅认一种，后续再建其他形态的同名表会提示“relation already exists”。迁移或恢复时需特别留意。
四、恢复命令的选择
恢复命令取决于导出格式，遵循以下原则。
纯文本格式（.sql）恢复
只能使用 ksql 恢复。恢复前需先创建目标数据库。
复制代码# su - kingbase
$ createdb -h 127.0.0.1 -p 54321 -U system dbtest
$ ksql -h 127.0.0.1 -p 54321 -U system -d dbtest -f /home/kingbase/backup/sys_dump_2023060615/dbtest.sql
自定义格式和目录格式恢复
使用 sys_restore 工具：
复制代码# 自定义格式
$ sys_restore -h 127.0.0.1 -p 54321 -U system -d dbtest /home/kingbase/backup/sys_dump_2023060615/dbtest.dmp# 目录格式，支持并行恢复
$ sys_restore -h 127.0.0.1 -p 54321 -U system -d dbtest -Fd -j 4 /home/kingbase/backup/sys_dump_2023060615
使用 sys_restore 时注意：-d 与 -f 不可同时使用，只需用 -d 指定目标库，无需再用 -f 单独指定文件路径。此细节易被忽略。
恢复特定 Schema 或表
若导出为 .sql 文件，仍使用 ksql -f：
复制代码$ ksql -h 127.0.0.1 -p 54321 -U system -d dbtest -f /home/kingbase/backup/sys_dump_2023060615/public.sql
五、高级技巧：恢复时替换 Schema
实际工作中常需在恢复时变更 schema 名称，例如将源库 abc schema 的数据导入到目标库的 u2 schema 下。sys_restore 提供 -g（源 schema）和 -G（目标 schema）参数。但存在易被忽略的陷阱：仅使用 -g -G 时，表的 owner 仍为原用户。若需同步变更 owner，必须额外加 -O 参数。
以完整测试说明：先创建用户 abc、数据库 abc 及 schema abc，其中包含表 t1，owner 和 schema 均为 abc。再创建超级用户 u2 及对应 schema u2。
导出 abc 库：
复制代码sys_dump -Uabc -Fc -f abc.dmp abc -p 2920
使用 -O、-g、-G 参数恢复，目标 schema 指定为 u2：
复制代码sys_restore -Uu2 -dabc -Fc -p 2920 -gabc -Gu2 -O abc.dmp
恢复后查询，t1 表的 schema 和 owner 均变为 u2：
复制代码abc-# c abc u2
abc-# d
List of relations
Schema | Name | Type | Owner
--------+---------------------+-------+--------
public | sys_stat_statements | view | system
u2 | t1 | table | u2
(2 rows)
作为对比，若不加 -O，虽 schema 变为 u2，但 owner 仍为 abc：
复制代码sys_restore -Uu2 -dabc -Fc -p 2920 -gabc -Gu2 abc.dmp
-- 结果：t1 的 Owner 仍为 abc
此外还可采用更直接的方案：导出为 .sql 文本，用 sed 命令全局替换 schema 名称。
复制代码sys_dump -Usystem -Fp -f abc.sql abc -p 2920
sed -i 's/abc/u2/g' abc.sql
sed -i 's/public/u2/g' abc.sql
ksql abc -Usystem -f abc.sql
该方法直观且易于操作，但数据量较大时文本替换效率较低，且全局替换可能误伤表名中包含相同字样的情况。因此，小库可选用此法，大库应优先使用 sys_restore 的参数方案。
写在最后
逻辑备份的真正难点并非命令本身，而是隐藏在细节中的边界条件：三种格式对应的恢复方式、shell 中转义大小写混合表名、sys_restore 的参数互斥、owner 与 schema 替换不同步等。逐一解决这些问题，备份恢复流程才能具备真正的可靠性。
最关键的建议始终如一：生产环境必须定期进行恢复演练。备份文件存于硬盘不等于安全，唯有在需要时能完整、正确地恢复，才称得上真正的容灾能力。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
相关攻略
更多同类更新
更多
热游推荐
更多-
- DreamStudio
- Android/ | AI绘图
- 2026-06-30
-
-
- Playground AI
- Android/ | AI绘图
- 2026-06-30
-
- Adobe Firefly
- Android/ | AI绘图
- 2026-06-30
-
-
-
- Leonardo AI
- Android/ | AI绘图
- 2026-06-30
-
- Stable Diffusion
- Android/ | AI绘图
- 2026-06-30
