在 OceanBase V4.2 版本中，当用户创建外表时，是否有明确要求外表所指定的数据源文件必须全部存放在同一台 OB 服务器节点上？如果文件分布在不同节点，或者使用 NFS、OSS 等共享存储路径，是否会导致外表创建失败或后续查询报错？这一限制的底层原因是什么，是架构设计、权限控制还是安全策略导致的？

培训 & 考证
#1

在 OceanBase V4.2 版本中，当用户创建外表时，是否有明确要求外表所指定的数据源文件必须全部存放在同一台 OB 服务器节点上？如果文件分布在不同节点，或者使用 NFS、OSS 等共享存储路径，是否会导致外表创建失败或后续查询报错？这一限制的底层原因是什么，是架构设计、权限控制还是安全策略导致的？

#2

1. 是否要求数据源文件必须位于同一 OBServer 节点？

是的。
在使用 CREATE EXTERNAL TABLE ... LOCATION = 'file://...' 创建本地外表时，local_file_path 必须位于当前执行 SQL 的 OBServer 节点本地文件系统中，且必须满足以下条件：

  • 路径必须是配置项 secure_file_priv 所指定目录的子路径；
  • 若使用相对路径，则当前工作目录必须为 OceanBase 数据库的安装目录。

这意味着：每个 OBServer 节点只能访问自己本地磁盘上符合权限控制的文件，无法直接读取其他节点上的本地文件。

2. 使用 NFS 或 OSS 等共享存储是否会导致外表创建失败或查询报错？

不会导致创建失败，但需注意使用方式：

  • 如果将 NFS 挂载到每个 OBServer 节点的相同路径下，并确保该路径在 secure_file_priv 允许范围内，则可以正常创建外表并查询；
  • 对于 OSS（对象存储），OceanBase 不支持通过 file:// 协议直接访问，而应使用专门的对象存储外表语法（如 LOCATION = 'oss://...'），但这通常在更高版本（如 4.3+）才更完善；
  • 在 4.2 版本中，主要支持的是本地文件路径（file://），若强行将 OSS 映射为本地路径（如通过 fuse 挂载），可能因性能、一致性或权限问题导致查询异常或不可靠。

因此，单纯使用 NFS（正确挂载且权限合规）通常可行；但直接用 OSS 作为 file:// 路径则不符合设计，可能导致错误 。

3. 该限制的底层原因是什么？

根本原因在于 OceanBase 外表的“本地文件”模式是单节点 I/O 模型：

  • 当前（4.2 版本）的本地外表实现假设数据文件存在于执行 SQL 的 OBServer 节点本地；
  • 查询时，该节点直接通过操作系统 API（如 open/read）读取本地文件，不涉及分布式文件系统协调或跨节点数据拉取；
  • 若文件实际位于其他节点或未在所有节点一致挂载（如 NFS 挂载点不一致），则会导致：
    • 文件找不到（File not found）；
    • 数据不一致（不同节点看到不同内容）；
    • 权限拒绝（secure_file_priv 校验失败）。

此外，secure_file_priv 是 MySQL 兼容的安全机制，OceanBase 继承了该设计，用于防止任意路径读取造成安全风险。

#3

打卡

#4

加油