This FAQ covers common questions about the PolarDB-X binary logging feature, including availability, DDL behavior, log generation mode, performance metrics, and DDL compatibility isolation.
How is high availability ensured for binary logging?
The PolarDB-X Change Data Capture (CDC) cluster runs on multiple nodes. When a node goes down, PolarDB-X automatically shifts the logging process to a healthy node. The recovery time objective (RTO) is 30 seconds or less.
Does scaling data nodes interrupt binary logging?
Yes. Scaling data nodes triggers a restart of the binary logging feature. The RTO is 20 seconds or less.
Does binary logging pause when DDL statements run?
No. Binary logging continues uninterrupted while DDL statements execute. You can perform DDL operations online without blocking the logging process.
Are global binary logs generated synchronously or asynchronously?
Global binary logs are generated asynchronously. The process works as follows:
After a transaction commits, physical binary logs are written to the data node synchronously.
CDC reads those physical binary logs and generates global binary logs asynchronously.
What performance metrics does binary logging expose?
Binary logging reports two metrics: data latency and data throughput. For benchmark figures, see CDC node test.
How does PolarDB-X handle DDL compatibility when both MySQL and PolarDB-X are used as secondary databases?
PolarDB-X uses custom DDL syntax that MySQL does not support. To serve both downstream types from a single log stream, the log engine uses a dual-encoding approach:
DDL with custom syntax — recorded as single-line comments in the binary log
DDL without custom syntax — recorded in normal mode
The downstream behavior differs by database type:
| Downstream | Binary log handling |
|---|---|
| MySQL | Consumed directly |
| PolarDB-X | Must be preprocessed to extract and apply the custom-syntax DDL from the comments |
