将因果集群升级到 4.x 补丁版本

本节介绍如何将 Neo4j 集群升级到相同 MAJOR 和 MINOR 版本中的更新 PATCH 版本。

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

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

从较早的补丁版本升级时，您可能还需要升级 system 数据库。使用 call dbms.upgradeStatus 检查是否需要此操作，或参阅升级系统数据库以获取更多信息。

离线升级

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

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

先决条件

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

准备升级

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

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

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

  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 文件是否已正确配置以找到这些目录。

升级集群

  1. 通过从 <NEO4J_HOME> 运行以下命令启动 Neo4j

    bin/neo4j start

    升级在启动期间进行。

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

  3. 验证集群是否形成以及升级后的 Neo4j DBMS 部署是否上线。

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

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

升级后

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

滚动升级

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

建议

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

  • 为降低滚动升级期间的失败风险，请确保集群在升级期间没有承受任何重负载。如果可能，最安全的方法是完全禁用写入。

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

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

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

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

先决条件

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

  2. 通过在Cypher® Shell或 Neo4j Browser 中运行 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]

云基础设施的滚动升级

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