OceanBase Database adopts a shared-nothing architecture with multiple replicas to ensure zero single point of failure and system continuity. OceanBase Database supports high availability and disaster recovery at the IDC (deployment of an OceanBase cluster in multiple IDCs in the same region), region (deployment of an OceanBase cluster across IDCs in different regions), and multi-region (deployment of an OceanBase cluster across regions) levels. You can deploy an OceanBase cluster in a single IDC, in two IDCs in two regions, or in three IDCs across two regions, and deploy the arbitration service to reduce costs.
Deployment solutions
Solution 1: Deploy three replicas across three IDCs in the same region
Characteristics:
- The three IDCs form a cluster (each IDC is a zone), with network latency between IDCs ranging from 0.5 to 2 ms.
- In the case of a disaster at one IDC, the remaining two replicas are still in the majority and can continue to synchronize redo logs, ensuring RPO=0.
- The solution cannot protect against disasters at the region level.
Deployment diagram:
Solution 2: Deploy five replicas across three IDCs in three regions
Characteristics:
- The three regions form a cluster with five replicas.
- A disaster in any IDC or region will not affect the majority status of the replicas. This ensures RPO=0.
- To form a majority, at least three replicas are needed. Therefore, to reduce latency, IDCs 1 and 2 in the same region should be located close to each other to lower the latency of synchronizing redo logs.
Deployment diagram:
Solution 3: Deploy two OceanBase clusters in the same region in a "primary/standby" configuration
Characteristics:
- Each IDC hosts an OceanBase cluster, one as the primary cluster and the other as the standby cluster. Each cluster has its own Paxos group for multi-replica consistency.
- Data is synchronized between the primary and standby clusters through redo logs. This is similar to the conventional "primary/standby replication" model in which data is asynchronously synchronized from the primary database to the standby database.
Deployment diagram:
Solution 4: Deploy three IDCs in two regions in a "primary/standby" configuration
Characteristics:
- The primary and standby regions form a cluster with five replicas. A disaster in the IDC of the primary region can result in the loss of at most two replicas. The remaining three replicas are still in the majority.
- The standby region builds an independent cluster with three replicas as a standby database. The primary database asynchronously synchronizes data to the standby database.
- If the primary region encounters a disaster, the standby region takes over the business.
Deployment diagram:
Solution 5: Deploy an arbitration service across three IDCs in the same region
Characteristics:
- The three IDCs form a cluster, with network latency between IDCs ranging from 0.5 to 2 ms. Two IDCs host full-featured replicas and are deployed as zones. To reduce costs, the third IDC hosts only the arbitration service (without synchronizing logs).
- In the case of a disaster at one IDC, the replicas in the remaining IDCs can compete for the arbitration service to perform arbitration downgrading (if the IDC where the full-featured replica is located encounters a disaster). This ensures RPO=0.
- The solution cannot protect against disasters at the region level.
For more information about the arbitration service, see Overview.
Deployment diagram:
Solution 6: Deploy an arbitration service across five IDCs in three regions
Characteristics:
- The five IDCs across three regions are deployed as a cluster. IDCs 1 and 2 in the same region are located close to each other to reduce the latency of synchronizing redo logs. IDC 3 is deployed to reduce costs (without synchronizing logs).
- A disaster in any IDC will not affect the majority status of the remaining full-featured replicas (at least three replicas). This ensures RPO=0.
- A disaster in any two IDCs or in one region will not affect the majority status of the remaining full-featured replicas (at least two replicas). In this case, the arbitration service can be used to restore the service (downgrading the two affected replicas to Learner replicas) to ensure RPO=0.
- To form a majority, at least three replicas are needed. Therefore, to reduce latency, IDCs 1 and 2 in the same region should be located close to each other to lower the latency of synchronizing redo logs.
Deployment diagram:
Solution 7: Deploy the arbitration service across two IDCs in one region
Characteristics:
- The primary region has two IDCs, each of which contains two zones. This configuration is suitable for deploying full-featured replicas.
- The standby region has one IDC for deploying the arbitration service, which helps reduce deployment costs and cross-region bandwidth overheads.
- If an IDC in the primary region fails, at most two replicas are lost. In this case, the remaining replicas might not form a majority (2/4). The arbitration service can trigger a downgrade and restore to ensure RPO=0.
- A disaster in the primary region cannot be handled, but a disaster in the standby region does not have any impact.
Deployment diagram:
