将因果集群升级到 4.x 修补程序版本

本部分介绍如何将 Neo4j 集群升级到同一 MAJOR 和 MINOR 版本中的较新 PATCH 版本。

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

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

从早期修补程序版本升级时，您可能还需要升级 system 数据库。使用 call dbms.upgradeStatus 检查是否需要此操作，或查看 升级系统数据库 了解更多信息。

离线升级

此变体适用于滚动升级不可行的场景。

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

先决条件

确保您已为每个集群成员完成了 升级清单 上的所有任务。

准备升级

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

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

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

  4. 将 neo4j.conf 文件替换为您在部分 准备新安装要使用的 neo4j.conf 文件 中为每个实例准备的文件。

  5. 复制用于加密的所有文件，例如私钥、公钥证书以及 trusted 和 revoked 目录（位于 <neo4j-home>/certificates/ 中）的内容。

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

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

升级您的集群

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

    bin/neo4j start

    升级在启动期间进行。

  2. 监视 neo4j.log 文件以获取有关升级将涉及多少步骤以及已进行到何种程度的信息。

  3. 验证集群是否已形成，并且已升级的 Neo4j DBMS 部署已上线。

  4. 启动每个只读副本，并等待它赶上集群中的其他成员。

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

升级后

建议使用空的 target 目录执行完整备份。

滚动升级

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

建议

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

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

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

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

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

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

先决条件

  1. 确保您已为每个集群成员完成了 升级清单 上的所有任务。

  2. 通过在 Cypher® Shell 或 Neo4j 浏览器中运行 SHOW DATABASES 验证所有数据库是否都处于联机状态。可以使用 START DATABASE [database-name] 启动脱机数据库。

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

    您绝不能运行DENY ACCESS ON DATABASE system TO PUBLIC或DENY ACCESS ON DATABASE * TO PUBLIC，因为这样会导致您无法访问system数据库。如果您真的锁定了自己，请按照操作手册中的禁用身份验证步骤恢复并阻止外部访问实例或集群。
    对于4.0版本内的PATCH升级

    1. 拒绝所有角色访问除system数据库之外的每个数据库。您可以使用SHOW ROLES查询所有可用的角色。

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

    2. 使用以下命令确保在滚动升级期间无法停止数据库

      DENY STOP ON DATABASE * TO admin

      对于admin角色和所有具有停止数据库权限的其他角色，必须执行此操作。有关列出特权的更多信息，请参见Cypher 手册 → 管理特权。
    对于4.x版本内的PATCH升级：

    1. 拒绝PUBLIC角色访问除system数据库之外的每个数据库。

      DENY ACCESS ON DATABASE [database-name] TO PUBLIC

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

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

升级集群

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

如果在滚动升级期间集群丢失了法定人数并且无法恢复，则可能需要停机时间来进行灾难恢复。
对于每个集群成员

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

  2. 关闭实例。

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

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

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

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

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

升级后步骤

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

对于4.0版本内的PATCH升级

  1. 恢复admin角色停止数据库的特权。

    REVOKE DENY STOP ON DATABASE * FROM admin

    必须针对所有被拒绝停止数据库特权的角色执行此操作（请参见固定数量服务器的滚动升级的步骤 6）。有关列出特权的更多信息，请参见Cypher 手册 4.0 → 图和子图访问控制。

  2. (可选) 如果您启动了离线数据库并在滚动升级的准备阶段拒绝了一些访问权限，那么您还应该将它们恢复到原始状态

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

      STOP DATABASE [database-name]

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

      REVOKE DENY ACCESS ON DATABASE [database-name] FROM [role1],[role2]
对于4.x版本内的PATCH升级

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

    REVOKE DENY STOP ON DATABASE * FROM PUBLIC

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

    REVOKE DENY DATABASE MANAGEMENT ON DBMS FROM PUBLIC

  3. (可选) 如果您在滚动升级的准备阶段启动了离线数据库，那么您需要停止它们以将其恢复到原始状态

    STOP DATABASE [database-name]

云基础设施的滚动升级

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