High availability with cross-cloud primary-standby databases|OceanBase Cloud| docs|Distributed Database

High availability with cross-cloud primary-standby databases

Last Updated：2026-01-29 07:18:31 Updated

In addition to supporting multiple cloud vendors, OceanBase Cloud now offers cross-cloud primary-standby database capabilities to meet the business needs of cross-cloud disaster recovery.

The cross-cloud primary-standby database feature has the following characteristics:

Stronger disaster recovery capabilities: By deploying the primary-standby databases in geographically separated regions, the system can effectively resist regional disasters such as natural disasters and data center failures. If the primary database on one cloud vendor experiences an issue, the standby database on another cloud vendor can quickly take over, minimizing business interruption.
Improved service availability: Cross-cloud deployment reduces the risk of service disruptions caused by internal issues within a single cloud vendor. If a cloud platform encounters a failure, the system can quickly switch to the standby database on another cloud, ensuring business continuity.
Cost-effectiveness: While cross-cloud deployment may introduce some management complexity and data synchronization costs, the flexibility to allocate resources across different cloud vendors allows enterprises to better balance costs and service quality.

Concepts

Global endpoint

The global endpoint is a single endpoint that can be used to access both the primary-standby databases. This configuration allows the system to route requests to the standby database without changing the application's connection endpoint when the primary database fails, minimizing the need for invasive changes to the application's address management and ensuring high availability for the business.

When the primary database is running normally, the global endpoint points to the primary database.
If the primary database fails, after you click Initiate Failover, the requests are switched to the standby database (which becomes the new primary database), and the primary database triggers a decoupling action.

Data synchronization methods

OceanBase Cloud supports two data synchronization methods for cross-cloud primary-standby databases: direct network connection and log archiving.

Direct network connection

The direct network connection method establishes a network connection between the VPCs of the primary-standby databases. Transaction logs are transmitted in real-time from the primary database to the standby databases using the Log Transport Service (LTS). The standby databases then apply these logs to their memory (MemStore) using the Log Replay Service (LRS), achieving data synchronization between the primary-standby databases. This method is characterized by low latency, high reliability, and strong security.

Working principle: The primary database provides read and write services. The standby databases synchronize data in real-time using redo logs, ensuring data consistency. The primary database connects directly to the standby databases through a VPC network, dedicated line, or public internet to achieve data synchronization.

Log archiving

The log archiving method involves the primary database periodically archiving transaction logs to the Object Storage Service (OSS). The standby databases then read these archived logs from OSS and apply them locally, achieving data synchronization and maintaining data consistency.

Applicable scenarios: This method is suitable for scenarios where a certain tolerance for data synchronization latency is acceptable and where cost efficiency is a priority. It is commonly used in non-real-time scenarios such as data backup, report analysis, and read/write separation.

Comparison of the two methods

Aspect	Direct network connection	Log archiving
Primary-standby synchronization latency	Milliseconds	Seconds
Standby database read/write separation	Supported	Not supported
Cost	Relatively high (cross-cloud private network channel)	Relatively low (cross-cloud object storage access)

Architecture patterns

Cross-cloud primary-standby architecture supports two patterns: one-primary-one-standby, and one-primary-multi-standby. The one-primary-one-standby pattern is suitable for standard disaster recovery scenarios, while the one-primary-multi-standby pattern provides higher disaster recovery redundancy and availability.

One-primary-one-standby

One-primary-multi-standby

One-primary-one-standby

The one-primary-one-standby pattern uses a dual-cloud primary-standby architecture, consisting of a primary cloud (Cloud A) and a standby cloud (Cloud B). This design ensures high availability and disaster recovery.

Deployment method: Deploy a primary database in Cloud A and a standby database in Cloud B to establish a cross-cloud one-primary-one-standby relationship.

Application connection method: Business instances connect to their respective cloud vendor's OceanBase instance through a VPC network, or access through a global endpoint to ensure automatic traffic routing during failover.

One-primary-multi-standby

