PDB-Level Data Guard With Federated Redo Synchronization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing high availability (HA) solutions for multitenant architectures in container databases face challenges such as rigid synchronization and failover topologies, performance bottlenecks, and unpredictable replication lag, which impact reliability, availability, and serviceability, particularly in online transaction processing (OLTP) scenarios.
Innovation Solution
A federated architecture with pseudo control files (PCFs) that track the lifespans and incarnations of pluggable databases (PDBs), allowing independent HA configuration and real-time redo shipping, enabling flexible synchronization and failover at the PDB level, decoupling PDBs from CDBs, and supporting fine-grained redundancy and elasticity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a standby CDB synchronizes with a primary CDB using existing HA solutions, then synchronization is achieved, but the topology is rigid and failover is constrained
Solution Approach 1:
The patent segments the HA configuration from the CDB level to the PDB level. Each PDB can have its own standby PDB configured independently, allowing different synchronization topologies for different PDBs within the same CDB. This enables flexible one-to-one, one-to-many, or many-to-one relationships between primary and standby PDBs, resolving the rigidity of traditional CDB-level HA solutions.
2Productivity
If multiple PDBs share a single redo feed in a primary CDB, then resource amortization is achieved, but performance bottlenecks and unpredictable replication lag occur
Solution Approach 1:
The patent segments the redo feed resource at the PDB level, allowing each standby PDB to have its own dedicated redo feed from its primary PDB. This eliminates the performance bottleneck caused by multiple PDBs competing for a single shared redo feed, while still maintaining resource efficiency through the multitenant architecture. Each PDB-standby PDB pair operates independently with predictable replication lag.
3Reliability
If a standby CDB receives redo records from only one primary CDB, then role-based HA is maintained, but cascading failures and limited scalability occur
Solution Approach 1:
The patent segments the HA roles at the PDB level, allowing a single CDB to host multiple primary PDBs and multiple standby PDBs with different HA roles. A standby PDB can be configured to receive redo from a primary PDB in a different CDB, enabling cross-CDB redundancy and protecting against cascading failures. This maintains role-based HA stability while dramatically improving failure resilience and scalability.
4Reliability
If HA configuration is done at the CDB level, then system-wide redundancy is achieved, but fine-grained control and elasticity are lost
Solution Approach 1:
The patent segments the HA configuration capability to the individual PDB level, allowing administrators to configure standby PDBs independently for each primary PDB. This enables fine-grained control over which PDBs require HA, the choice of standby targets, and the synchronization parameters. The system maintains system-wide redundancy through coordinated PDB-level configurations while providing unprecedented operational flexibility and elasticity.
Data Source
AI summary
Herein is high availability for online transaction processing with redundancy and redo for a federation of pluggable databases and container databases. In an embodiment of a federation of container database management systems that includes a first container database, first redo data of a first pluggable database in a second container database is obtained based on a database dictionary in the first container database. To the first pluggable database in the first container database, the first redo data of the first pluggable database in the second container database is applied. Based on the database dictionary in the first container database, second redo data of a second pluggable database in a third container database is obtained. To the second pluggable database in the first container database, without modifying content of the first pluggable database in the first container database, the second redo data of the second pluggable database in the third container database is applied.


