Neo4j 4.0 及更高版本支持在同一 DBMS 中管理多个数据库。所有这些数据库都通过一个称为 system 的特殊数据库进行控制。

本文简要概述了 system 数据库的架构。

system 数据库的作用是定义其他数据库的配置。数据库可能有各种类型的配置。例如

许多有趣的操作工作（在幕后）发生在独立和集群环境中，这些工作由一个称为**协调器 (reconciler)** 的组件处理。请参见下面的图 2。

system 数据库在集群中进行复制，并且像任何其他数据库一样有一个领导者。4.0 及以后版本的每个数据库都在一个独立的 raft 组中。这意味着 core-1 可能是 system 数据库的领导者，而 core-2 可能是 mydb 数据库的领导者。system 数据库中的所有内容也都存储在图数据模型中。但是，此数据库中只能执行 DDL 命令（CREATE、DROP、SHOW 等），而不能执行常规的 Cypher 命令（例如 MATCH）。有代表其他数据库的节点（在本例图 2 中为 neo4j 和 mydb）。

**协调器 (reconciler)** 与另一个称为**数据库管理器 (database manager)** 的组件进行通信，后者管理实际的数据库。每个实例协调所有数据库的本地副本。如果在 core-2 上的协调器（在上述示例中）知道 mydb 在领导者 (core-1) 中变为在线，它会确保 mydb 在此实例中也变为在线。每个实例中的 system 数据库都有一个协调器和一个数据库管理器。

协调器的工作是协调期望状态（STOPPED、STARTED、DROPPED）和当前状态之间的差异。

协调器的一个重要方面是它完全异步运行，并且始终基于复制到 system 数据库中的“事实来源”期望状态。例如，如果一个服务器暂时与集群的其余部分隔离，或者由于某种原因落后，那么它将不会获得“期望状态”的更新，因此该服务器上的协调器将尚未执行其他服务器已经完成的操作更改。但是，一旦集群恢复正常，具备连接性等，协调器将继续工作。

当创建名称为 mydb 的数据库时，会在 system 数据库中创建一个带有标签 Database 的节点。该节点还有一些其他属性，如 name、status、uuid，如上图所示。值得注意的有趣之处是，当删除 mydb 数据库时，节点的标签会更改为 DeletedDatabase。

以下是单个 Database 节点的示例

如果它被删除，只需将 Database 标签更改为 DeletedDatabase

在内部唯一标识数据库的属性是 uuid，它是 UUID 类型。因此，您可以 DROP 一个数据库 neo4j，然后再 CREATE 它。在内部，第一个将带有 DeletedDatabase 标签存在，而新的将带有不同的 uuid 和 Database 标签。

备份 system 数据库时，请记住它包含操作配置。假设在对 system 数据库进行在线备份时，mydb 数据库当时处于停止状态。因此，当您恢复 system 数据库备份时，mydb 将处于停止状态。所以，操作状态始终由 system 数据库中的内容定义。

以下是执行 SHOW DATABASES 命令时协调器将发布的包含所有状态的状态图（图 3）。

文件系统中存在文件夹（例如 $neo4j_home/data/database/mydb）并不定义数据库的存在。它由 system 数据库中的内容决定。如果数据库不在 system 数据库中，即使文件夹存在，它也未注册。要让系统识别该数据库，您需要执行 CREATE DATABASE mydb。

此外，如果 system 数据库包含数据库 Xdb，并且在恢复它之前，$neo4j_home/data/database/ 位置没有这样的数据库，那么协调器将创建该文件夹，此时您将有一个空白的 Xdb。然而，如果集群中有其他实例 active 拥有一个正在运行的 Xdb 数据库，集群绑定过程将执行该数据库的**存储复制 (store copy)**，而不是创建一个空数据库。

最后，从多数据库操作角度来看，还有几点需要注意