在 OceanBase 集群的搭建中,允许将多个副本(节点)分散到多个机房、多个城市中,跨机房/跨城市实现Paxos 组。在选择多机房,多城市集群架构时,通常也是为了获取机房级容灾甚至是城市级容灾的能力。从技术上来说,只要是支撑 OceanBase 集群不同副本节点的基础设施足够好, 在合理的副本分布下,OceanBase 集群就可以将数据分布在不同的节点上对外提供数据服务。通常情况下,OceanBase 集群对基础设施的基本要求是:节点间的网络延迟时间(单向延迟)最好保证在 50ms 以内,最差(单向延迟)也要在 100ms 以内。OBServer 节点环境中的时钟服务应该保证时钟同步的偏差在 100ms 以内,且不能够产生 1s 及以上的时钟跳变。通常情况下,进行多机房/多城市的的部署方案最重要的是考虑业务和各方面产生的架构需求。因为多机房/多城市的部署方式也会直接带来整个系统成本的大幅提高(比如是跨城市的网络专线部署等等)。所以不同的部署方案是一个基于成本、需求、产品能力、方案可行性等多个维度的权衡结果产出。 从技术上来讲,可以解决机房级容灾或者城市级容灾的集群解决方案有:
-
同城三机房三副本部署
- 同城 3 个机房组成一个集群(每个机房是一个 Zone),机房间网络延迟一般在 0.5 ~ 2 ms 之间。
- 机房级灾难时,剩余的两份副本依然是多数派,依然可以同步 Redo-Log 日志,保证 RPO=0。
- 无法应对城市级的灾难。

-
三地五中心五副本部署:
- 三个城市,组成一个 5 副本的集群。
- 任何一个 IDC 或者城市的故障,依然构成多数派,可以确保 RPO=0。
- 由于 3 份以上副本才能构成多数派,但每个城市最多只有 2 份副本,为降低时延,城市 1 和城市 2 应该离得较近,以降低同步 Redo-Log 的时延。
- 为降低成本,城市 3 可以只部署日志型副本(只有日志)。

在实际的部署方案中,OceanBase 集群也根据客户的需求定制过同城双机房和两地三中心的方案。两种部署方案都各自解决了一部分相应场景对于系统高可用的需求,但是同时也存在一定容灾能力的短板。在一定时期有可能作为系统架构的中间态成为客户在初始部署的选择,客户也有可能参与 OceanBase 主备库架构搭配使用一起达到期望的容灾能力。具体的方案探讨需要考虑多个因素和方面,如果有实际具体的场景,请联系 OceanBase 数据库技术架构师进行方案讨论和对接。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




