知识库

规划数据中心迁移

以下知识库描述了您可以使用备份（或只读副本）来以滚动方式（无零停机时间）从一个数据中心（DC1）迁移（和/或升级）到另一个数据中心（DC2）的过程。

此方法涉及利用来自 DC1 核心节点的最新备份，然后基于备份缓慢添加 DC2 核心节点，同时删除旧的 DC1 核心节点。

具体来说，您需要遵循滚动模式

1) Add 2 cores to DC2
2) Remove 1 core from DC1
3) Add one core to DC2
4) Remove 2 remaining cores from DC1

请注意，在上述每个步骤之间，您应该监视每台机器上的集群状态端点，以确保新的加入者能够充分赶上并参与到 Raft 中，然后再关闭旧成员。

端点、示例响应以及如何解释它都记录在此处： https://neo4j.ac.cn/docs/operations-manual/current/monitoring/causal-cluster/http-endpoints/#causal-clustering-http-endpoints-status

此方法需要考虑的关键点如下

  • 由于某些核心节点位于 DC1 之外（即提交需要跨 DC 网络跳跃），您能否承受一段时间的写入吞吐量降低？

  • 如何在每个新的核心节点上获取足够最新的备份，以便在它们加入集群后不需要立即进行存储副本。

上面第二点实际上取决于您的工作负载。也就是说，如果工作负载可能非常高，那么您可能需要使用利用只读副本 (RR) 的替代方法，您将在其中在 DC2 中设置 3 个 RR，最终您将在开始滚动迁移之前关闭并解除绑定它们。

现在，如果您必须使用 RR，请按照以下说明操作

1) Start the 3 RRs some time before migration cut over date
2) Wait until they’re caught up with the Cores (let’s call the Cores dc1.1, dc1.2, dc1.3)
3) Then stop the RRs
4) Run "$bin/neo4j-admin unbind" against all RR instances
5) Reconfigure them all to be Cores (call them dc2.4, dc2.5 and dc2.6)
6) Start dc2.4 and dc2.5
7) Use the status endpoint to make sure they’re keeping up with dc1.1, dc1.1 and dc1.1
8) Then shutdown dc1.1
9) Followed by starting dc2.6
10) Lastly, shut down dc1.1 and dc1.2

同样，使用状态端点确保 dc2.6 获取最新数据并与 dc1.1、dc.2、dc2.4 和 dc2.5 保持同步。

如果一切顺利，那么您就已无停机地滚动到新的数据中心 (DC2)。

最后，您需要稍后更新 DC2.4、DC2.5 和 DC2.6 的配置以从 initial_discovery_members 等中删除 DC1 实例。

但是您不需要重新启动数据库来执行此操作 - 您只需修改配置文件并允许该设置在每个实例下次重新启动时被提取。

  • RR 试运行

1) Set up a single RR in the On-prem database
2) Try turning it into a Core
3) And making sure it catches up, using the status endpoint
4) That should give you good data on how long things are likely to take on the day of the migration