表空间目录自动创建：从一个小开关聊到云原生存储的那些事

文章目录

兼容是对前人努力的尊重是确保业务平稳过渡的基石然而这仅仅是故事的起点

有个事儿得从刚入行不到两年说起

我记得特别清楚，那会儿刚入行不到两年，有天晚上接到一个紧急需求，要在生产环境加一个表空间。我当时心想这还不简单？一条SQL的事嘛。结果啪啪打脸------CREATE TABLESPACE 刚敲下去就报错，目录不存在。大半夜的，我又没有服务器的root权限，只能给运维打电话让他帮忙建目录。运维老哥接了电话，迷迷糊糊的，建了目录还忘了chown，属主给成了root。我又执行一次，还是报错，权限不对。来来回回折腾了四十多分钟，最后运维老哥都烦了，说"你到底行不行"。

说实话，那会儿我整个人都是懵的。一个表空间而已，为啥搞得这么复杂？后来才明白，这就是数据库和操作系统之间那个"谁都管不了谁"的老问题------数据库想存东西，但没有权限在文件系统里建目录；操作系统有权限，但它不关心你要建什么表空间。

所以后来KES出了这个 auto_createtblspcdir 参数的时候，我第一反应就是：这玩意儿早该有了。

这个坑我记得特别清楚

早期的KES版本里，创建自定义表空间是个"两头跑"的活。你先得登录服务器，一层层把目录建好，还得确保权限和属主都对，然后再回到数据库里执行 CREATE TABLESPACE。听着不复杂对吧？但实际操作中，只要中间有一步出错------目录少建了一层、属主给了root、权限设成755------语句直接报错，前面的功夫全白费。

而且这个流程在几个场景下特别让人崩溃：

批量初始化环境的时候，脚本里要不断判断"目录到底存不存在"，不存在就 mkdir -p，然后执行SQL，代码越写越臃肿。自动化部署更别提了，DevOps流水线要在操作系统层面和数据库层面反复切换，编排复杂度直线上升。测试环境快速搭建，临时建一个表空间光准备目录就得花好几分钟。多层嵌套路径，手敲 /data/ts/business/module1/submodule/sp1 这种东西，拼写错误几乎是必然的。

KES的解决思路很直接------既然目录不存在是报错的根源，那就让数据库自己把它建出来。

auto_createtblspcdir 到底是个啥

这个特性由一个GUC参数 auto_createtblspcdir 控制。先说个很多人不知道的点：不同KES大版本的默认值不一样。V8默认是off，V9默认改成了on。我接触过好几个新手，就是因为没注意这个版本差异，照着旧文档操作，结果踩了坑。

所以拿到新环境第一件事：

sql 复制代码

-- 先看看当前到底是啥值，别想当然
SHOW auto_createtblspcdir;

这个参数是bool类型，就两个值，on和off。它属于Sighup级别的参数，改完执行 pg_reload_conf() 就能生效，不用重启数据库，生产环境改起来很方便。

开和关的行为差异其实挺大的：

on的时候（V9默认），目录不存在数据库就自动帮你递归创建整条路径，路径中已经存在的父目录属主必须是数据库操作系统用户，新建目录的属主自动设为数据库OS用户。

off的时候呢，目录不存在直接报错，目录必须已经存在而且必须为空，属主也必须对。相当于回退到传统模式，所有准备工作都得你自己做。

sql 复制代码

-- 修改参数，推荐用ALTER SYSTEM，变更会写入kingbase.auto.conf方便追踪
ALTER SYSTEM SET auto_createtblspcdir = off;
-- 不用重启，reload就行
SELECT pg_reload_conf();
-- 确认一下
SHOW auto_createtblspcdir;

-- 想看参数的完整元信息，包括当前值从哪来的
SELECT name, setting, source, context, short_desc
FROM pg_settings
WHERE name = 'auto_createtblspcdir';

话说回来，大多数场景下建议保持默认的on。除非你有非常严格的目录管理规范------比如所有存储路径必须由专门的运维流程创建------才考虑关掉它。

自动不等于随意------五条铁律

自动创建虽然方便，但KES对表空间设置了一整套约束，无论参数开关怎么设，这些规则都不能破。

