All Products
Search
Document Center

ApsaraDB for OceanBase:Overview

Last Updated:Nov 27, 2024

ApsaraDB for OceanBase allows you to add standby cluster instances for a primary cluster instance to form a cluster network. In this cluster network, data is synchronized between the primary and standby instances to further improve the high availability of the database.

Principle

The primary/standby architecture consists of a primary instance and multiple standby instances (Physical_Standby). You cannot add standby instances to a standby instance in cascading mode. The primary and standby instances maintain data consistency by performing asynchronous log replication, which does not affect the stability and performance of the primary instance.

When the primary instance expectedly or unexpectedly becomes unavailable for reasons such as the failure of the majority of replicas, a standby instance can take over the services. OceanBase Database provides two disaster recovery solutions to minimize service downtime, which are lossless failover with an RPO of 0 and lossy failover with an RPO greater than 0. For more information, see Change the role of a standby instance to the primary instance. Both the primary and standby instances support data reads. However, only the primary instance supports data writes.

主备架构图

The following table describes steps in the flowchart.

Step

Description

1

An application or your business system writes data to or reads data from a database node in the primary cluster. A database node is a server on which the observer process runs.

2

After the data is written to the primary cluster, which is your production cluster, the primary cluster generates REDO logs.

3

The primary cluster automatically transfers REDO logs to the standby cluster by performing asynchronous log replication.

4

A database node of the standby cluster, which contains data backups for the primary cluster, receives the REDO logs and replays the data.

5

The application or your business system reads data from a database node in the standby cluster.

Scenarios

The primary/standby architecture is used mainly in the following two scenarios:

  • Zone-disaster recovery

Some regions of Alibaba Cloud provide only two zones. This makes it impossible for the three replicas of a single OceanBase Database instance to provide disaster recovery capabilities at the IDC (zone) level. In this case, you can create primary and standby instances in two zones to achieve cross-IDC high availability of the database. When one IDC fails, you can manually switch the business to the standby instance.

  • Geo-disaster recovery

If the business is deployed in multiple regions, you can create primary and standby instances in multiple regions to achieve cross-region high availability of the database. When one region fails, you can manually switch the business to the standby instance.

Note

The switchover between the primary and standby instances takes about 5 minutes. In this process, transient disconnections may occur. We recommend that you perform primary/standby switchover during off-peak hours and use techniques such as a connection pool to implement automatic reconnection.

Operations on primary and standby instances

You can create a standby instance as needed. The following table describes the operations that you can perform on the primary and standby instances.

Instance Type

Operation

Primary instance

You can create one or more standby instances for the primary instance. For more information, see Create a standby instance.

Standby instance

After the tenant data is synchronized from the primary instance to a standby instance, you must manually add a primary address for each tenant in the standby instance. For more information, see Add a primary address for a tenant in the standby instance.

In the event of a database disaster, you can switch the role of a standby instance to the primary instance to ensure data consistency and business availability. For more information, see Change the role of a standby instance to the primary instance.

In scenarios such as business splitting, you can decouple a standby instance from the primary instance to get two independent instances. This operation improves resource utilization. For more information, see Decouple a standby instance.