设计弹性的多数据中心集群企业版
概述
部署弹性多数据中心集群的目标是实现高可用性、灾难恢复,并能够容忍数据中心丢失。
您应考虑集群架构和拓扑,并决定数据库主节点(Primary)和从节点(Secondary)的位置,以平衡性能和容错能力。有关数据库拓扑的建议,请参阅 简介:Neo4j 集群架构。
注意网络和流量路由
-
如果数据库主节点彼此距离较远,则会增加写入延迟。
-
为了提交更改,写入主节点必须获得法定数量(Quorum)成员(包括其自身)的确认。如果主节点相距甚远,网络延迟会增加提交时间。
推荐的集群设计模式
通过用户数据库从节点实现读取弹性
为了获得更好的读取性能,您可以将所有数据库主节点放置在一个数据中心 (DC) 中,并将从节点放置在另一个 DC 中。这种设置还提供了快速写入,因为写入操作将在单个 DC 内完成。
但是,如果包含主节点的数据中心宕机,您的集群将失去写入可用性。尽管通过从节点可能仍能保持读取可用性。
从数据中心丢失中恢复
您可以在没有故障 DC 的情况下恢复集群的写入可用性。
-
如果您在另一个 DC 中有足够的数据库从节点成员,您可以将它们的模式切换为“主节点”,而不必存储副本或等待主节点副本恢复。
-
如果需要,您可以使用从节点重新植入(re-seed)数据库。有关更多详细信息,请参阅
dbms.recreateDatabase()过程。
有关详细方案,请参阅灾难恢复指南。
主数据库的地理分布
您可以将每个主节点副本放置在不同的数据中心 (DC),至少使用三个数据中心。
因此,如果一个 DC 发生故障,只会丢失一个主节点成员,集群可以在没有数据丢失的情况下继续运行。
但是,每次写入操作都需要支付跨数据中心的延迟时间。
从数据中心丢失中恢复
此设置不会丢失法定数量,因此集群会保持运行,只是容错能力降低了(没有空间容纳额外的故障)。
为了恢复容错能力,您可以等待受影响的 DC 重新上线,或者在其他地方启动一个新的主节点成员,这将提供弹性并重建三数据中心的容错能力。
- 恢复步骤示例
-
-
启动并启用新服务器。详情请参阅 如何将服务器添加到集群。
-
从集群中移除不可用的服务器
-
首先,取消分配服务器上的数据库。
-
然后删除该服务器。
有关更多信息,请访问管理集群中的服务器。
-
-
有关详细方案,请参阅灾难恢复指南。
system 数据库的独占地理分布
system 数据库的主节点分布在三个数据中心您可以将所有用户数据库的主节点放在一个数据中心 (DC) 中,并将所有从节点放在另一个数据中心中。
在第三个 DC 中,部署一台仅承载 system 数据库主节点成员的服务器(除了前两个数据中心中的服务器之外)。
-
该服务器可以是小型机器,因为
system数据库的资源需求极小。 -
为了防止用户数据库被分配到该服务器上,请将
allowedDatabases约束设置为一个永远不会使用的名称。
您的写入速度将很快,因为它们发生在单个 DC 内。
如果一个 DC 宕机,您仍能保持 system 数据库的写入可用性,这使得恢复用户数据库的写入可用性变得更容易。
但是,如果包含主节点的数据中心宕机,用户数据库将失去写入可用性。尽管通过从节点可能仍能保持读取可用性。
从数据中心丢失中恢复
如果您丢失了包含主节点的数据中心,用户数据库将失去写入可用性,但从节点应能继续提供读取可用性。由于存在第三个 DC,system 数据库保持写入可用,因此您可以在不导致进程停机的情况下使用户数据库恢复写入可用。
但是,如果您需要使用 dbms.recreateDatabase() 过程,这将导致用户数据库停机。
- 恢复步骤示例
-
-
通过警戒将缺失的服务器标记为不存在。对于每个
Unavailable(不可用)服务器,在其中一个可用服务器上运行CALL dbms.cluster.cordonServer("unavailable-server-id")。 -
重建每个用户数据库,让其选择现有的服务器作为种子节点。您需要接受一个适合剩余数据中心的较小拓扑。
-
有关详细方案,请参阅灾难恢复指南。
容忍任意两个主节点故障的容错能力
为了容忍任意两个服务器(或两个主节点)的故障,数据库必须配置为五个主节点分配。
该配置允许在保持容错能力的同时临时移除一个主节点,例如在重启一台服务器进行维护时。
对于多数据中心部署,建议使用 2P+2P+1P 布局将五个主节点分布在三个数据中心。您还可以添加从节点,例如用于运行备份作业。请参阅图 4. 分布在三个数据中心的五个主节点分配。通过此配置,集群可以容忍任何单个数据中心的丢失。
不建议使用仅有两个数据中心(例如 3P+2P 或 4P+1P)或分布不均匀的三个数据中心(例如 3P+1P+1P)的部署。这些配置只能容忍特定数据中心的丢失,而不是任何数据中心的丢失。
如果您拥有足够的基础设施,可以将五个主节点分布在五个数据中心。
从数据中心丢失中恢复
此设置允许您丢失多达两个主数据库分配或任何单个数据中心。不会丢失法定数量,因此集群保持运行。
如果您丢失了三个主节点,则需要重建数据库,因为它已经失去了多数主节点分配,因此无法写入。但是,重建可以基于健康服务器上仍然存在的主节点和从节点分配,因此不需要备份。
- 恢复步骤示例
-
-
启动并启用新服务器。详情请参阅 如何将服务器添加到集群。
-
通过警戒将缺失的服务器标记为不存在。对于每个
Unavailable(不可用)服务器,在其中一个可用服务器上运行CALL dbms.cluster.cordonServer("unavailable-server-id")。 -
对于每个
Cordoned(被警戒的)服务器,在其中一个可用服务器上运行DEALLOCATE DATABASES FROM SERVER cordoned-server-id。这将把所有数据库分配从该服务器移动到集群中的可用服务器。 -
从集群中移除不可用的服务器
-
首先,取消分配服务器上的数据库。
-
然后删除该服务器。
有关更多信息,请访问管理集群中的服务器。
-
-
有关详细方案,请参阅灾难恢复指南。
应避免的集群设计模式
成员资格不均衡的两个数据中心
假设您决定只设置两个数据中心,在数据中心 1 (DC1) 中放置两个主节点,在数据中心 2 (DC2) 中放置一个主节点。
如果写入主节点位于 DC1,则写入速度很快,因为可以达到本地法定数量。
此设置可以容忍一个数据中心的丢失——但仅限于故障发生在 DC2 的情况下。如果 DC1 发生故障,您将丢失两个主节点成员,这意味着失去了法定数量,集群将无法进行写入。
请记住,任何问题都可能将系统推回跨数据中心写入延迟的状态。更糟糕的是,由于延迟,DC2 中的成员可能会滞后。在这种情况下,DC1 中成员的故障意味着数据库无法写入,直到 DC2 成员追上进度为止。
如果领导权转移到 DC2,这会使所有写入变慢。
最后,如果 DC1 宕机,无法保证数据不丢失。因为 DC2 中的主节点成员可能没有最新的写入记录,即使是追加写入也是如此。
总结
| 设置 | 设计 | 优点 | 缺点 | 最佳使用场景 |
|---|---|---|---|---|
推荐模式 |
||||
通过从节点实现读取弹性 |
主节点在一个数据中心,从节点在其他数据中心 |
|
|
需要快速写入的应用。集群可以容忍恢复期间的停机。 |
地理分布的数据中心 (3DC) |
每个主节点在不同的数据中心 (≥3) |
|
|
即使整个数据中心故障也需要持续可用性的关键系统。 |
仅对 |
用户数据库主节点在一个 DC,从节点在另一个, |
|
|
平衡的方法:正常的快速操作,更容易的恢复,可接受一定的停机时间。 |
容忍任何两个主节点故障 (3DC) |
五个主节点分布在三个数据中心 |
|
|
允许在保持容错能力的同时移除一个主节点,例如重启一台服务器进行维护。 |
非推荐模式 |
||||
两个 DC – 成员不均衡 |
DC1 中有两个主节点,DC2 中有一个主节点。 |
如果领导者在 DC1,写入很快。 |
|
应避免。 |
两个 DC – 成员均衡 |
两个 DC 中主节点数相等。 |
(无显著优势) |
|
应避免。 |