The Physical Standby Database solution is an important part of the high availability capability of OceanBase Database. It ensures the high availability, data protection, and disaster recovery for your key applications.
The Physical Standby Database solution provides a quasi-real-time hot backup for the production database of OceanBase Database. Upon scheduled switchover or when the primary database cannot provide services due to a failure, a physical standby database can be switched to be the primary database to provide external services. This reduces the service unavailability time and possible data loss.
You can use the Physical Standby Database solution together with other features of OceanBase Database, such as multi-replica disaster recovery, arbitration-based disaster recovery, physical backup and restore, and Change Data Capture (CDC), to meet your various data protection and availability requirements.
You can also use the Physical Standby Database solution to perform tasks that may consume a large amount of resources, such as backup and restore, CDC, and analytical processing (AP) queries. This can reduce the load of the primary database and improve the overall availability and stability of database services.
Configuration
OceanBase Database supports multiple tenants in a single cluster and implements resource isolation by using tenants. This way, each database instance is isolated and remains invisible to other instances. OceanBase Database uses privilege control to ensure data security for all tenants. For more information about the multitenancy feature of OceanBase Database, see Overview.
OceanBase Database V4.1.0 and later provide the Physical Standby Database solution at the tenant level. That is, the primary or standby role is assigned to a tenant but not a cluster. In this document, a primary database is equivalent to a primary tenant, and a standby database is equivalent to a standby tenant, unless otherwise specified.
One Physical Standby Database solution contains one primary tenant and one or more standby tenants. The primary tenant provides read and write services for your business. The standby tenant synchronizes business data written in the primary tenant from redo logs in real time.
You can deploy a primary tenant and its standby tenants in different OceanBase clusters that are close to each other or far apart, or in the same OceanBase cluster. In other words, an OceanBase cluster can contain only primary tenants or standby tenants, or both. Tenant names, resource specifications, configurations, and locality of primary and standby tenants can be different.
Primary and standby tenants can be single-replica tenants, multi-replica tenants, or tenants with arbitration-based high availability. Different deployment modes provide different levels of replica-based disaster recovery for tenants.
Core components
The following figure shows the core components of the Physical Standby Database solution in a scenario with only one primary tenant and one standby tenant.
Log transport service
The Physical Standby Database solution synchronizes redo logs between primary and standby tenants in real time by using the log transport service. The primary tenant does not push logs to the standby tenant. Instead, the standby tenant pulls logs from the primary tenant.
The log transport service automatically addresses log locations and handles high availability issues such as log lagging and node failures in the cluster where the primary tenant resides. The standby tenant can obtain logs by using the log archiving service of the primary tenant or directly connect to the cluster where the primary tenant resides to obtain logs.
Log storage service
The log storage service provides highly available and reliable log storage and read/write capabilities. The log storage service can have a single replica or multiple replicas that achieve high availability based on the Paxos protocol.
The log storage service works in different modes for primary and standby tenants. In the primary tenant, the log storage service works in
APPENDmode to receive data written by transactions, DDL operations, and other upper-layer modules. In the standby tenant, the log storage service works inRAW WRITEmode that allows the writing of only logs obtained by the log transport service from other tenants or archive logs.Log replay service
The logs written to the log storage service in the standby tenant are applied by the log replay service to the MemStore in real time or with a delay, to ensure data consistency between primary and standby tenants.
Role transitions
The Physical Standby Database solution provides two role transition methods.
Switchover
Switchover is a lossless transition between primary and standby tenants. It is usually performed based on business plans and ensures a recovery point objective (RPO) of 0 and a recovery time objective (RTO) of several seconds. During a switchover, the primary tenant is converted into a standby tenant and a specified standby tenant is converted into the primary tenant.
Failover
Failover is performed when the primary tenant fails or cannot provide services due to other reasons. You can select a standby tenant for a failover. After the failover is completed, the standby tenant is converted into the primary tenant. Failover is a lossy operation. When logs are properly synchronized without significant lagging, it ensures an RPO of several seconds (depending on the lagging status of the standby tenant) and an RTO of several seconds.
Synchronization mode
In OceanBase Database V4.x, the Physical Standby Database solution provides only the asynchronous mode for synchronization.
Related solutions
OceanBase Database provides a variety of disaster recovery solutions to meet your business needs in different scenarios. You can use the Physical Standby Database solution with other solutions.
Multi-replica disaster recovery
OceanBase Database supports multi-replica disaster recovery based on the Paxos protocol. This solution provides high availability with an RPO of 0 and an RTO of less than 8s when a minority of replicas fail.
This solution cannot provide external services when the majority of replicas or all replicas fail. Due to the characteristics of the Paxos protocol, the logs must be synchronized across regions if your business requires geo-disaster recovery. This leads to a large delay in transaction execution.
The Physical Standby Database solution ensures business availability when the majority of replicas or all replicas of the primary cluster fail, and therefore is an important supplement to this solution.
Arbitration-based disaster recovery
Arbitration-based disaster recovery is an innovative high availability solution provided by OceanBase Database on the basis of Paxos-based multi-replica disaster recovery.
At the business layer, this solution ensures strong synchronization of data among the majority of replicas (when four full-featured replicas and one arbitration service are deployed) or all replicas (when two full-featured replicas and one arbitration service are deployed). If half of the full-featured replicas fail, this solution automatically performs a downgrade to avoid data loss while ensuring business continuity.
Unlike the maximum protection or maximum availability solution for a conventional database, this solution achieves a balance between business continuity and data integrity, thus avoiding the risk of split-brain. Based on your locality configurations, this solution can provide read and write services on multiple database nodes where full-featured replicas reside.
Similar to majority-based disaster recovery, arbitration-based disaster recovery is an intra-cluster solution that cannot ensure data protection or availability when the majority of replicas or all replicas fail. In addition, the delay caused by the strong synchronization of logs between replicas must be considered.
For more information about the arbitration service, see Arbitration-based high availability solution.
CDC
Change Data Capture (CDC) is a solution that captures and records data changes in the database. When data is inserted, updated, or deleted in your database, CDC captures and records the changes based on their sequence. This way, other systems can promptly process and use the latest data in your database.
CDC can convert all database modification operations in an OceanBase cluster into DML or DDL operations at the transaction granularity so that the operations can be repeated in another cluster. Therefore, you can build a logical standby database based on CDC.
Such a logical standby database consumes a lot of resources, and its execution efficiency is lower than that of a physical standby database built based on synchronization of redo logs. Therefore, we recommend that you use the Physical Standby Database solution in OceanBase Database.
For more information about CDC, see Overview.