High availability with cross-cloud primary-standby databases

OceanBase Cloud supports cross-cloud primary-standby databases. This feature allows you to deploy primary and standby databases across different cloud vendors, ensuring business continuity and disaster recovery.

Cross-cloud primary-standby databases deployment

In a cross-cloud primary-standby databases deployment, a primary database instance is created on one cloud vendor, and one or more standby instances are created on other cloud vendors. Data is synchronized between the primary and standby instances.

The cross-cloud primary-standby databases deployment has the following features:

• Stronger disaster recovery capability: By deploying the primary and standby instances in geographically separated regions, the deployment can effectively resist regional disasters such as natural disasters and data center failures. If the primary instance on one cloud vendor fails, the standby instance on another cloud vendor can quickly take over, minimizing the impact of business interruptions.

• Higher service availability: Cross-cloud deployment reduces the risk of service disruptions caused by internal issues on a single cloud vendor. If a failure occurs on one cloud platform, the system can quickly switch to the standby instance on another cloud platform, ensuring business continuity.

• Cost-effectiveness: Although cross-cloud deployment may increase management complexity and data synchronization costs, it allows enterprises to flexibly allocate resources across different cloud vendors, achieving a better balance between cost and service quality.

OceanBase Cloud allows you to create a data instance with one primary and multiple standby instances and a database instance with one primary and one standby instance across clouds through network connections.

Create a database instance with one primary and multiple standby instances across clouds

Deploy the primary and standby instances on two cloud vendors. For example, you can deploy one primary instance and one standby instance on Cloud A and one standby instance on Cloud B, or deploy one primary instance on Cloud A and two standby instances on Cloud B. This forms a cross-cloud primary-standby databases deployment with one primary and multiple standby instances.

• The primary instance provides read and write services. The standby instances synchronize data in real time through redo logs to ensure data consistency.

• Log synchronization chain: The primary instance transmits transaction logs to each standby instance through the Log Transport Service (LTS). The standby instances apply the logs to the MemStore in memory through the Log Replay Service (LRS), achieving data synchronization between the primary and standby instances.

• Global address: Applications access the database through the global address, which serves as a unified entry point. The global address automatically routes traffic to the current primary instance. When a primary-standby switch occurs, the global address automatically points to the new primary instance, allowing applications to switch seamlessly without modifying the connection configuration.

• Application connection method: Multiple business instances connect to their respective OceanBase instances on each cloud vendor through a Virtual Private Cloud (VPC) network. They access the database through the global address, ensuring automatic traffic routing during switches.

Create a database instance with one primary and one standby instance across clouds

In a cross-cloud primary-standby databases deployment, the primary instance is deployed on Cloud A, and the standby instance is deployed on Cloud B. This design ensures high availability and disaster recovery. Each cloud platform has two regions, Region A and Region B, where independent database instances and Object Storage Service (OSS) object storage services are deployed.

• Cloud A efficiently distributes data through internal write routing.

• Cross-cloud synchronization ensures data consistency between the primary and standby instances by synchronizing data to the standby cluster instance over the public internet.

• You can view the data synchronized to the standby cluster instance on Cloud B.

Cross-cloud high availability with primary-standby database disaster recovery

This section describes the disaster recovery scenarios of cross-cloud high availability, including primary-standby switching and disaster recovery switching.

Primary-standby switching

Primary-standby switching refers to the process of actively switching the roles of the primary and standby databases to smoothly migrate business traffic. This is mainly used in the following scenarios:

• Planned maintenance: When planned operations such as system upgrades, hardware maintenance, or configuration adjustments are required on the primary database, you can actively execute primary-standby switching to redirect business traffic to the standby database, ensuring uninterrupted business operations during maintenance. After maintenance, you can switch back to the original primary database or maintain the new primary-standby relationship.

• Performance optimization: When performance bottlenecks or resource shortages occur in the primary database's cloud vendor or region, you can switch to a standby database with better performance to improve overall business performance. For example, the standby database may offer superior network bandwidth or computing resources.

• cloud vendor migration: When an enterprise needs to migrate from one cloud vendor to another, primary-standby switching can be used to gradually migrate business operations from the original cloud vendor to the target cloud vendor, ensuring a smooth cloud migration process.

• Load balancing: Based on business needs or cost optimization strategies, you can regularly switch between primary and standby databases to dynamically allocate cross-cloud resources, ensuring high availability while optimizing the cost structure.

• Testing and validation: When testing new features, performance, or conducting disaster recovery drills on the standby database, you can temporarily switch the standby database to the primary role to verify its integrity and availability, ensuring that the disaster recovery capabilities meet expectations.

