将因果集群升级到 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 Browser 中运行 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 数据库，其中包含复杂信息，例如用户、角色及其权限的安全配置。随着 DBMS 功能的增长，system 数据库中包含的图结构会随着 Neo4j 的每个新版本而变化。因此，每次升级 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. （推荐）使用空的目标目录执行一次**完整备份**。

云基础设施的滚动升级

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

© . All rights reserved.