将因果集群升级到 4.4

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

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

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

离线升级

此变体适用于滚动升级不可行的情况。

建议在类似生产的环境中执行测试升级，以获取停机时间的相关信息。

先决条件

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

在执行滚动升级到 Neo4j 4.4 时，请确保升级前的版本是 4.3 的最新版本，否则升级可能会失败。

准备升级

  1. 关闭所有集群成员（核心和只读副本）。

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

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

  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 目录中。

升级集群

在**一个**核心上

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

  2. 从 <neo4j-home> 运行以下命令启动 Neo4j

    bin/neo4j start

    升级在启动期间进行。

  3. 监控 neo4j.log 文件以获取有关升级将涉及多少步骤以及进度如何的信息。

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

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

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

  7. 请**不要**启动服务器。

在其他每个核心上

  1. 将您在第一个核心服务器上创建的数据库转储复制到其他每个核心。

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

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

对于每个只读副本

启动只读副本并等待它追赶上集群中其他成员。

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

验证只读副本是否加入集群。

升级后

建议使用空目标目录执行 *完整备份*。

滚动升级

滚动升级是一种用于升级因果集群的零停机方法。您可以一次升级一个成员，而其他成员仍在运行。但是，如果在滚动升级期间，集群失去了仲裁并且无法恢复，那么可能需要停机才能执行灾难恢复。

建议

  • 升级期间的关键点是知道何时可以安全地关闭原始成员。
    强烈建议在每次移除之前监控 状态端点，以决定关闭哪个成员以及何时可以安全地关闭。

  • 为了降低滚动升级期间发生故障的风险，请确保在升级期间集群不受任何重负载的影响。如果可能，最安全的方法是完全禁用写入。

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

  • 从 *neo4j.conf* 中删除 dbms.record_format 以避免任何意外的跨格式迁移。

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

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

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

先决条件

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

    在执行滚动升级到 Neo4j 4.4 时，请确保升级前的版本是 4.3 的最新版本，否则升级可能会失败。

  2. 通过在 Cypher® Shell 或 Neo4j 浏览器中运行 `SHOW DATABASES`，验证 **所有数据库是否在线**。离线数据库可以使用 `START DATABASE [database-name]` 启动。

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

    DENY ACCESS ON DATABASE [database-name] TO PUBLIC

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

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

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

升级集群

您一次 **升级一个集群成员**，而其他成员仍在运行。

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

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

  2. 关闭实例。

  3. 安装您要升级到的 *Neo4j* 版本。有关如何安装您正在使用的发行版的更多信息，请参见 操作手册 4.4 → 安装。

  4. 用您在 准备新安装要使用的 *neo4j.conf* 文件 中为该实例准备的文件替换 *neo4j.conf* 文件，并将 dbms.allow_upgrade=true 设置为允许自动存储升级。

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

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

  7. 在 *neo4j.conf* 文件中，配置以下设置

    1. 将 dbms.allow_upgrade=false 设置为禁用自动存储升级。

    2. 如果以前已删除 dbms.record_format，请恢复其任何自定义值。

由于只读副本不是集群共识组的一部分，因此在升级期间替换它们不会影响集群的可用性和容错级别。但是，仍然建议以增量方式添加只读副本，以实现结构化且可维护的升级过程。

升级 `system` 数据库

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

您要启用的任何特定指标都 **必须** 在 `metrics.filter` 中指定。
有关更多信息，请参见 操作手册 4.4 → 启用指标记录。
兼容性和同步

对于具有许多实例的因果集群，在依次升级每个实例时，集群会在一段时间内由一些旧实例和一些新实例组成。单个 `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. (可选) 如果您在滚动升级的准备阶段启动了离线数据库，请停止每个数据库以将它们恢复到原始状态

    STOP DATABASE [database-name]

  4. (推荐) 使用空目标目录执行 *完整备份*。

云基础设施的滚动升级

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