知识库

规划数据中心迁移

以下知识库描述了一种通过备份（或读取副本）以滚动方式从一个数据中心（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 之外（即提交操作需要跨数据中心网络跳转）？

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

上述第二点取决于您的工作负载。如果工作负载非常高，那么您可能需要采用另一种方法，即利用读取副本 (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
© . All rights reserved.