规划数据中心迁移
以下知识库描述了您可以使用备份（或只读副本）进行的过程，以在滚动方式下将一个数据中心（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，随后再关闭旧成员。
此端点、示例响应及其解释方法记录在此处： /docs/operations-manual/current/monitoring/causal-cluster/http-endpoints/#causal-clustering-http-endpoints-status
采用此方法时需要考虑的关键点如下
-
您是否能接受写入吞吐量在某段时间内下降，因为部分核心位于 DC1 之外（即提交需要跨数据中心网络跳转）
-
如何为每个新核心获取足够最新的备份，以便它们加入集群后不需要立即复制存储。
上述第二点实际上取决于您的工作负载。如果工作负载非常高，您可能需要采用利用只读副本（RR）的替代方案，即在 DC2 中部署 3 台只读副本，并在开始滚动迁移前将其关闭并解绑。
现在，如果必须使用只读副本，请遵循以下指令
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 实例移除。
但无需重启数据库来完成此操作——只需修改配置文件，设置将在每个实例下次重启时生效。
-
只读副本演练
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此页面有帮助吗？