绝对路径是硬要求。 数据库不接受相对路径，因为"相对于谁"这个问题它没法回答：

sql 复制代码

-- 这才对
CREATE TABLESPACE mysp1 LOCATION '/data/tablespaces/mysp1';
-- 这要报错的
CREATE TABLESPACE mysp1 LOCATION './mysp1';
-- ERROR: tablespace location must be an absolute path

路径不能在data目录里面。 这条限制是为了避免表空间文件和系统数据文件混在一起，不然备份、迁移、权限管理都会乱成一锅粥：

sql 复制代码

-- 假设data目录是 /opt/Kingbase/ES/V8/data
CREATE TABLESPACE mysp1 LOCATION '/opt/Kingbase/ES/V8/data/mysp1';
-- ERROR: tablespace location must not be inside the data directory

一个路径只能绑一个表空间。 防止命名冲突和资源争用：

sql 复制代码

CREATE TABLESPACE sp1 LOCATION '/data/ts/sp1';
CREATE TABLESPACE sp2 LOCATION '/data/ts/sp1';
-- ERROR: directory is already in use as a tablespace

只有超级用户能创建表空间。 普通用户想用表空间怎么办？可以授权CREATE权限，但不代表他能管理表空间本身：

sql 复制代码

-- 普通用户直接建表空间？没门
-- ERROR: must be superuser to create a tablespace

-- 但可以这样授权，让他能在表空间里建表
CREATE ROLE ops_admin LOGIN;
GRANT CREATE ON TABLESPACE ts_data TO ops_admin;

属主必须一致------这个坑最深。 不管自动创建还是手动创建，路径中已经存在的那些父目录，属主必须是启动数据库的操作系统用户。最典型的翻车现场：运维用 sudo mkdir 建了目录，忘了 chown，然后创建表空间死活失败。

bash 复制代码

# 检查属主
ls -la /data/tablespaces/
# drwx------ 2 kingbase kingbase 4096 ...

# 如果属主不对，赶紧修正
sudo chown -R kingbase:kingbase /data/tablespaces/
sudo chmod 700 /data/tablespaces/

来点实际的------各种场景跑一遍

我有个哥们儿之前也是这问题，各种目录情况都踩了一遍，我直接把他的测试场景搬过来，加上我自己的理解整理一下。

场景一：目录已经完整存在

最简单的情况，目录提前建好了，直接建表空间就行：

sql 复制代码

-- 前提是目录已经存在，属主也对了
CREATE TABLESPACE mysp1 LOCATION '/data/tbs/mysp1';

场景二：只存在一部分目录

这种情况挺常见的，比如 /data/tbs 已经有了，但 /data/tbs/app/logs 不存在。当 auto_createtblspcdir 开启的时候，KES会自动把不存在的部分补全：

sql 复制代码

-- /data/tbs 存在，/data/tbs/app/logs 不存在，自动创建
CREATE TABLESPACE mysp_log LOCATION '/data/tbs/app/logs';

场景三：完全不存在，全路径自动创建

这个是最方便的场景。路径完全不存在？KES递归创建所有层级，你啥都不用管：

sql 复制代码

-- 深层嵌套路径？无所谓，自动全建出来
CREATE TABLESPACE mysp_new LOCATION '/data/tbs/app/year/month/day/mysp_new';

场景四：大小写混合+建表写数据验证

光建表空间不算完，得验证数据能不能真正写进去才行：

sql 复制代码

-- 建表空间，注意大小写混合的路径
CREATE TABLESPACE mysp_biz LOCATION '/data/tbs/BizData';

-- 在这个表空间上建表
CREATE TABLE orders (
    id     INT,
    amount NUMERIC(12,2),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) TABLESPACE mysp_biz;

-- 插数据试试
INSERT INTO orders VALUES (1, 9999.00, '2026-01-15 10:30:00');
INSERT INTO orders VALUES (2, 1234.56, '2026-01-16 14:22:00');
INSERT INTO orders VALUES (3, 55555.00, '2026-02-01 09:00:00');

-- 查一下确认没问题
SELECT * FROM orders;