The one-primary-multi-standby pattern allows for multiple standby databases to be configured with a single primary database, providing higher disaster recovery redundancy and availability.

Deployment method: Deploy the primary database and multiple standby databases across different cloud vendors or regions, connecting them through cross-cloud networks to synchronize data. This forms a cross-cloud one-primary-multi-standby disaster recovery architecture. The primary-standby databases can be flexibly distributed across multiple cloud vendors, enhancing disaster recovery redundancy. Business applications access through a global endpoint, and the system automatically routes requests based on the primary/standby status, allowing for disaster recovery switching without changing the connection address.

Application connection method: Multiple business instances connect to their respective cloud vendor's OceanBase instance through a VPC network, accessing through a global endpoint to ensure automatic traffic routing during failover. If the primary database fails, the system selects one of the standby databases as the new primary, and the global endpoint automatically points to the new primary, enabling seamless business switching.

Standby database selection strategy: The disaster recovery switching feature automatically ensures that all candidate standby databases are in sync and available. Regardless of which standby database is selected as the new primary, the system synchronizes its data to the largest synchronization point among all standby databases and ensures they are in a normal operational state.

When initiating a disaster recovery switch, users need to select an appropriate new primary database based on the following factors:

Geographic location: Consider network latency and business proximity, prioritizing standby databases closer to the business application.

Disaster recovery

Cross-cloud primary-standby databases provide two types of disaster recovery capabilities: disaster recovery switching and primary-standby switching. This ensures that business can be quickly restored when the primary database fails.

Disaster recovery switchover

Disaster recovery switchover refers to the process where, after a failure occurs in the primary database, the system automatically switches the business traffic to the standby database. In a normal primary-standby mode, the primary database mainly handles the business traffic, while the standby database synchronizes data from the primary database but does not handle business traffic, serving only as a disaster recovery preparation. Global endpoints work in conjunction with disaster recovery switchover to achieve high availability and disaster recovery capabilities, ensuring that the business does not experience any interruption.

Disaster recovery switchover in the one-primary-one-standby architecture

Disaster recovery switchover in the one-primary-multi-standby architecture

Disaster recovery switchover in the one-primary-one-standby architecture

Process	Description
Normal operation	The primary database processes business traffic. 1. The customer's primary business application server (primary) accesses the database service deployed in the primary VPC through the global endpoint. 2. Database requests are routed from the primary ODP (primary) to the corresponding tenant Tenant1 (primary). 3. After daily business data is written to the primary database, it is simultaneously synchronized to the standby database.
Normal operation	The standby database serves as a disaster recovery environment 1. Tenant1 (standby) remains synchronized with Tenant1 (primary). 2. Log backups are periodically archived to the standby database or external storage.
Disaster recovery switchover	Primary database failure The ODP and Tenant1 instances in the primary VPC become "independent instances" and can no longer handle primary business. The synchronization link is disconnected, and data synchronization to the standby database can no longer continue.
Disaster recovery switchover	Standby database becomes the primary database The customer's business application server switches to access the database service deployed in the standby VPC. The global endpoint resolution is updated to point to the new primary database (ODP standby / Tenant1 standby).
Disaster recovery switchover	Standby database handles business read/write operations The standby VPC becomes the new primary environment, fully taking over database read and write requests. Log backups continue to be archived to ensure data integrity.
Post-disaster recovery switchover	The customer's business can continue to operate with high availability.

Disaster recovery switchover in the one-primary-multi-standby architecture

When a cloud vendor fails

When a region fails

