知识库

将您的因果集群从 3.1.x 升级到 3.2.x

本文概述了将 Neo4j 3.1.2+ 因果集群升级到 3.2.2 的可能步骤。对于此升级路径，Neo4j 不支持滚动升级，因此需要停机才能完成此过程。但是，以下步骤尝试在保留数据安全性/高可用性的同时，最大限度地减少读写操作的停机时间。这种权衡可能并非适用于所有设置。

前提条件

  • 您有一个运行正常的 Neo4j 因果集群 3.1.x 版本（x>=2）。

  • 您有三台核心服务器，且没有副本服务器。

  • 您的操作系统是 Linux。

  • Neo4j 的安装是通过解压 .tar.gz 文件完成的。

  • 您已获得多数据中心操作许可，详情请参阅 https://neo4j.ac.cn/docs/operations-manual/current/clustering/causal-clustering/multi-data-center/#multi-dc-licensing。

  • 在遵循本文的升级步骤时，您的配置、插件以及 data/dbms/ 中的文件未发生更改（当然，步骤中描述的调整除外）。

  • 您的可用磁盘空间至少是当前安装（包括数据库文件）的两倍。

升级步骤

在执行以下步骤之前，请仔细阅读整篇文章，并在预生产环境中测试该过程。

步骤 0 - 准备

  • 确保您可以访问 Neo4j 3.2.2 的安装源。

  • 确保您的客户端应用程序有良好的错误处理机制，因为它们将在短时间内收到异常。例如，在使用 Java 驱动程序时，您可能希望将其配置为 Config.build().withMaxTransactionRetryTime( .. ).toConfig()。

  • 确保您的客户端应用程序区分读事务和写事务。即，每当您只进行读取操作时，请使用 session.readTransaction() 或将会话的访问模式设置为 AccessMode.READ。

  • 确保您的所有插件都与新版本兼容。

  • 备份您的数据库。

步骤 1 - 安装 Neo4j 3.2.2

在每台服务器上

  • 解压 neo4j-enterprise-3.2.2-unix.tar.gz 文件

  • 将以下目录中的所有文件从旧的（正在运行的）Neo4j 安装复制到新解压的（仍处于关机状态的）安装（保留目录结构）

    • conf/ 中的文件

    • data/dbms/ 中的文件

    • plugins/ 中的文件

在下文中，我们将 old 和 new 指代文件或实例。旧文件/实例指 Neo4j 3.1 安装，新文件/实例指 Neo4j 3.2 安装。

步骤 2 - 将副本服务器设置为“只读副本”模式

  • 识别旧集群安装中的主节点和副本节点。您可以使用以下命令之一：

    • Neo4j Browser 中的 :sysinfo 或

    • 通过 Cypher 调用 CALL dbms.cluster.overview()

  • 选择一个尚未处于“只读副本”模式的副本实例

    • 在该实例的旧 neo4j.conf 文件中

    • 设置/添加 causal_clustering.refuse_to_be_leader=true 以及

    • 设置/添加 causal_clustering.multi_dc_license=true。

    • 重启该实例，它将不再能够成为主节点。

    • 等待此实例再次启动并运行。

  • 重复步骤 2，直到所有副本节点（在此场景中为两个）都处于“只读副本”模式。

在此步骤中，您可能会遇到处理读取请求时的短暂延迟（几毫秒）。但是，如果您已将应用程序配置为重试事务（参见步骤 0），则不会出现停机。此步骤完成后，我们将拥有一个三实例集群，其中只有一个实例被允许成为主节点。这会降低写入操作的高可用性。例如，如果主节点现在出现故障，读取操作仍将继续处理，但无法进行写入操作。

步骤 3 - 关闭主节点

  • 停止旧的主节点。此步骤开始写入操作的停机时间！读取操作仍通过两个副本实例处理。

步骤 4 - 将数据库复制到新的主节点

  • 在旧的主节点实例上

    • 将您的（旧的）活动数据库文件夹（默认：data/databases/graph.db）复制到新的 3.2.x 安装（已在步骤 1 中设置）。通过复制数据库文件夹，我们仍然可以获得最新的写入数据以供回滚。

步骤 5 - 配置 3.2.x 进行格式迁移

  • 在主节点服务器上，新 3.2.x 的 neo4j.conf 文件中，确保设置以下参数：

    • dbms.allow_format_migration=true

    • dbms.mode=SINGLE

步骤 6 - 升级数据库文件（格式迁移）

  • 在新安装的主节点服务器上

    • 启动 Neo4j 3.2.x。根据数据库的大小，此步骤可能需要一些时间才能完成。

    • 检查您的 logs/neo4j.log 文件以确认成功。它应该包含以下行：2017-07-06 18:08:59.933+0000 INFO Successfully finished upgrade of database

    • 停止 Neo4j 3.2.x。我们现在有了一个升级后的数据库，可以用来引导新集群。

步骤 7 - 恢复步骤 5 中的配置

  • 在主节点服务器上，新的 conf/neo4j.conf 文件中，确保设置以下参数：

    • dbms.allow_format_migration=false

    • dbms.mode=CORE

步骤 8 - 引导集群

  • 将新升级的数据库文件夹（默认：data/databases/graph.db）复制到副本实例的新安装目录中。即：

    • 将新的活动数据库文件夹从主节点服务器复制到其中一个新副本安装目录中。

    • 将新的活动数据库文件夹从主节点服务器复制到另一个新副本安装目录中。

步骤 9 - 切换版本

从一个旧的副本实例开始

  • 停止该实例。

对第二个副本实例重复此过程。这是读取操作停机的开始！

  • 现在，启动新集群

    • 启动新的主节点实例。

    • 启动两个新的副本实例。

此过程停止了读写操作的停机时间。

步骤 10 - 验证

验证您的集群是否健康。CALL dbms.cluster.overview() 可用作起点。如果您的 Neo4j Browser 仍然在 Web 浏览器中打开，您可能需要刷新页面。

步骤 11 - 备份

  • 对您正在运行的数据库进行完整备份，包括一致性检查，以验证升级后的数据库。

步骤 12 - 移除 3.1.x

  • 删除所有三台服务器上的旧安装文件。

回滚场景

以下部分描述了将您的设置恢复到原始状态的步骤。根据您决定何时回滚，您将跳转到以下某个部分并执行其中描述的步骤。

来自上述步骤 1

  • 从所有服务器中删除新安装文件。

来自上述步骤 2

  • 遵循“来自上述步骤 1”部分中的步骤。

来自上述步骤 3

从一个旧的副本实例开始

  • 在该实例的旧 neo4j.conf 文件中

    • 设置 causal_clustering.refuse_to_be_leader=false 或完全删除该参数，并且

    • 将 causal_clustering.multi_dc_license 恢复到其原始配置值。

  • 重启（旧的）副本实例。

  • 等待此实例再次启动并运行。> 对第二个副本实例重复此过程。

  • 遵循“来自上述步骤 1”部分中的步骤。

来自上述步骤 4、5、6、7 或 8

  • 启动旧的主节点

此步骤标志着写入停机时间的结束！

  • 遵循“来自上述步骤 3”部分中的步骤。

来自上述步骤 9 或 10

请注意，执行以下操作时，您将丢失已提交到新集群的写入数据！

  • 停止新的副本节点。

  • 停止新的主节点。

  • 启动旧的主节点。

  • 遵循“来自上述步骤 3”部分中的步骤。

© . All rights reserved.