迁移因果集群
本章介绍了将因果集群从 Neo4j 3.5 直接迁移到 4.x 所需的步骤。
|
将因果集群从 Neo4j 3.5 迁移到 4.x 需要停机。因此，建议在类似生产的环境中执行测试迁移，以获取停机时间的信息。 |
|
每个集群成员都必须完成先决条件和迁移步骤。 |
先决条件
确保您已完成迁移清单上的所有任务。
准备迁移
迁移集群部署的策略是从一个集群实例完成离线复制，然后使用复制的存储来初始化新集群。
|
请记住，迁移是一个单一事件。不要在每个实例上执行独立的迁移！应该只有一个迁移事件，并且该迁移后的存储将成为集群所有其他实例的真相来源。这很重要，因为在迁移时，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` 命令会提取模式并生成一系列命令，您以后可以使用这些命令在新的 4.x 存储上重新创建模式。重新创建模式的命令也保存在迁移日志文件中，位于 */logs* 目录中。
-
准备初始化集群
- 在选定的实例上
-
使用 `neo4j-admin 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这可以通过再次针对系统数据库运行以下命令来重新创建
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 部署中以前使用的所有用户和角色。