知识库

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

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

假设

  • 您有一个在 3.1.x 版本中运行的 Neo4j Causal 集群,其中 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/ 中的文件

在下文中,我们指的是 文件或实例。旧文件/实例是 Neo4j 3.1 安装的文件/实例,新文件/实例是 Neo4j 3.2 安装的文件/实例。

步骤 2 - 将跟随者设置为“仅跟随者”

  • 识别旧集群安装的主节点和跟随者实例。您可以使用以下命令之一

    • Neo4j 浏览器中的 :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。根据数据库的大小,此步骤可能需要几分钟才能完成。

    • 检查您的日志/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() 可用作起点。如果您在 Web 浏览器中仍然打开了 Neo4j 浏览器,则可能需要刷新站点。

步骤 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”部分中的步骤。