管理操作Infinigraph在 Aura 上不可用2025.12 版本引入
分片属性数据库的管理方式与标准 Neo4j 数据库类似，但在某些管理操作上存在差异。
管理分片数据库的别名
为分片数据库创建别名时，指定别名目标请使用虚拟数据库名称。以下示例展示了如何为分片数据库 foo-sharded 创建别名 foo
CREATE ALIAS foo FOR DATABASE `foo-sharded`管理分片数据库的服务器
服务器管理命令中的图引用必须指向分片。虚拟分片数据库会被拒绝或忽略。
以下示例展示了如何启用服务器并允许分配属性分片 foo-sharded-p000
ENABLE SERVER 'serverId' OPTIONS { allowedDatabases: ['foo-sharded-p000'] }备份与恢复
分片属性数据库是由多个数据库组成的数据库。这意味着在备份数据库时，必须分别备份所有分片，从而产生由多个较小备份链组成的分片属性数据库备份。
每个分片的备份链均使用 neo4j-admin database backup 命令生成。对于图分片，其备份链必须包含一个完整存档和 0 个或多个差异存档。每个属性分片的备份链必须仅包含一个完整备份，且不含差异备份。在实践中，这意味着要备份分片属性数据库，您需要从图分片的完整备份开始，然后是所有属性分片的备份；随后的任何差异备份只需要针对图分片。这是因为属性分片的事务日志与图分片日志相同，在应用时只是进行了过滤，因此恢复时仅需要图分片日志。
备份分片属性数据库
例如，假设有一个名为 foo 的分片属性数据库，包含一个图分片和 2 个属性分片。
-
备份每个分片，例如
bin/neo4j-admin database backup "foo*" --to-path=/backups --from=localhost:6361 --remote-address-resolution -
检查所得备份的有效性。有关命令语法和选项的详细信息，请参阅 验证数据库备份。
bin/neo4j-admin backup validate --from-path=s3://bucket/backups --database="foo"输出将指示备份是否有效。例如
| DATABASE | PATH | STATUS | | foo-g000 | /bucket/backups/foo-g000-2025-06-11T21-04-42.backup | OK | | foo-p000 | /bucket/backups/foo-p000-2025-06-11T21-04-37.backup | OK | | foo-p001 | /bucket/backups/foo-p001-2025-06-11T21-04-40.backup | OK |
恢复分片属性数据库
您可以使用 CREATE DATABASE 命令通过有效备份来播种（seed）分片属性数据库。以下示例从存储在 S3 存储桶中的备份中播种分片属性数据库 baz
CYPHER 25 CREATE DATABASE baz SET GRAPH SHARD { TOPOLOGY 3 PRIMARIES 0 SECONDARIES }
SET PROPERTY SHARDS { COUNT 2 TOPOLOGY 1 REPLICA }
OPTIONS {seedUri:"s3://bucket/backups/"};了解备份验证
由于当分片备份不在完全相同的事务 ID 上时（因为备份可以并行或顺序执行）可能会发生潜在的同步问题，因此恢复过程被设计为对不同分片处于不同事务 ID 的情况非常宽容。因此，如果每个属性分片的存储文件都在图分片的事务日志中记录的事务范围内，则分片属性数据库备份被视为有效。
例如，假设图分片的存储文件处于事务 10，且拥有事务 11-36 的事务日志；属性分片 1 的存储文件处于 13，属性分片 2 的存储文件处于 30，那么在恢复时，所有数据库都可以恢复并保持一致，直至事务 36。
您可以使用 neo4j-admin backup validate 命令来检查数据库的一组备份链是否有效。有关命令语法和选项的详细信息，请参阅 验证数据库备份。
如果属性分片领先或落后于图分片备份链中的事务范围，则可能需要执行额外操作来创建经过验证的备份。
| DATABASE | PATH | STATUS | | foo-g000 | /backups/foo-g000-2025-06-11T21-04-42.backup | OK | | foo-p000 | /backups/foo-p000-2025-06-11T21-04-37.backup | Backup is behind (3 < 5) the graph shard backup chain | | foo-p001 | /backups/foo-p001-2025-06-11T21-04-40.backup | Backup is ahead (12 > 8) of the graph shard backup chain |
要形成经过验证的备份，必须确保每个属性分片的存储文件都在图分片的事务日志记录的事务范围内。在上面的示例中，属性分片 foo-p000 落后于图分片备份链，而属性分片 foo-p001 领先于图分片备份链。要形成有效的分片属性数据库备份，您需要：
-
对属性分片
foo-p000进行完整备份，以便其存储至少包含事务 5。 -
对图分片进行差异备份，以便其事务日志中至少包含事务 12，从而将
foo-p001包含在其范围内。
一旦创建了有效的分片属性数据库备份，就可以通过对图分片进行差异备份来执行差异备份，从而扩展图分片链的范围。继续上述示例，图链包含从 11 到 36 的事务，属性分片 1 的存储文件处于 13，属性分片 2 的存储文件处于 30。然后，您对包含事务 37 到 50 的图分片进行差异备份。在恢复时，所有数据库都可以恢复到事务 50 并保持一致。
事务日志清理与恢复
在分片属性数据库中，属性分片从图分片拉取事务日志条目并将其应用到各自的存储中。因此，要求图分片在每个属性分片的每个副本都拉取并应用该条目之前，不得从其事务日志中清理该条目。否则，尚未应用最新条目的属性分片副本将无法应用，从而导致连接断开，进而引发数据不一致。如果给定属性分片的所有副本都发生这种情况，则整个分片属性数据库将处于不可恢复的状态。
为了确保保留足够的事务日志，您必须相应地设置 db.tx_log.rotation.retention_policy。一个合适的经验法则是确保保留的事务日志涵盖分片属性数据库连续完整备份之间写入的事务。确保事务日志有足够的空间以及服务器磁盘空间充足也同样重要。
从 Neo4j 2026.01 开始，为防止属性分片副本断开，系统会自动监控属性分片副本的事务应用延迟，并阻止图分片清理属性分片副本尚未应用到其存储中的条目。
此机制可防止任何属性分片副本落后于图分片上可用的事务日志范围。如果无法清理的状态持续存在，系统会将分片属性数据库置于只读模式，以防止服务器磁盘空间耗尽。一旦解决了导致属性分片滞后的根本原因，您可以通过执行以下步骤将分片属性数据库切换回读写模式：
-
确保所有属性分片的所有副本都已通过针对
system数据库运行以下查询追赶上图分片的事务日志：CYPHER 25 SHOW DATABASES YIELD name, type, role, lastCommittedTxn, replicationLag, shardTxnLagreplicationLag列显示了每个副本落后于其主库的程度，shardTxnLag列显示了每个属性分片落后于图分片的程度。
如果任何副本显示非零的replicationLag或shardTxnLag，请等待其追赶上来。
一旦所有副本的replicationLag和shardTxnLag均为零，分片属性数据库即可恢复为读写模式。 -
针对
system数据库运行 Cypher 命令ALTER DATABASE <sharded-db-name> SET ACCESS READ WRITE，将分片属性数据库恢复为读写模式。
|
如果发生系统故障转移
2026.01 引入的前述监控机制应能防止属性分片断开。然而，万一分片确实发生故障，您可以使用以下选项之一进行恢复：
|