-- 看看表空间的使用情况
SELECT spcname, sys_size_pretty(sys_tablespace_size(oid)) as size
FROM sys_tablespace;

话说回来------底层到底怎么执行的

这个应该...嗯...我记得是这么回事。当你执行 CREATE TABLESPACE ... LOCATION 'xxx' 的时候，内核里的流程大致是这样的：

首先校验LOCATION路径的合法性，只支持绝对路径，写相对路径直接报错。然后检查路径对应的目录是否已经存在。如果存在了，校验目录权限，通过就把表空间元信息写入系统表，完事。如果不存在，看 auto_createtblspcdir 参数------off就直接报错，on的话用KES运行用户（一般是kingbase用户）调用系统mkdir创建目录。

这里有个细节值得注意：如果自动创建目录失败（比如权限不够），KES在某些情况下不会在 CREATE TABLESPACE 阶段报错，而是把错误打在日志里，仍然把表空间的元信息写入系统表返回"创建成功"。只有当你第一次往这个表空间的表插入数据、需要创建数据文件的时候，才会再次访问目录，找不到目录才会报错。这个设计挺...嗯...怎么说呢，我一开始觉得挺反直觉的，创建失败为什么不直接报错？后来想想也能理解------表空间本质上是个逻辑容器，创建的时候并不一定马上就要写文件。

所以如果你建完表空间之后不太确定，最好顺手验证一下：

sql 复制代码

-- 建完表空间后，创建个测试表确认目录是真的可用的
CREATE TABLE tblspc_test (id int) TABLESPACE mysp_new;
INSERT INTO tblspc_test VALUES (1);
DROP TABLE tblspc_test;

GUC参数那些事儿------不只是改个值

既然说到参数，我就多唠叨几句。auto_createtblspcdir 是GUC体系下的一个参数，而GUC是KES所有参数配置的核心框架。很多人对GUC一知半解，改参数改错了还不知道为什么。

KES的GUC参数大概有几百个，按生效方式分成五个级别：

Internal级是内核编译时写死的，改不了。Postmaster级必须重启数据库才能生效，比如 max_connections。Sighup级改完reload就能用，auto_createtblspcdir 就是这种。Backend级现有连接不生效，新连接自动加载新值。Session级当前会话直接改，只对当前会话生效。

参数还有优先级概念，从高到低依次是：会话级SET命令 > ALTER DATABASE SET > ALTER ROLE SET > kingbase.auto.conf > kingbase.conf > 编译时默认值。

sql 复制代码

-- 看参数从哪来的
SELECT name, setting, source
FROM sys_settings
WHERE name = 'auto_createtblspcdir';

配置管理上我有几条建议。关键参数统一写入配置文件，结合Git追踪变更历史。改参数先在测试环境验证，生产环境无小事。动态参数优先用 ALTER SYSTEM SET，持久化写入 kingbase.auto.conf，比直接编辑 kingbase.conf 更安全，也方便审计。

关于 auto_createtblspcdir 的具体配置建议：开发测试环境保持默认开启（on），追求便捷和效率；生产环境看情况，如果你对存储布局管控要求特别严格可以关掉，保持可控可追溯。不过说实话，我自己的习惯是开着，只要权限管好就行。

这个才是重点------容器化环境里咋整

好了，前面聊的都是传统部署场景下的东西。现在谁还裸机部署啊？Docker和K8s才是主流。那问题来了------表空间的"自动创建目录"特性，在容器化环境里到底好不好使？

先说结论：好使，但有几个坑你得知道。

K8s里的PV/PVC和表空间

KES在K8s上部署，官方提供了Operator，用的是StatefulSet+PVC的模式。数据目录通过PVC挂载，确保Pod重建后数据不丢。但表空间这玩意儿比较特殊------你需要额外的挂载点。

yaml 复制代码

