迁移因果集群
本章介绍了将因果集群从 Neo4j 3.5 直接升级到 4.x 所需的步骤。
|
将因果集群从 Neo4j 3.5 迁移至 4.x 需要停机。因此，建议在类生产环境中进行一次测试迁移，以获取停机时间的预估信息。 |
|
必须在每个集群成员上完成前提条件和迁移步骤。 |
先决条件
确保您已完成 迁移检查清单 上的所有任务。
准备迁移
迁移集群部署的策略是：从一个集群实例执行离线拷贝，然后使用拷贝的数据存储来初始化（seed）新的集群。
|
请记住，迁移是一个单一事件。请勿在每个实例上独立执行迁移！应该只进行一次迁移事件，并且该迁移后的存储将作为集群中所有其他实例的事实来源（source of truth）。这一点很重要，因为在迁移时，Neo4j 会生成随机的存储 ID；如果独立执行，您的集群最终将拥有与实例数量一样多的存储 ID。如果出现这种情况，Neo4j 将无法启动。因此，部分集群迁移步骤将在单个实例上执行，而其他步骤将在所有实例上执行。每个步骤都会说明应在何处执行必要的操作。 |
|
在此阶段，您应该选定一个实例来进行操作。这将是实际发生迁移的实例。接下来的步骤将告知您是在选定的实例上、剩余实例上还是所有实例上执行该步骤。 |
- 在每个集群成员上
-
-
确认您已关闭所有集群成员（核心节点和只读副本）。您可以查看 neo4j.log。
-
在每个实例上安装您想要迁移到的 Neo4j 版本。有关如何安装您所使用版本的更多信息，请参阅 操作手册 → 安装。
-
使用您在 为新安装准备新的 neo4j.conf 文件 一节中为每个实例准备好的文件替换 neo4j.conf。
-
复制所有用于加密的文件，例如私钥、公有证书，以及受信任和已吊销目录的内容（位于 <NEO4J_HOME>/certificates/ 中）。
如果您的旧安装修改了以
dbms.directories.*开头的配置或dbms.active_database设置，请确认新的 neo4j.conf 文件已正确配置以找到这些目录。
-
迁移数据
- 在选定的实例上
-
使用 4.x Neo4j Admin 工具迁移您的 3.5 Neo4j 数据存储。
neo4j-admin copy命令还会删除任何不一致的节点、属性和关系，并且不会将其复制到新创建的存储中。-
在 <NEO4J_HOME> 文件夹中，运行以下命令来复制数据存储。您需要指定旧的存储位置和目标更新数据库的名称：
bin/neo4j-admin copy --from-path=/path/to/3.5.x/graph.db --to-database=<db_name>Starting to copy store, output will be saved to: $NEO4J_HOME/logs/neo4j-admin-copy-2020-11-26.16.07.19.log 2020-11-26 16:07:19.939+0000 INFO [StoreCopy] ### Copy Data ### 2020-11-26 16:07:19.940+0000 INFO [StoreCopy] Source: /path/to/3.5.x/graph.db (page cache 8m) 2020-11-26 16:07:19.940+0000 INFO [StoreCopy] Target: $NEO4J_HOME/data/databases/db_name (page cache 8m) 2020-11-26 16:07:19.940+0000 INFO [StoreCopy] Empty database created, will start importing readable data from the source. 2020-11-26 16:07:21.661+0000 INFO [o.n.i.b.ImportLogic] Import starting Import starting 2020-11-26 16:07:21.699+0000 Estimated number of nodes: 50.00 k Estimated number of node properties: 50.00 k Estimated number of relationships: 0.00 Estimated number of relationship properties: 50.00 k Estimated disk space usage: 2.680MiB Estimated required memory usage: 8.598MiB (1/4) Node import 2020-11-26 16:07:22.220+0000 Estimated number of nodes: 50.00 k Estimated disk space usage: 1.698MiB Estimated required memory usage: 8.598MiB .......... .......... .......... .......... .......... 5% ∆239ms .......... .......... .......... .......... .......... 10% ∆1ms .......... .......... .......... .......... .......... 15% ∆1ms .......... .......... .......... .......... .......... 20% ∆0ms .......... .......... .......... .......... .......... 25% ∆1ms .......... .......... .......... .......... .......... 30% ∆0ms .......... .......... .......... .......... .......... 35% ∆0ms .......... .......... .......... .......... .......... 40% ∆1ms .......... .......... .......... .......... .......... 45% ∆0ms .......... .......... .......... .......... .......... 50% ∆1ms .......... .......... .......... .......... .......... 55% ∆0ms .......... .......... .......... .......... .........- 60% ∆51ms .......... .......... .......... .......... .......... 65% ∆0ms .......... .......... .......... .......... .......... 70% ∆0ms .......... .......... .......... .......... .......... 75% ∆1ms .......... .......... .......... .......... .......... 80% ∆0ms .......... .......... .......... .......... .......... 85% ∆0ms .......... .......... .......... .......... .......... 90% ∆1ms .......... .......... .......... .......... .......... 95% ∆0ms .......... .......... .......... .......... .......... 100% ∆0ms (2/4) Relationship import 2020-11-26 16:07:22.543+0000 Estimated number of relationships: 0.00 Estimated disk space usage: 1006KiB Estimated required memory usage: 15.60MiB (3/4) Relationship linking 2020-11-26 16:07:22.879+0000 Estimated required memory usage: 7.969MiB (4/4) Post processing 2020-11-26 16:07:23.272+0000 Estimated required memory usage: 7.969MiB -......... .......... .......... .......... .......... 5% ∆356ms .......... .......... .......... .......... .......... 10% ∆0ms .......... .......... .......... .......... .......... 15% ∆1ms .......... .......... .......... .......... .......... 20% ∆0ms .......... .......... .......... .......... .......... 25% ∆0ms .......... .......... .......... .......... .......... 30% ∆1ms .......... .......... .......... .......... .......... 35% ∆0ms .......... .......... .......... .......... .......... 40% ∆0ms .......... .......... .......... .......... .......... 45% ∆1ms .......... .......... .......... .......... .......... 50% ∆0ms .......... .......... .......... .......... .......... 55% ∆0ms .......... .......... .......... .......... .......... 60% ∆0ms .......... .......... .......... .......... .......... 65% ∆1ms .......... .......... .......... .......... .......... 70% ∆0ms .......... .......... .......... .......... .......... 75% ∆0ms .......... .......... .......... .......... .......... 80% ∆0ms .......... .......... .......... .......... .......... 85% ∆0ms .......... .......... .......... .......... .......... 90% ∆0ms .......... .......... .......... .......... .......... 95% ∆1ms .......... .......... .......... .......... .......... 100% ∆0ms IMPORT DONE in 2s 473ms. Imported: 1 nodes 0 relationships 1 properties Peak memory usage: 15.60MiB 2020-11-26 16:07:24.140+0000 INFO [o.n.i.b.ImportLogic] Import completed successfully, took 2s 473ms. Imported: 1 nodes 0 relationships 1 properties 2020-11-26 16:07:24.668+0000 INFO [StoreCopy] Import summary: Copying of 100704 records took 4 seconds (25176 rec/s). Unused Records 100703 (99%) Removed Records 0 (0%) 2020-11-26 16:07:24.669+0000 INFO [StoreCopy] ### Extracting schema ### 2020-11-26 16:07:24.669+0000 INFO [StoreCopy] Trying to extract schema... 2020-11-26 16:07:24.920+0000 INFO [StoreCopy] ... found 1 schema definitions. The following can be used to recreate the schema: 2020-11-26 16:07:24.922+0000 INFO [StoreCopy] CALL db.createIndex('index_5c0607ad', ['Person'], ['name'], 'native-btree-1.0', {`spatial.cartesian-3d.min`: [-1000000.0, -1000000.0, -1000000.0],`spatial.cartesian.min`: [-1000000.0, -1000000.0],`spatial.wgs-84.min`: [-180.0, -90.0],`spatial.cartesian-3d.max`: [1000000.0, 1000000.0, 1000000.0],`spatial.cartesian.max`: [1000000.0, 1000000.0],`spatial.wgs-84-3d.min`: [-180.0, -90.0, -1000000.0],`spatial.wgs-84-3d.max`: [180.0, 90.0, 1000000.0],`spatial.wgs-84.max`: [180.0, 90.0]}) 2020-11-26 16:07:24.923+0000 INFO [StoreCopy] You have to manually apply the above commands to the database when it is stared to recreate the indexes and constraints. The commands are saved to $NEO4J_HOME/logs/neo4j-admin-copy-2020-11-26.16.07.19.log as well for reference.使用直接路径时，索引不会自动迁移，因此您必须重新创建它们。运行存储迁移后，
neo4j-admin copy命令会提取模式（schema）并生成一系列命令，供您稍后在新 4.x 存储上重建模式使用。重建模式的命令也会保存在 /logs 目录下的迁移日志文件中。
-
准备初始化集群
- 在选定的实例上
-
使用
neo4j-admin dump对您新迁移的数据库和事务进行转储（dump）。bin/neo4j-admin dump --database=neo4j --to=$BACKUP_DESTINATION/neo4j.dump请注意，迁移后，Neo4j Admin 命令可能会略有不同，因为 Neo4j 现在支持多个数据库。
暂时不要启动服务器。
初始化集群
如果您要迁移到 4.3 之前的 Neo4j 版本，并且您的迁移后的数据库在 neo4j.conf 中被设置为 default 数据库，则应将迁移后的数据库目录从选定实例复制到所有其他实例以初始化集群。此步骤是必需的，以确保数据库启动时所有实例都拥有相同的数据库副本。如果迁移后的数据库不是 default 数据库且 Neo4j 版本为 4.3+，则无需此步骤。
-
将转储文件复制到其余实例。
-
使用
neo4j-admin load --from=<archive-path> --database=<db_name> --force将每个数据库替换为在选定实例上迁移的数据库。bin/neo4j-admin load --from=$BACKUP_DESTINATION/neo4j.dump --database=neo4j --force
启动集群
- 在每个集群成员上（包括选定的实例）
|
继续之前，请确保已完成以下活动并成功结束：
|
-
如果列表中的所有操作均已成功，您可以继续启动集群的所有实例。
bin/neo4j start或
systemctl start neo4j -
如果迁移后的数据库是
default数据库，它应该在实例启动时自动启动，无需此步骤。如果迁移后的数据库不是default数据库，它仍处于STOPPED状态。您现在需要启动数据库。在其中一个集群成员上，在 Neo4j Browser 或 Cypher® Shell 中运行以下命令：Neo4j 4.0/4.1/4.2CREATE DATABASE <db_name>;Neo4j 4.3+CREATE DATABASE <db_name> OPTIONS { existingData : 'use', existingDataSeedInstance: '<seedInstanceId>'};其中
<seedInstanceId>是选定实例的 ID，可以通过调用CALL dbms.cluster.overview()找到。
重建索引
最后一步是重建 neo4j-admin copy 命令输出的任何索引或约束。在其中一个集群成员上，将当前数据库切换为新迁移的数据库，并运行以下过程：
CALL db.createIndex('index_5c0607ad', ['Person'], ['name'], 'native-btree-1.0', {`spatial.cartesian-3d.min`: [-1000000.0, -1000000.0, -1000000.0],`spatial.cartesian.min`: [-1000000.0, -1000000.0],`spatial.wgs-84.min`: [-180.0, -90.0],`spatial.cartesian-3d.max`: [1000000.0, 1000000.0, 1000000.0],`spatial.cartesian.max`: [1000000.0, 1000000.0],`spatial.wgs-84-3d.min`: [-180.0, -90.0, -1000000.0],`spatial.wgs-84-3d.max`: [180.0, 90.0, 1000000.0],`spatial.wgs-84.max`: [180.0, 90.0]})迁移后操作
重建用户数据
Neo4j 3.5.x 将用户和角色信息存储在 $NEO4J_HOME/data/dbms 目录下的平面文件中。从 Neo4j 4.0 开始，此信息改为存储在 system 数据库中。如果您使用了原生用户，则需要重建它们。转到备份的旧 $NEO4J_HOME/data/dbms 目录。身份验证数据位于 auth 文件中，这是一个以冒号分隔的 CSV 文件，如下所示：
neo4j:SHA256,1066956C2D4E46C810CA39AE218AAD128854F2C08E9E831C379958CBFA6FF17D,899F9D67F2
96746766848D92B325B29EAFD9AC93940257713BA7CF4CF2B166FF:第一列包含用户名，第二列包含密码信息。可以使用针对 system 数据库的 CREATE USER 语句重建用户，例如：
CREATE USER neo4j SET ENCRYPTED PASSWORD
‘0,1066956C2D4E46C810CA39AE218AAD128854F2C08E9E831C379958CBFA6FF17D,899F9D67F29
6746766848D92B325B29EAFD9AC93940257713BA7CF4CF2B166FF’ CHANGE NOT REQUIRED其中字符串 SHA-256 被字符 0（零）替换。
角色数据位于 roles 文件中，如下所示：
admin:neo4j这可以通过再次针对 system 数据库运行以下命令来重建：
GRANT ROLE admin TO neo4j您可以使用 Neo4j 解析 auth 和 roles 文件。这将处理这些文件并生成重建所有用户和角色所需的所有 CREATE USER 和 GRANT ROLE 命令。为此，您只需将备份的 auth 和 roles 文件移至 Neo4j 的 /import 目录即可。之后，您可以使用以下两个查询，一个用于用户，另一个用于角色：
LOAD CSV FROM 'file:///auth' as line
with split(line[0], ":")[0] as user, split(line[2], ":") as hash
with user, hash[0] as pwd, CASE hash[1] WHEN "" THEN "NOT" ELSE "" END as
pwdChange
with "CREATE OR REPLACE USER "+user+" SET ENCRYPTED PASSWORD '0,"+pwd+"' CHANGE
"+pwdChange+" REQUIRED" as cypher
return *LOAD CSV FROM 'file:///roles' as line FIELDTERMINATOR ':'
WITH line[0] as role, split(line[1],",") as users
UNWIND users as user
with "GRANT ROLE "+role+" TO "+user as cypher
return *这些查询中的每一个都会返回一系列 Cypher 命令，在针对 system 数据库执行时，它们会重建之前在 Neo4j 3.5.x 部署中使用的所有用户和角色。