将因果集群升级至 4.1
企业版

本节介绍了如何升级 Neo4j 因果集群。

您可以执行滚动升级或离线升级来升级现有的 Neo4j 因果集群。

每个集群成员都必须完成先决条件和升级步骤。

离线升级

此变体适用于无法进行滚动升级的情况。

建议在生产环境的模拟环境中进行测试升级，以了解停机时间。

先决条件

确保您已完成 升级检查清单 中的所有任务。

准备升级

  1. 关闭所有集群成员（Core 和 Read Replica）。

  2. 在每个集群成员上执行 neo4j-admin unbind 以移除集群状态数据。

  3. 在每个实例上安装您想要升级到的 Neo4j 版本。有关如何安装所用发行版的更多信息，请参阅 操作手册 4.1 → 安装。

  4. 使用您在 为新安装准备新的 neo4j.conf 文件 一节中为每个实例准备好的文件替换 neo4j.conf 文件。

  5. 复制所有用于加密的文件，例如私钥、公有证书，以及受信任和已吊销目录的内容（位于 <NEO4J_HOME>/certificates/ 中）。

  6. 根据您的备份方法，使用 neo4j-admin restore（在线）或 neo4j-admin load（离线），在新安装中恢复您的每个数据库和事务，包括 system 数据库。如果您运行的是 Debian/RPM 发行版，则可以跳过此步骤。

    如果您的旧安装修改了以 dbms.directories.* 开头的配置或 dbms.default_database 设置，请验证新的 neo4j.conf 文件配置是否正确，以确保能够找到这些目录。

  7. 如果您使用的是自定义插件，请确保它们已更新并与新版本兼容，并将它们放置在 /plugins 目录中。

升级您的集群

在其中一个 Core 节点上

  1. 打开新安装的 neo4j.conf 文件并配置以下设置

  2. 通过在 <NEO4J_HOME> 中运行以下命令来启动 Neo4j

    bin/neo4j start

    升级在启动过程中进行。

  3. 监控 neo4j.log 文件，了解升级涉及的步骤数量及其进度。

  4. 升级完成后，停止服务器。

  5. 打开 neo4j.conf 文件并配置以下设置

  6. 使用 neo4j-admin dump 对您的每个数据库和事务（包括 system 数据库）进行转储。

  7. 暂时不要启动服务器。

在其余每个 Core 节点上

  1. 将您在第一个 Core 服务器上创建的数据库转储文件复制到其他所有 Core 节点。

  2. 使用 neo4j-admin load --from=<archive-path> --database=<database> --force 替换您的每个数据库（包括 system 数据库），使用在第一个 Core 服务器上升级后的版本。

  3. 启动所有核心服务器（包括第一个），并验证它们是否加入了集群。

对于每个 Read Replica 节点

启动 Read Replica 并等待它追赶上集群中的其余成员。

（可选）虽然空的只读副本最终会从集群的其他成员获取所有数据的完整副本，但这一追赶过程可能需要一些时间。为了加快此过程，您可以先使用 neo4j-admin load --from=<archive-path> --database=<database> --force 加载数据，用升级后的数据库替换您现有的数据库（包括 system 数据库）。

验证 Read Replica 是否加入了集群。

升级后

建议使用空的目标目录执行全量备份。

滚动升级

滚动升级是一种无需停机即可升级因果集群的方法。您一次升级一个成员，而其余成员保持运行。但是，如果滚动升级期间集群失去仲裁且无法恢复，则可能需要停机进行灾难恢复。

建议

  • 升级过程中的关键点是确定何时可以安全地关闭原始成员。
    强烈建议在每次移除前监控 状态端点，以确定要关闭哪个成员以及何时关闭是安全的。

  • 为降低滚动升级期间出现故障的风险，请确保集群在升级期间没有处于繁重负载下。如果可能，最安全的方法是完全禁用写入。

  • 在滚动升级期间，数据库管理不应有任何变更。有关更多信息，请参阅 操作手册 4.1 → 管理数据库。

固定数量服务器的滚动升级

此变体适用于服务器数量固定且必须原地更新的部署。

在执行固定数量服务器的滚动升级时，无法增加集群规模。因此，在替换成员时，集群的容错级别会降低。

先决条件

  1. 确保您已完成 升级检查清单 中的所有任务。

  2. 通过在 Cypher® Shell 或 Neo4j Browser 中运行 SHOW DATABASES 来验证所有数据库是否均在线。离线数据库可以使用 START DATABASE [数据库名称] 启动。

    开始滚动升级前，必须启动所有数据库。如果您必须在滚动升级期间保持某个数据库不可访问，可以使用以下命令禁用对该数据库的访问

    DENY ACCESS ON DATABASE [database-name] TO PUBLIC

    切勿运行 DENY ACCESS ON DATABASE system TO PUBLIC 或 DENY ACCESS ON DATABASE * TO PUBLIC，因为这会将您自己锁定在 system 数据库之外。如果您确实把自己锁在了外面，请按照操作手册中的 禁用身份验证 步骤进行恢复，并防止外部访问该实例或集群。

    从 Neo4j 4.0.x 升级时，您必须禁用对每个拥有该特定数据库访问权限的角色（role）的访问，因为此时 PUBLIC 尚未存在。

    DENY ACCESS ON DATABASE [database-name] TO [role1],[role2]

    可以使用 SHOW ROLES 查询所有可用角色。

  3. 确保通过使用以下命令，在滚动升级期间无法停止、创建或删除数据库

    DENY STOP ON DATABASE * TO PUBLIC