# 一个典型的KES StatefulSet配置，注意表空间的额外卷
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kingbase
spec:
  serviceName: kingbase
  replicas: 1
  template:
    spec:
      containers:
      - name: kingbase
        image: kingbase:v1
        volumeMounts:
        - name: data
          mountPath: /home/kingbase/userdata
        - name: tbs-hot       # 热数据表空间挂载
          mountPath: /mnt/ssd/tbs
        - name: tbs-cold       # 冷数据表空间挂载
          mountPath: /mnt/hdd/tbs
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: managed-nfs-storage
      resources:
        requests:
          storage: 50Gi
  - metadata:
      name: tbs-hot
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: ssd-storage    # SSD存储类
      resources:
        requests:
          storage: 100Gi
  - metadata:
      name: tbs-cold
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: hdd-storage    # HDD存储类
      resources:
        requests:
          storage: 500Gi

关键点是：auto_createtblspcdir 开启的情况下，你只需要确保PVC挂载到了正确的路径（比如 /mnt/ssd/tbs），然后在KES里直接执行 CREATE TABLESPACE 就行了。不需要进容器手动 mkdir，数据库自动帮你把子目录建好。

但这里有个大坑------PVC挂载的根目录属主问题。默认情况下，K8s的PV挂载进来的时候，目录属主可能是root。而KES容器里是用kingbase用户跑的，所以你需要：

dockerfile 复制代码

# Dockerfile里或者initContainer里处理权限
# 方式一：在容器启动脚本里加
chown -R kingbase:kingbase /mnt/ssd/tbs /mnt/hdd/tbs
chmod 700 /mnt/ssd/tbs /mnt/hdd/tbs

或者用 securityContext 配置：

yaml 复制代码

securityContext:
  fsGroup: 1000   # kingbase用户的gid
  runAsUser: 1000  # kingbase用户的uid

这样K8s在挂载PV的时候会自动把目录属主调整成kingbase用户，配合 auto_createtblspcdir 就能做到"挂载即用"。

S3兼容存储？想都别想...呃，也不是完全不行

有人问我：能不能把S3兼容接口的存储挂载过来当表空间用？

说实话，这事儿挺邪门的。KES的表空间底层走的是POSIX文件系统接口，要求目录操作是原子的、强一致的。而S3本质上是对象存储，不支持POSIX语义。直接用S3当表空间路径？不行。

但是------可以通过S3兼容的文件系统网关（比如S3FS、JuiceFS、Goofys）把对象存储映射成本地目录。映射完之后，对KES来说就是一个普通目录，auto_createtblspcdir 该怎么用还怎么用。

bash 复制代码

# 用JuiceFS把S3映射为本地路径
juicefs format \
    --storage s3 \
    --bucket https://my-bucket.s3.cn-north-1.amazonaws.com.cn \
    --access-key xxx \
    --secret-key xxx \
    redis://localhost/0 \
    myjfs

juicefs mount -d redis://localhost/0 /mnt/juicefs/tbs-archive
chown -R kingbase:kingbase /mnt/juicefs/tbs-archive

sql 复制代码

-- 然后在KES里直接建表空间，auto_createtblspcdir帮你建子目录
CREATE TABLESPACE tbs_archive LOCATION '/mnt/juicefs/tbs-archive/data';

不过要注意性能问题。对象存储的延迟比本地盘高一个数量级，只适合冷数据归档场景。我之前试过把热数据表空间放S3FS上，那个IO性能简直...整无语了，查询慢了十倍不止。

存储分层------这才是云原生的正确打开方式

在云环境下，表空间最核心的价值不是"把数据放在不同的地方"，而是"把不同访问特征的数据放在不同性能的存储介质上"------也就是所谓的存储分层（Tiered Storage）。

说实话，这个思路不算新鲜，Oracle玩了很多年了。但在云原生环境里，它有了新的实现方式。

热数据上SSD，冷数据上HDD

假设我们有个ERP系统，数据访问特征差异很大------基础数据模块访问频繁，交易数据量巨大且并发高，财务报表历史数据多但访问少，文件附件基本就是归档。

传统做法是不同表空间指定不同挂载点。云原生环境下，我们用不同的StorageClass来实现：

yaml 复制代码

# SSD StorageClass - 给热数据用
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-storage
provisioner: disk.csi.alibabacloud.com
parameters:
  type: cloud_essd
  performanceLevel: PL1
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
---
# HDD StorageClass - 给冷数据用
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: hdd-storage
provisioner: disk.csi.alibabacloud.com
parameters:
  type: cloud_efficiency
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