Process	Description
Normal operation	The customer's business system operates across multiple business VPCs. 1. Cloud Vendor A contains Customer Business VPC (Primary) and Customer Business VPC (Standby 1), connected to Customer Business Primary Instance and Customer Business Standby Instance 1, respectively. 2. Cloud Vendor B contains Customer Business VPC 2 (Standby 2), connected to Customer Business Standby Instance 2. 3. The primary business VPC is connected to the standby business VPC 2 through VPC Interconnect. 4. Business read/write requests are uniformly accessed through the global endpoint, which currently points to the primary database.
Normal operation	Database architecture and operations Cloud Vendor A: Region A deploys the primary instance, handling daily business read/write requests. Region B deploys standby instance 1, receiving real-time data updates from the primary database through the database synchronization mechanism. The primary instance transmits transaction logs in real-time to standby instance 1 through the Log Transport Service. Standby instance 1 applies these logs through the Log Replay Service to achieve data synchronization between primary and standby instances. Cloud Vendor B: Region A deploys standby instance 2, receiving real-time data updates from the primary database through the database synchronization mechanism. The primary instance synchronizes transaction logs to standby instance 2 through the VPC network, dedicated line network, or public network. The primary and standby instances are connected across clouds through network connection instances, and the global endpoint connects to the network connection instances of each cloud vendor.
Disaster recovery switchover	Primary database failure The primary instance in Region A of Cloud Vendor A fails, and the business can no longer process requests through the primary instance. The synchronization link is disconnected, and the standby instances no longer receive data updates from the primary database. The global endpoint needs to be rerouted to the new primary database.
Disaster recovery switchover	Select the optimal standby instance to take over production traffic from multiple standby instances The system selects the optimal standby instance as the new primary database based on factors such as data synchronization status, synchronization delay, availability, geographical location, and resource status among the standby instances. It prioritizes the standby instance with the most complete data synchronization, the smallest delay, and the highest availability. The global endpoint resolution dynamically updates to route business traffic to the selected standby database. The former primary instance (Region A of Cloud Vendor A) is removed and no longer handles primary business. The selected standby database (e.g., standby instance 1 in Region B of Cloud Vendor A) becomes the new primary database, independently handling business read/write requests. Other standby instances continue to serve as standby databases and establish synchronization relationships with the new primary database, maintaining the one-primary-multi-standby architecture.
Disaster recovery switchover	New primary database handles business read/write operations The selected standby VPC becomes the new primary environment, fully taking over database read and write requests. Log backups continue to be archived to ensure data integrity. The synchronization direction reverses, with data synchronized from the new primary database (e.g., standby instance 1) to the former primary database (now a standby instance), and other standby instances continue to synchronize data from the new primary database, maintaining the one-primary-multi-standby architecture.
Post-disaster recovery switchover	The customer's business can continue to operate with high availability.

Primary-standby switching

Primary-standby switching refers to the scenario where the standby database takes over the business operations when the primary database fails. The standby database quickly becomes the new primary database, and the business can resume without any noticeable impact. Real-time data synchronization is implemented between the primary-standby databases to ensure data consistency. The global endpoint resolution works in conjunction with primary-standby switching to automatically route traffic. In the event of a single point of failure (such as a primary database failure), disaster recovery switching is performed to maintain business continuity, achieving high availability and disaster recovery capabilities.

Primary-standby switching in the one-primary-one-standby architecture

Primary-standby switching in the one-primary-multi-standby architecture

Primary-standby switching in the one-primary-one-standby architecture

Process	Description
Normal operation	The customer's business system runs in two business VPCs. 1. Primary business VPC (blue) and standby business VPC (green). 2. The primary business APP Server connects to the primary database (Tenant1 primary & ODP primary) to handle read/write traffic in the production environment. The standby business APP Server is on standby and serves as a high-availability instance. The connection is normal, but it does not carry traffic.
Normal operation	Database architecture and operations Primary database (Tenant1 primary): Handles read/write requests for daily business operations and runs in the primary VPC. Standby database (Tenant1 standby): Receives real-time data updates from the primary database through database synchronization mechanisms to ensure data consistency between primary-standby databases. The primary-standby databases are managed by corresponding ODPs (OceanBase Database Proxies), which determine traffic routing.
Normal operation	Global endpoint resolution The primary business APP Server connects to the database through the global endpoint. Global endpoint resolution routes business traffic to the private IP address PL1 of the primary database (Tenant1 primary).
Normal operation	The primary database regularly backs up and archives logs to the backup environment.
Primary-standby switching	Primary database failure The primary database (Tenant1 primary) or the primary VPC fails, and the business cannot continue to process requests through Tenant1 primary. The connection between the primary business APP Server and the primary database is interrupted. The standby database no longer receives data synchronization from the primary database.
Primary-standby switching	Standby database takes over production traffic Global endpoint resolution dynamically updates to route business traffic to the private IP address PL2 of the standby database (Tenant1 standby). The standby business APP Server begins to handle requests and connects to Tenant1 standby, becoming the new primary business APP Server. The standby database becomes the primary database, independently handling business read/write requests.
Primary-standby switching	New backups are established. After the primary-standby switch is completed, new standby environments may be deployed to restore the primary-standby architecture to its normal state.
Post-primary-standby switching	The customer's business can continue to operate with high availability.