During primary-standby switching, the global address automatically updates to point to the new primary database, allowing business operations to seamlessly transition without requiring changes to the application's connection configuration. After the switch, the original primary database becomes the standby, and the original standby becomes the primary, with the primary-standby synchronization relationship automatically rebuilt to ensure data consistency.

Disaster recovery switching

Disaster recovery switching refers to the process of automatically or manually redirecting business traffic to the standby database when the primary database fails or becomes unavailable, ensuring business continuity. This is mainly used in the following scenarios:

• When a cloud vendor experiences a failure:

  If the primary database's cloud vendor experiences a major failure (such as a data center outage, network disruption, or service unavailability), the primary database cannot continue to provide services. In this case, disaster recovery switching can be used to redirect business traffic to the standby database deployed on another cloud vendor, ensuring uninterrupted business operations.

  • Fault detection: The system automatically detects a failure in the primary database's cloud vendor, or an administrator manually triggers the disaster recovery switch.
  • Switch execution: The global address is automatically updated, routing business traffic to the standby database on another cloud vendor.
  • Standby database promotion: The standby database takes over all business read and write requests, becoming the new primary database.
  • Business recovery: Applications continue to access the database through the global address without needing to modify the connection configuration, allowing for a quick recovery.

  For example, if the primary database is deployed on cloud vendor A and the standby database on cloud vendor B, a failure in cloud vendor A can immediately redirect business traffic to the standby database on cloud vendor B, ensuring business continuity.

  

• When a region experiences a failure:

  If the primary database's region (such as a region-level data center failure, natural disaster, or network partition) fails, even if other regions of the same cloud vendor are functioning normally, the primary database cannot provide services. In this case, disaster recovery switching can be used to redirect business traffic to a standby database in another region or on a different cloud vendor.

  • Impact of the failure: A failure in the primary database's region may render all services in that region, including the primary database instance, unavailable.
  • Switching strategy: If there are standby databases in other regions of the same cloud vendor, you can switch to those. If cross-cloud deployment is used, you can switch to a standby database on another cloud vendor, providing stronger disaster recovery guarantees.
  • Data consistency: Before the switch, the standby database maintains data consistency with the primary database through real-time synchronization. After the switch, data integrity is ensured.
  • Rapid recovery: Through automatic routing via the global address, business operations can be restored within minutes.

  For example, if the primary database is deployed in Region 1 of cloud vendor A and the standby database in Region 2 of cloud vendor A or cloud vendor B, a failure in Region 1 can redirect business traffic to the standby database in Region 2 or cloud vendor B, providing disaster recovery protection across regions or cloud vendors.

  

Role of global addresses in cross-cloud primary/standby database architecture

This topic describes the role of global addresses in a cross-cloud primary/standby database architecture.

A global address is a single connection address that can be used to access both the primary and standby databases. This configuration allows the system to route requests to the standby database without changing the connection address of the business application when the primary database fails. This minimizes the impact on the business application's address management and ensures high availability of the business.

A global address is a virtual network address that clients use to access the database. The system automatically routes requests to the correct database instance based on the current primary/standby status. For example:

• When the primary instance is running normally, the global address points to the primary instance.

• If the primary instance fails, you can click Disaster Recovery Switch to switch requests to the standby database without changing the connection address. The primary database also triggers a decoupling action.

Global address and disaster recovery switchover

In normal primary-standby mode, the primary database handles most of the business traffic, while the standby database synchronizes data from the primary database but does not actively process business requests. This standby database serves as a disaster recovery backup. Global addresses and disaster recovery switchover ensure high availability and disaster recovery capabilities without interrupting business operations.

Global address and switchover

This scenario describes the switchover process when the primary database fails. The standby database quickly takes over the business operations and becomes the new primary database. The customer does not need to be aware of the change. Global addresses and switchover ensure real-time data synchronization between the primary and standby databases. The standby database becomes the new primary database, ensuring continuous business operations. In the event of a single point of failure (primary database failure), the disaster recovery switchover ensures business continuity. This setup provides high availability and disaster recovery capabilities without interrupting business operations.

Global address and active decoupling

When the primary database and the synchronization link are completely failed, the standby database runs independently. The primary-standby relationship is broken, and manual intervention is required to restore the primary-standby architecture. By designing the primary-standby architecture, even if the primary database fails, the standby database can take over in a timely manner to ensure the business system does not interrupt. Normally, the primary database synchronizes data to the standby database in real time to ensure data consistency. When the primary database fails, the standby database can independently handle the main business traffic to ensure continuous business operations. By configuring a global domain name, the customer's business system does not need to perform any operations to switch addresses. The system can dynamically switch traffic to the new primary instance through domain name resolution. Log backup and archiving, along with the synchronization link, ensure data security. Even if an irreversible failure occurs in a specific environment, data can be recovered using backups.