如何判断数据库和对象存储是否被 JuiceFS 使用?

2024-08-16
于鸿儒(Herald Yu)

随着使用 JuiceFS 的时间越来越长,一些用户已经用多种数据库和对象存储创建了很多的 JuiceFS 文件系统。有些是纯云端的,有些是纯本地的,有些则是本地与云端结合的。它们当中有一些是存储了文件的,而有一些则只是测试目的临时创建的。多个文件系统混合在一起使用难免会混淆,特别是在同一个数据库实例中创建多个文件系统时会更为明显。

比如在一个 Redis 实例的 0 号数据库和 1 号数据库都创建了文件系统,其中一个是正常使用的,另一个是测试用的,当需要删除测试用的文件系统时,就可能会误删正常使用的文件系统。

在这篇文章会分享一些解决类似问题的日常管理技巧,希望能够帮助到更多的 JuiceFS 用户。

前置知识

在开始之前,先介绍一些 JuiceFS 的基本概念,以便大家更好地理解这些技巧。

如下图,JuiceFS 采用的是一种数据与元数据分离存储的技术架构,数据存储在对象存储中,元数据存储在数据库中。

从管理的角度来说,这就涉及到数据库和对象存储两个部分的管理。

情景一:数据库被 JuiceFS 使用了吗?

如果你也像我一样喜欢尝试用不同的数据库作为 JuiceFS 的元数据引擎,那么你可能会遇到这样的情况:有很多数据库,但不确定哪个数据库被 JuiceFS 使用。

对于这种情况,无外乎两种判断方法: 1. 用 JuiceFS 客户端执行检查; 2. 用数据库客户端执行检查。

两种方法都能用来判断,只是有些数据库更适合用第一种方法,有些数据库更适合用第二种方法。

适合用 JuiceFS 客户端检查的数据库

对于 SQLite3、Badger 这样的单机数据库,直接用 JuiceFS 客户端检查更合适。因为一个数据库只对应一个 JuiceFS 文件系统,所以只要 JuiceFS 客户端能够连接到数据库,就能够检查出这个数据库是否被 JuiceFS 使用。

例如,在我本地电脑的某个目录中发现了一个名为 my.db 的文件,我现在不确定它究竟是 JuiceFS 文件系统的元数据,还是其他应用的数据库。这时,我可以使用 JuiceFS 客户端的 status 子命令来检查:

juicefs status sqlite3://my.db

从命令输出的 JSON 中,包含文件系统的名称、UUID、存储类型、对象存储等信息,可以确定这个数据库是一个 JuiceFS 文件系统的的元数据引擎。

如果没有输出 JSON 信息,并显示 database is not formatted,那么这个就不是 JuiceFS 使用的元数据引擎。

与 SQLite3 类似,Badger 也是一个单机数据库,但它的数据库不是单个文件,而是一个目录。

比如,我在本地发现一个名为 myjfs 的目录,时间久远已经不记得它究竟是一个普通的目录,还是 badger 数据库目录。这时,我可以使用 JuiceFS 客户端的 status 子命令来检查:

juicefs status badger://myjfs

适合用数据库客户端检查的数据库

虽然完全可以用 JuiceFS 客户端进行检查,但在数据库很多,以及记不得有哪些数据库的情况下,用数据库客户端检查网络数据库会更为直观方便。

Redis

默认情况下,一个 Redis 实例有编号为 0~15 共计 16 个数据库。如果之前没有在备忘本中明确记录每个数据库的用途,那么时间久了再次要用到的时候,就很难区分哪个数据库是 JuiceFS 使用的。

比如,我有以下 Redis 实例:

地址 192.168.1.88
端口 6379
密码 password

我不确定哪个数据库用于 JuiceFS,甚至不确定是否有数据库用于 JuiceFS。这时,最简单的办法就是使用 redis-cli 客户端连接到 Redis 实例,逐一对每个数据库执行检查:

# 连接到 Redis 实例
redis-cli -h 192.168.1.88 -p 6379 -a password

# 检查哪些数据库存储了数据
192.168.1.88> info keyspace

通过 info keyspace 命令,可以看当前实例的 db0、db1 和 db3 都存储了数据,接下来就可以依次对这些数据库执行 get setting 检查是否是 JuiceFS 使用的数据库。

如图所示,db0 没有 JuiceFS 的信息,说明它不是 JuiceFS 使用的数据库。db1 和 db3 都包含 JuiceFS 的信息,说明它们是 JuiceFS 使用的数据库。

Postgres、MySQL、MariaDB