Primary-standby switching in the one-primary-multi-standby architecture

Process	Description
Normal operation	The customer's business system runs in multiple business VPCs. 1. Cloud Vendor A: Contains the primary business VPC (Primary1) and standby business VPC (Standby1), which are connected to the primary business instance and standby business instance 1 of the customer, respectively. 2. Cloud Vendor B: Contains the standby business VPC 2 (Standby2), which is connected to the standby business instance 2 of the customer. 3. The primary business VPC (Primary1) and standby business VPC 2 (Standby2) are connected through VPC interconnect. 4. Business read/write requests are uniformly accessed through the global endpoint, which points to the primary database.
Normal operation	Database architecture and operations Cloud Vendor A: Region A deploys the primary instance, which handles read/write requests for daily business operations. Region B deploys the standby instance 1, which receives real-time data updates from the primary database through database synchronization mechanisms. The primary instance transmits transaction logs in real time to standby instance 1 through the Log Transport Service. Standby instance 1 applies the logs through the Log Replay Service to achieve data synchronization between primary-standby databases. Cloud Vendor B: Region A deploys the standby instance 2, which receives real-time data updates from the primary database through database synchronization mechanisms. The primary instance synchronizes transaction logs to standby instance 2 through the VPC network, dedicated line, or public network. The primary and standby instances are connected across clouds through network connection instances, and the global endpoint is connected to the network connection instances of each cloud vendor.
Normal operation	Global endpoint resolution The primary business APP Server connects to the database through the global endpoint. Global endpoint resolution routes business traffic to the primary instance (in Region A of Cloud Vendor A). Data is synchronized from the primary instance to standby instance 1 (in Region B of Cloud Vendor A) and standby instance 2 (in Region A of Cloud Vendor B).
Normal operation	The primary database regularly backs up and archives logs to the backup environment. Multiple standby instances provide higher redundancy, distributed across different cloud vendors and availability zones.
Primary-standby switching	Primary database failure The primary instance in Region A of Cloud Vendor A fails, and the business cannot continue to process requests through the primary instance. The synchronization link is disconnected, and the standby instances no longer receive data synchronization from the primary database. The global endpoint needs to be rerouted to the new primary database.
Primary-standby switching	Select the optimal standby instance to take over production traffic from multiple standby instances The system selects the optimal standby instance as the new primary database based on factors such as data synchronization status, synchronization delay, availability, geographical location, and resource status of the standby instances. It prioritizes the standby instance with the most complete data synchronization, the smallest synchronization delay, and the highest availability. Global endpoint resolution dynamically updates to route business traffic to the selected standby database. The former primary instance (in Region A of Cloud Vendor A) is marked as the standby instance (former primary instance) and no longer handles primary business operations. The selected standby database becomes the primary database, independently handling business read/write requests. Other standby instances continue to serve as standby instances and establish synchronization relationships with the new primary database to maintain the one-primary-multi-standby architecture.
Primary-standby switching	New backups are established. After the primary-standby switch is completed, new standby environments may be deployed to restore the primary-standby architecture to its normal state.
Post-primary-standby switching	The customer's business can continue to operate with high availability.