然后在KES里创建对应的表空间：

sql 复制代码

-- 热数据放SSD
CREATE TABLESPACE tbs_erp_base LOCATION '/mnt/ssd/tbs/erp_base';
CREATE TABLESPACE tbs_erp_trade LOCATION '/mnt/ssd/tbs/erp_trade';
-- 交易索引单独一个表空间，和基表分开，减少IO争用
CREATE TABLESPACE tbs_erp_trade_idx LOCATION '/mnt/ssd/tbs/erp_trade_idx';

-- 冷数据放HDD
CREATE TABLESPACE tbs_erp_report LOCATION '/mnt/hdd/tbs/erp_report';
CREATE TABLESPACE tbs_erp_archive LOCATION '/mnt/hdd/tbs/erp_archive';

建表的时候指定表空间：

sql 复制代码

-- 热数据表 - 基表放SSD，索引也放SSD但分开表空间
CREATE TABLE trade_orders (
    id           BIGSERIAL,
    order_no     VARCHAR(32) NOT NULL,
    customer_id  INT,
    amount       NUMERIC(12,2),
    status       VARCHAR(16),
    created_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) TABLESPACE tbs_erp_trade;

CREATE INDEX idx_orders_no ON trade_orders(order_no)
    TABLESPACE tbs_erp_trade_idx;

-- 冷数据表 - 放HDD就行
CREATE TABLE finance_report_2024 (
    id          BIGSERIAL,
    report_type VARCHAR(32),
    data        JSONB,
    generated_at TIMESTAMP
) TABLESPACE tbs_erp_report;

临时表空间也别忘了

很多人忽略临时表空间，但在高并发排序、大结果集hash join的场景下，临时表空间的IO压力可能比主表空间还大。独立的临时表空间能避免临时IO冲击业务数据盘：

sql 复制代码

-- 临时表空间也放SSD上
CREATE TABLESPACE tbs_temp LOCATION '/mnt/ssd/tbs/temp';

-- 设置默认临时表空间
SET temp_tablespaces = 'tbs_temp';
-- 或者持久化
ALTER SYSTEM SET temp_tablespaces = 'tbs_temp';
SELECT pg_reload_conf();

动态扩容怎么办

云环境最大的优势就是弹性。表空间对应的PVC空间不够了？不需要停库，直接扩容PVC：

bash 复制代码

# 扩容PVC（前提是StorageClass支持动态扩容）
kubectl patch pvc tbs-hot-kingbase-0 \
    -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'

KES这边不需要任何操作，文件系统扩容后，表空间自动就能用上新的空间。这个配合 auto_createtblspcdir 的好处是------新建表空间不需要进容器操作文件系统，一条SQL搞定，运维复杂度直线下降。

版本差异这事儿真的坑爹

前面提了一嘴，这里展开说。V8默认off，V9默认on，这个差异不是随便改着玩的。

V8的时候，保持的是传统行为------你得自己建目录。这是为了和当时的生态兼容，很多老用户的自动化脚本都是基于"先建目录再建表空间"的流程写的。

V9改成了默认on，主要是因为越来越多的用户从Oracle迁移过来，Oracle的习惯就是"建表空间不用管目录"。为了降低迁移门槛，默认行为改了。

所以如果你的环境是V8，想用这个特性得手动开：

sql 复制代码

-- V8环境，默认off，手动开启
ALTER SYSTEM SET auto_createtblspcdir = on;
SELECT pg_reload_conf();

如果你的运维手册和部署脚本是按V8写的，迁移到V9的时候要注意这个差异。我之前就见过一个项目，测试环境用V9一切正常，上了生产发现是V8...创建表空间的脚本全报错。看了眼表，凌晨两点半，服了。

超级用户权限管理------别给多了

表空间创建和删除只能由超级用户执行，这是KES的安全设计。但超级用户权限大了，风险也大。生产环境里我的建议是：

超级用户账号越少越好，一般保留两三个就够。一个给DBA日常维护，一个给应用连接池。其他的应用系统账号，别给superuser权限。

sql 复制代码