DENY DATABASE MANAGEMENT ON DBMS TO PUBLIC

    从 Neo4j 4.0.x 升级时，您只能禁用停止数据库的能力。

    DENY STOP ON DATABASE * TO admin

    这必须针对 admin 角色以及所有其他有权停止数据库的角色执行。有关列出权限的更多信息，请参阅 Cypher 手册 4.1 → 图和子图访问控制。

升级集群

您一次升级一个集群成员，而其余成员保持运行。

如果滚动升级期间集群失去仲裁且无法恢复，则可能需要停机进行灾难恢复。
对于每个集群成员

  1. （推荐）使用 状态端点 中描述的过程来评估移除旧实例是否安全。

  2. 关闭该实例。

  3. 安装您想要升级到的 Neo4j 版本。有关如何安装所用发行版的更多信息，请参阅 操作手册 4.1 → 安装。

  4. 使用您在 为新安装准备新的 neo4j.conf 文件 中为该实例准备好的文件替换 neo4j.conf 文件。

  5. 启动新实例并等待它追赶上集群中的其余成员。

  6. 使用 状态端点 验证新实例是否已成功加入集群并赶上其余成员的进度。

由于 Read Replica 不属于集群共识组，因此在升级期间替换它们不会影响集群可用性和容错级别。不过，仍建议逐步添加 Read Replica，以获得结构化且易于维护的升级过程。

升级 system 数据库

在 4.x 版本中，Neo4j 使用共享的 system 数据库，其中包含复杂信息，例如用户、角色及其权限的安全配置。随着 DBMS 功能的增长，system 数据库中包含的图结构会随每个新版本的 Neo4j 而变化。因此，每次升级 Neo4j 部署时，system 数据库的内容或架构也必须进行转换。在执行单个部署或因果集群的离线升级时，这些更改会自动发生，因为配置了 dbms.mode=SINGLE（参见 准备升级 和 升级您的集群）。但是，在执行滚动升级时，您从不使用配置值 dbms.mode=SINGLE 启动实例，即无法自动更新 system 数据库。

兼容性与同步

在拥有多个实例的因果集群中，轮流升级每个实例时，会有一段时间集群由部分旧实例和部分新实例组成。单个 system 数据库在整个集群中保持一致复制。因此，不可能在某些实例上按照新版本 Neo4j 的需求构建架构，而在其他实例上则使用旧版本架构。

当 system 数据库未与给定实例的 Neo4j 版本保持最新时，该实例将以兼容模式运行。这意味着两个 Neo4j 版本共有的功能将继续工作，但需要新架构的功能将被禁用。例如，如果您尝试授予旧架构不支持的新权限，将会收到错误且授权将失败。因此，当滚动升级完成后，您必须手动升级 system 数据库架构，才能使用所有新功能。

如果 system 数据库的架构太旧，无法启用兼容模式，服务器将无法启动。有关更多信息，请参阅 故障排除。
手动触发 system 数据库的升级

  1. 在其中一个集群成员上，调用过程 dbms.upgradeStatus() 以确定是否需要升级

    CALL dbms.upgradeStatus();
    +-------------------------------------------------------------------------------------------------------------------------+
| status             | description                                                                | resolution            |
+-------------------------------------------------------------------------------------------------------------------------+
| "REQUIRES_UPGRADE" | "The sub-graph is supported, but is an older version and requires upgrade" | "CALL dbms.upgrade()" |
+-------------------------------------------------------------------------------------------------------------------------+

    有关可能的状态值完整列表，请参阅 dbms.upgradeStatus 的状态代码。

  2. 在其中一个集群成员上，通过对 system 数据库调用过程 dbms.upgrade() 来执行升级

    CALL dbms.upgrade();
    +---------------------------+
| status    | upgradeResult |
+---------------------------+
| "CURRENT" | "Success"     |
+---------------------------+

    由于 Neo4j 使用共享的 system 数据库，升级后的 system 数据库将复制到整个集群。如果升级因故失败，状态不会改变，并且 upgradeResult 字段将描述哪些组件升级失败。

升级后步骤

滚动升级后必须执行以下步骤。

  1. 恢复 PUBLIC 角色的停止数据库权限

    REVOKE DENY STOP ON DATABASE * FROM PUBLIC

  2. 恢复 PUBLIC 角色的创建和删除数据库权限

    REVOKE DENY DATABASE MANAGEMENT ON DBMS FROM PUBLIC

  3. （可选）如果您在滚动升级的准备阶段启动了离线数据库并拒绝了一些访问权限，则也应将它们恢复到原始状态。

    1. 运行以下命令停止每个数据库：

      STOP DATABASE [database-name]

    2. 运行以下命令重新启用对数据库的访问：

      REVOKE DENY ACCESS ON DATABASE [database-name] FROM [role1],[role2]

  4. （推荐）使用空的目标目录执行全量备份。

云基础设施的滚动升级

此变体适用于使用可替换云资源或容器资源的部署。它遵循与 固定数量服务器 相同的步骤，但您可以在关闭旧成员之前添加新成员，从而保持集群的容错级别。由于只读副本（Read Replicas）不属于集群共识组，因此在升级期间替换它们不会影响集群的可用性和容错级别。不过，为了获得结构化且易于维护的升级过程，仍然建议逐步添加只读副本。

© . This site is unofficial and not affiliated with Neo4j, Inc.