GBase 8c Distributed Database Core Technology Unveiled: CDC Data Synchronization
As a critical component of enterprise IT infrastructure, a database system's stability and availability form the essential foundation for upper-layer application operations. With the acceleration of digital transformation, numerous core business systems are imposing higher demands for city-level disaster recovery. As a distributed database, GBase 8c can easily implement cross-region disaster recovery architectures such as the Two-City-Three-Center topology. In a GBase 8c cross-region disaster recovery cluster, different nodes employ their respective high-availability deployment methods, with synchronous or asynchronous replication between the two sites. This design provides resilience against hardware-level failures, data center-level incidents, and city-wide disasters, with the distance between sites capable of exceeding 1,000 kilometers.
Beyond disaster recovery, GBase 8c also supports multi-cluster deployment with bidirectional data synchronization between clusters, enabling an active-active multi-site architecture to meet the demands of business scenarios requiring stringent high availability. The key to GBase 8c's active-active multi-site capability lies in its data synchronization mechanism, and CDC is the core technology that powers this mechanism.
The following section details the architecture and implementation principles of CDC technology in the GBase 8c database.
How CDC Technology Works
CDC (Change Data Capture) in GBase 8c is a mechanism that captures all table-level data changes by parsing GBase 8c's WAL incremental logs and converts them into a format that can be replicated to homogeneous or heterogeneous systems.
As a multi-model, multi-form distributed database, GBase 8c's CDC implementation mechanisms and execution processes can be categorized into two main types: primary-standby and distributed.
Primary-Standby Mode
The publish/subscribe feature based on logical replication is the core mechanism of CDC technology. In GBase 8c's primary-standby architecture, the main execution flow for data synchronization using publish/subscribe is as follows:
Primary-Standby CDC Execution Flow Diagram
A local GBase 8c instance can specify a single table, or all tables within a database, as the publication source for logical replication. The remote GBase 8c acts as the subscription target for logical replication, connecting to the local GBase 8c's service port. The local GBase 8c starts a WalSender thread to read and decode WAL logs, outputting messages in a specific format. These messages are sent to the ApplyWorker thread on the remote GBase 8c. The ApplyWorker thread recognizes these formatted messages and directly executes the corresponding INSERT, UPDATE, DELETE, or other statements to replay the data. The local primary server uses a Replication Slot mechanism to store consumer offsets and track subscriber progress.
Distributed Mode
Unlike the primary-standby architecture, in a distributed architecture, DNs (Data Nodes) are distributed across multiple servers. A transaction in the local cluster may involve DN nodes on several servers. Therefore, when the remote cluster performs data synchronization and replay, there are two different execution methods depending on the transaction processing strategy.
1. Shard-Based Distributed Subscription Process
The first method is shard-based distributed subscription. The core mechanism is the same as the primary-standby mode, also relying on logical replication. The difference is that when the remote cluster subscribes, it creates multiple subscription tasks based on the local GBase 8c's DNs, connecting to each DN node respectively. In this scenario, the CN on the remote cluster starts multiple ApplyWorker threads, with each thread replicating the logical logs from one DN node. Each DN in the local cluster starts a WalSender thread to read, decode, and output formatted messages from its own WAL logs, sending them to the remote GBase 8c's ApplyWorker threads for data replay.
Shard-Based Distributed Subscription Process Diagram
While this synchronization method achieves high efficiency through parallel synchronization with parallelism equal to the number of DN nodes, it lacks an effective mechanism to guarantee the global ordering of distributed transactions from the local cluster when replaying on the remote cluster. Consequently, it cannot guarantee the atomicity and global transaction consistency of replayed transactions, ensuring only eventual data consistency.
2. CDC Publish/Subscribe Execution Process
To address the global transaction consistency issue inherent in shard-based distributed subscriptions, GBase 8c introduces a CDC node in the second synchronization method for distributed architecture scenarios. This node merges and sorts distributed transactions from all DNs, ensuring that transactions are replayed in a globally ordered manner on the remote cluster. This achieves strong data consistency and guarantees the atomicity of distributed transactions.
The overall architecture of the CDC node is as follows:
CDC Architecture Diagram
The CDC node adopts a stateless design similar to the CN, storing only the metadata information of the local cluster. If a CDC node crashes unexpectedly, restarting the instance or switching to a standby node allows it to continue service. Functionally, the CDC node is composed of three primary roles:
1. Dumper
The Dumper fetches logically decoded WAL incremental logs from DNs via logical replication and outputs the transaction information to the Joiner for sorting and merging.
2. Joiner
The Joiner receives transaction information from each Dumper. It merges transactions sharing the same CSN (Commit Sequence Number) and then sorts them by CSN order to construct complete global transactions for output to the Output thread.
3. Output
The Output thread sends the complete transaction stream to the remote cluster. Supported output formats include JSON, SQL, and internaloutput (similar to the pgoutput format). When the remote cluster is a GBase 8c database, using the internaloutput format yields the best replay performance.
The specific publish/subscribe process for this CDC synchronization mechanism is detailed below:
CDC Execution Flow Diagram
In this setup, the remote GBase 8c cluster connects to the CDC node of the local GBase 8c cluster to create subscription tasks. The CDC node on the local cluster starts multiple Dumper threads, which begin receiving logically decoded incremental log outputs from multiple WalSender threads. Subsequently, the Joiner thread within the CDC performs transaction merging and sorting operations on these incremental log messages, constructing complete and ordered global transaction information. Finally, the Output thread transmits this information externally. The CN node on the remote cluster starts an ApplyWorker thread to parse and replay the logical logs from the formatted information sent by the Output thread, completing the data synchronization. This synchronization method guarantees global ordering of transaction replay on the remote cluster, achieving strong data consistency.
About GBase 8c
GBase 8c is a multi-model, multi-form distributed database built on openGauss 3.0. It supports multiple storage modes—including row-based, column-based, and in-memory—as well as various deployment forms such as standalone, primary-standby, and distributed. GBase 8c delivers high performance, high availability, elastic scalability, and robust security. It can be deployed on physical machines, virtual machines, containers, private clouds, and public clouds, providing secure, stable, and reliable data storage and management services for core systems in key industries, internet businesses, and government/enterprise applications.