GridDB Rust 客户端获取容器时报“Container not found”，如何排查？

2026-11-04数据小陈

结论

先核对创建容器的客户端和 Rust 程序是否连接同一集群、访问同一数据库，以及容器名称是否一致。当前代码查找的是 myCluster 集群中 public 数据库下的 users。如果容器在其他数据库中，这次查找仍可能失败。

仅凭示例和 Container not found 无法确定具体根因。get_store(props) 返回成功，也不能说明后续容器访问一定正常。

为什么获取 Store 成功，获取容器仍会失败？

GridStore 对象的创建和实际容器访问是两个阶段。官方编程指南说明，实际连接可能在首次创建、查找容器等数据操作时才建立。因此，排查时应查看 get_container("users") 的结果，不能只看 Store 是否创建成功。参见 GridDB 编程指南。

官方 Rust 客户端基于 GridDB C Client 开发，但题目未提供实际使用的 crate 来源和版本。具体的错误映射需要结合对应实现确认。参见 GridDB Rust 客户端仓库。

按什么顺序排查？

1. 对照两个客户端的连接配置

取出之前成功创建容器的客户端所用的实际配置，逐项比较：

集群地址是否指向同一套部署，特别要区分本地、测试和生产环境。
cluster_name 是否确实为 myCluster。
创建容器时使用的数据库是否为 public。
使用的账号是否一致；如果不同，确认其数据库访问权限。

可以优先检查数据库。GridDB 连接只能访问该连接指定数据库中的数据；访问其他数据库需要建立对应连接。参见 GridDB 数据库连接说明。

如果容器实际创建在其他数据库中，应修改 database 后重新调用 get_store，再获取容器。

2. 用原客户端再次确认容器存在

让创建容器的客户端重新连接，并在目标数据库中读取 users 的容器信息。确认实际名称和创建操作的结果，不要只依据之前打印过的“创建成功”日志。

检查拼写、前后空格和其他字符差异。也不要直接将问题归因于大小写：GridDB 普通容器名称的 ASCII 大小写通常不敏感，而 SQL/TQL 中的双引号名称有单独的规则。参见 GridDB 命名规则。

3. 记录查找目标和完整错误

可以保留原有调用方式，把查找目标集中到变量中，并在失败位置打印错误。以下片段用于替换原代码中获取容器的部分：

let container_name = "users";

eprintln!(
    "Fetching container: cluster={}, database={}, name={:?}",
    "myCluster", "public", container_name
);

let container = match store.get_container(container_name) {
    Ok(container) => container,
    Err(error) => {
        eprintln!("get_container failed: {:?}", error);
        return Err(error.into());
    }
};

println!("Container fetched");

示例沿用题目中返回 Result 的接口形式，仅用于补充诊断信息，不能直接修复容器查找失败。修改连接配置后，也要同步修改日志中的目标值。错误中是否包含底层错误码和详细原因，取决于当前客户端的实现。

配置一致后仍然失败怎么办？

如果原客户端使用同一集群、数据库和账号能够读取 users，而 Rust 客户端仍然失败，可以检查 Cargo.toml、Cargo.lock 中的 crate 来源与版本，再对照该版本的文档确认连接属性和 API 用法。不要直接套用其他 Rust 客户端或其他版本的导入路径与初始化方法。

继续定位时，需要保留完整错误、Rust crate 版本、GridDB Server 版本，以及使用 C Client 时实际加载的库版本。这些信息有助于区分配置、兼容性和客户端封装问题。

在确认容器确实缺失之前，不建议通过自动创建新的 users 来消除错误。这样可能在错误的数据库中创建空容器，原有数据仍然无法访问。