如何管理JuiceFS文件系统的数据库和对象存储

随着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实例：

我不确定哪个数据库用于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微信群进行提问，如果你有其他管理技巧，也欢迎分享给我们。