-- 查看所有超级用户，看看有没有不该有的
SELECT rolname FROM pg_roles WHERE rolsuper = true;

-- 创建应用用户的时候，只给需要的权限
CREATE USER app_readonly WITH PASSWORD 'xxx';
GRANT USAGE ON SCHEMA public TO app_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;

-- 如果需要在特定表空间建表，授权CREATE就行
CREATE USER app_dev WITH PASSWORD 'xxx';
GRANT CREATE ON TABLESPACE tbs_erp_trade TO app_dev;

定期审查权限配置。看看有没有账号长期不用但权限还在，有没有权限被滥用的情况。这个说起来简单，但真正做到的团队真不多。

踩坑实录------属主问题是最阴的

我自己的血泪教训：有一次在容器环境里创建表空间，死活不成功。日志里写着属主不对，但我在容器里 ls -la 看了又看，属主明明就是kingbase啊。折腾了好久，头发都快揪秃了。

最后发现------是PVC挂载的那个根目录的属主不对。/mnt/ssd/tbs 本身是root属主，虽然我让KES自动创建 /mnt/ssd/tbs/erp_trade，但父目录 /mnt/ssd/tbs 不是kingbase用户的，所以自动创建失败。

解决方法很简单，在容器启动脚本里加一行：

bash 复制代码

# initContainer或者在entrypoint里
mkdir -p /mnt/ssd/tbs /mnt/hdd/tbs
chown -R kingbase:kingbase /mnt/ssd/tbs /mnt/hdd/tbs
chmod 700 /mnt/ssd/tbs /mnt/hdd/tbs

或者用K8s的 securityContext.fsGroup，让K8s自动处理挂载目录的权限。

另外一个坑：如果你用NFS挂载的目录，要注意NFS的 root_squash 配置。NFS默认会把root用户映射成nobody，如果kingbase用户的uid在NFS服务端和客户端不一致，也会出现属主问题。这个坑我也是踩了才知道...

bash 复制代码

# NFS挂载的时候，注意sync/async和no_root_squash
mount -t nfs nfs-server:/data/tbs /mnt/nfs/tbs \
    -o rw,sync,hard,no_root_squash

一条SQL完成的快感

说实话，auto_createtblspcdir 开了之后，创建表空间真的变成了一条SQL的事。在容器化环境里，配合PVC和StorageClass，整个流程是这样的：

在K8s里声明PVC，绑定不同StorageClass
在容器配置里把PVC挂到指定路径
在KES里一条SQL建表空间
建表指定表空间

没有手动建目录，没有权限问题，没有属主不对的报错。这才是云原生的体验。

sql 复制代码

-- 一气呵成
CREATE TABLESPACE tbs_hot  LOCATION '/mnt/ssd/tbs/hot';
CREATE TABLESPACE tbs_cold LOCATION '/mnt/hdd/tbs/cold';
CREATE TABLESPACE tbs_temp LOCATION '/mnt/ssd/tbs/temp';

-- 热数据
CREATE TABLE user_activity (
    id         BIGSERIAL,
    user_id    INT,
    action     VARCHAR(64),
    occurred_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) TABLESPACE tbs_hot;

-- 冷归档
CREATE TABLE user_activity_archive (
    LIKE user_activity INCLUDING ALL
) TABLESPACE tbs_cold;

最后啰嗦两句

一个"自动建目录"的小功能，聊了这么多，值不值？我觉得值。因为表面上看它只是帮你省了一步 mkdir，但往深了挖，它引出了表空间的安全约束体系、IO分离的调优思路、磁盘规划的运维规范、GUC参数管理的底层机制、还有云原生存储的弹性架构。这些知识串在一起，才是一套完整的数据库存储管理能力。

几条最实用的建议收尾：

auto_createtblspcdir 保持默认开启，省心。表空间规划的核心是IO分离------数据和索引分开、冷热分开、临时操作单独隔离。目录权限用700，属主必须一致，定期检查。改GUC参数用 ALTER SYSTEM SET，不要直接编辑 kingbase.conf。云环境里配合PVC和StorageClass，把存储分层做起来。NFS环境注意属主映射，容器环境注意fsGroup配置。