PolarDB:Core advantages

Replication capabilities at a glance

Multimodal DML replication

Most traffic within a GDN carries data changes from DML operations. GDN provides several replication policies so you can tune the balance between data consistency and performance for your workload. See DML replication for policy details.

The replication engine includes two kernel-level optimizations that improve stability and reduce bandwidth consumption:

Partition-aware replication

PolarDB-X supports partitioned tables with multiple partitioning levels (partitioning and subpartitioning) and multiple partitioning methods (hash partitioning, range partitioning, and list partitioning). To effectively write data to specific partitions in a partitioned table, you must include the partition key column in the SQL statement. The GDN kernel recognizes partitioning rules and detects rule changes automatically, so data is routed to the correct partitions on secondary clusters without manual intervention.

TTL-aware replication

PolarDB-X supports time to live (TTL) tables, which automatically delete expired rows. In a standard replication setup, those delete operations generate a large volume of delete events in the global binlog — events that, if replicated across regions, consume significant network bandwidth and increase replication latency. PolarDB-X labels TTL-triggered delete events and excludes them from replication links. Each secondary cluster's TTL scheduler runs its own expiry independently, so bandwidth is preserved without any data inconsistency.

Global DDL synchronization

PolarDB-X is a distributed database service compatible with the MySQL ecosystem, but its DDL capabilities extend well beyond standard MySQL. DDL synchronization extracts DDL statements from the primary cluster's binlogs and applies them to secondary clusters. The built-in replication engine addresses the compatibility, consistency, stability, and availability challenges involved.

PolarDB-X extends MySQL DDL with distributed-database constructs, including global secondary indexes (GSI), clustered columnar indexes (CCI), local partitioning, locality assignments, and partition moves. Examples:

-- Create a global secondary index (GSI)
CREATE GLOBAL INDEX g_i_pk_type ON gsi_primary_table (id) COVERING (c_tinyint_1)
DBPARTITION BY HASH(id) TBPARTITION BY HASH(id) TBPARTITIONS 3;

-- Modify a GSI
ALTER INDEX gsi_lc ON TABLE t1
ADD PARTITION (PARTITION p2 VALUES IN ((11, 11), (10, 10)));

-- Add a Clustered Columnar Index (CCI) to a table
ALTER TABLE t_order ADD CLUSTERED COLUMNAR INDEX `g_i_buyer` (`buyer_id`)
partition by hash(`buyer_id`) partitions 16 COMMENT 'CREATE CCI TEST';

-- Create a table with composite partitioning, auto-expire old partitions, and pre-allocate future partitions
CREATE TABLE t1 (
    c1 bigint,
    c2 bigint,
    c3 bigint,
    gmt_modified DATETIME PRIMARY KEY NOT NULL
) PARTITION BY HASH(c1) PARTITIONS 4 LOCAL PARTITION BY RANGE (gmt_modified)
INTERVAL 1 MONTH EXPIRE AFTER 12 PRE ALLOCATE 6 PIVOTDATE NOW();

-- Specify the data node for each partition
CREATE TABLE l0 (
  x int PRIMARY KEY AUTO_INCREMENT,
  y int,
  INDEX `auto_shard_key_y` USING BTREE(`Y`)
) DEFAULT CHARSET = `utf8mb4` DEFAULT COLLATE = `utf8mb4_general_ci`
PARTITION BY LIST COLUMNS (y) (
  PARTITION p1 VALUES IN (0, 1, 2, 3) LOCALITY 'dn=xdevelop-240613031956-9e47-629h-dn-1',
  PARTITION p2 VALUES IN (4, 5, 6, 7) LOCALITY 'dn=xdevelop-240613031956-9e47-629h-dn-0',
  PARTITION p3 VALUES IN (10, 20, 30, 40) LOCALITY 'dn=xdevelop-240613031956-9e47-629h-dn-1'
);

-- Move partitions to a different data node
ALTER TABLE special_dml_test1
  MOVE PARTITIONS (p2, p4, p6, p8) TO 'xdevelop-240613031956-9e47-629h-dn-0';

See DDL replication for full details.

High compatibility

The native kernel-level replication engine eliminates SQL compatibility issues across different products and versions. Because the engine operates inside PolarDB-X, it carries extra metadata alongside DDL statements, allowing it to dynamically adjust DML generation rules, strip or remap data locality information for secondary cluster data nodes (DNs), and rewrite DDL statements for column-store data — without any manual configuration.

Asynchronous DDL execution

DDL operations on large distributed tables can take a long time to complete, blocking replication and increasing latency. For operations that support it — including ANALYZING TABLE, ALTER TABLE ADD INDEX, and ALTER TABLE CHANGE PARTITION — the replication engine processes them asynchronously at the kernel layer and coordinates two-phase DDL execution between the primary and secondary instances. Replication continues without prolonged blocking.

Consistent multi-stream DDL replication

GDN replication links are built on multi-stream binlogs, which means a DDL statement must be coordinated across multiple streams before it is applied. The built-in distributed DDL consistency engine ensures that a DDL statement is applied to the secondary instance only after all replication links have received the same statement. No additional operational overhead is required.

Lightweight bidirectional replication

GDN supports MySQL-compatible lightweight bidirectional replication between primary and secondary instances. Loopback traffic is filtered by server_id in the binlog event header — avoiding the performance overhead and scalability constraints of transaction-table-based filtering.

One-way primary-secondary synchronization is available directly in the PolarDB-X console. For two-way synchronization, submit a ticket.

Efficient data reconciliation

GDN includes a built-in data reconciliation capability. See Verify data in the primary and secondary instances for step-by-step instructions.

Multiple data consistency check modes

High-performance verification process

The reconciliation process combines fast checksum verification with targeted row-by-row comparison. A sampling algorithm divides data into intervals and computes checksums per interval. When checksums match, the interval is verified. When they don't, the process switches to row-by-row comparison for that interval only. This delivers a tenfold performance improvement over full row-by-row comparison and significantly reduces resource consumption.

Integrated O&M

GDN abstracts the complexity of cross-cluster data replication at the kernel level. From the PolarDB-X console, you can:

• Create a GDN

• Configure primary-secondary synchronization

• Remove secondary instances

• Perform a primary-secondary switchover

See Operations for a full guide to GDN management.