对于这三种数据库,有很多图形化客户端工具可以直接使用,比如 pgAdmin、Adminer、Navicat 等,可以直观地显示数据库中的表、数据等信息。

笔者相对更喜欢使用 Adminer,它是一个非常轻量级的数据库管理工具,可以直接通过 Docker 部署,通过浏览器访问,同时支持上述三种数据库。

假设在本地电脑上已经安装了 Docker,那么可以通过以下命令来部署 Adminer:

docker run -d -p 8080:8080 --name adminer adminer

部署完成后就可以通过浏览器访问 http://localhost:8080 来使用 Adminer。

以 Postgres 数据库为例,连接到 Postgres 数据库后,可以看到数据库中的表、数据等信息。

在数据库列表中,如果不确定哪个数据库是 JuiceFS 使用的,可以逐一点击进入数据库,查看其中的表。

如下图,JuiceFS 的表名称通常是以 jfs_ 开头的。

MySQL、MariaDB 等数据库的操作类似,访问时只需要在 Adminer 登录界面中据实选择即可。

另外,JuiceFS 还支持其他数据库,比如 TiKV、etcd、FoundationDB 等,检查它们是否用于 JuiceFS 的方法都是类似的,这里不再赘述。

情景二:对象存储被 JuiceFS 使用了吗?

对于 JuiceFS 文件系统来说,元数据引擎记录着所有文件的信息,对象存储则是保存着所有实际的文件。二者相辅相成,缺一不可。

从管理的角度来说,只要能够确定 JuiceFS 文件系统的元数据引擎,就能够确定对应的对象存储。

也就是说,只要用 juicefs status 命令扫一下相应的数据库,就能找到这个文件系统关联的对象存储。

根据输出的信息,在 Bucket 部分可以找到它使用的对象存储。当然,如果你在同一个云平台上有多个账号,最好还是从云平台的文件管理器中逐一查看 Bucket 内容。

如图所示,JuiceFS 会在 Bucket 根目录下创建一个与文件系统同名的文件夹作为根目录。打开这个目录,可以看到名为 juicefs_uuid 的文件,它是识别 JuiceFS 文件系统的关键。

另外,在文件系统的根目录下,通常还会有 chunks 和 meta 两个目录,分别存储文件的数据块和元数据备份。通过这些特征,就可以判断一个 Bucket 是否属于 JuiceFS 文件系统。

总结

以上两个场景分别介绍了如何判断已有的数据库和对象存储是否被 JuiceFS 使用,掌握了这些技巧,相信读者可以更好地管理 JuiceFS 文件系统,避免误删、误操作等问题。

文章的最后再提供几个创建 JuiceFS 文件系统时的建议: 1. 使用单机数据库作为元数据引擎时,数据库命名尽量有意义和简短。这样既方便识别,又方便后续使用; 2. 预计会长期使用的文件系统,数据库和 Bucket 建议让 JuiceFS 独享,尽量不要与其他应用共享使用,避免潜在的误操作和使用冲突; 3. 为文件系统定义一个容易识别的名称,有助于后续管理,比如在名称中添加 jfs 词缀 my-jfs、test-jfs 等。

如果你有其他问题,欢迎加入 JuiceFS 微信群进行提问,如果你有其他管理技巧,也欢迎分享给我们。

Author

于鸿儒(Herald Yu)

相关博客

基于 JuiceFS 的大数据平台上云:存储成本省 85%,性能媲美 HDFS

2024-01-10
本案例来自社区一家从事金融科技的用户。该用户在进行数据平台上云时,首个站点采用了与本地数据中心(IDC)相同的架构,在云主机上构建了基于 Hadoop 的技术栈。随着业务的迅速增长和更多站点的上线,…

POSIX 真的不适合对象存储吗?

2023-10-24
随着云计算、大数据、人工智能等技术的发展,促使很多存储产品在对象存储的基础上去实现 POSIX 接口来满足需求,组合的性能到底怎么样。

多点 DMALL:大数据存算分离下的存储架构探索与实践

2023-08-16 李铭
本文分享了多点DMALL 存算分离的云原生大数据架构的经验和挑战,并用 JuiceFS 社区版实现了与 Ranger 组件进行权限的对接

之江实验室:如何基于 JuiceFS 为超异构算力集群构建存储层

2023-06-09 洪晨
由于算力资源的天然异构性,以及不同技术实现的计算能力往往出自不同的系统架构或指令集,会导致软件不兼容性,从而提高了算力使用的门槛,也使得算力利用率难以有效提高。对面挑战最终选择了 JuiceFS 来…