All Products
Search
Document Center

PolarDB:DDL replication

Last Updated:Apr 01, 2026

DDL replication keeps schemas in sync across all clusters in a Global Database Network (GDN). Without it, schema drift between the primary and secondary clusters can cause data errors or serious performance degradation when a secondary cluster takes over traffic during a failover — even a missing index is enough to degrade query performance.

DML replication handles row-level data consistency. DDL replication goes further: it synchronizes all database objects, including tables, indexes, views, sequences, stored procedures, roles, and PolarDB-X-specific constructs such as table groups and global secondary indexes (GSIs).

Supported DDL types

The following DDL statements are not replicated and must be applied separately to each cluster: CCI-related statements (CREATE COLUMNAR INDEX, DROP COLUMNAR INDEX, ALTER COLUMNAR INDEX), SET GLOBAL, and SQL throttling rules. For details, see the Remarks column.
Type DDL statement Replicated Remarks
DATABASE CREATE DATABASE Yes See Database statements.
DROP DATABASE Yes
ALTER DATABASE No ALTER DATABASE does not support modifying character sets and is excluded from replication. Apply the statement separately on each cluster.
MOVE DATABASE No Apply separately on each cluster.
TABLE CREATE TABLE Yes See Table statements.
ALTER TABLE Yes
DROP TABLE Yes
TRUNCATE TABLE Yes
RENAME TABLE Yes
ANALYZE TABLE Yes
PARTITION SPLIT PARTITION Yes See Partition statements. Partition migration is not supported. See Limitations.
SPLIT INTO BY HOT VALUE Yes
MERGE PARTITIONS Yes
MOVE PARTITIONS No DN node association is not replicated. See Limitations.
RENAME PARTITION Yes
ADD PARTITION Yes
DROP PARTITION Yes
MODIFY PARTITION Yes
REORGANIZE PARTITION Yes
TRUNCATE PARTITION Yes
TABLEGROUP CREATE TABLEGROUP Yes See Table group statements.
DROP TABLEGROUP Yes
ALTER TABLEGROUP Yes
MERGE TABLEGROUP Yes
ALTER TABLEGROUP ADD TABLE Yes
ALTER TABLE SET TABLEGROUP Yes
JOINGROUP CREATE JOINGROUP Yes
ALTER JOINGROUP Yes
DROP JOINGROUP Yes
INDEX CREATE INDEX Yes See Indexes.
DROP INDEX Yes
ALTER INDEX Yes
ALTER INDEX VISIBILITY Yes
SEQUENCE CREATE SEQUENCE Yes See Sequences.
DROP SEQUENCE Yes
ALTER SEQUENCE Yes
RENAME SEQUENCE Yes
CONVERT ALL SEQUENCES Yes
FUNCTION CREATE FUNCTION Yes See Custom functions.
DROP FUNCTION Yes
ALTER FUNCTION Yes
CREATE JAVA FUNCTION Yes
ALTER JAVA FUNCTION Yes
DROP JAVA FUNCTION Yes
PROCEDURE CREATE PROCEDURE Yes See Stored procedures.
ALTER PROCEDURE Yes
DROP PROCEDURE Yes
VIEW CREATE VIEW Yes See Views.
DROP VIEW Yes
ALTER VIEW Yes
CREATE MATERIALIZED VIEW Yes
DROP MATERIALIZED VIEW Yes
USER CREATE USER Yes See Manage accounts and permissions.
DROP USER Yes
SET PASSWORD Yes
GRANT PRIVILEGE TO USER Yes
REVOKE PRIVILEGE FROM USER Yes
ROLE CREATE ROLE Yes See Manage roles and permissions.
DROP ROLE Yes
GRANT PRIVILEGE TO ROLE Yes
GRANT ROLE TO USER Yes
SET DEFAULT ROLE Yes
REVOKE PRIVILEGE FROM ROLE Yes
REVOKE ROLE FROM USER Yes
SET SET GLOBAL ... No PolarDB-X follows native MySQL behavior: global variable changes are not synchronized when a primary/secondary replication link is established. Apply separately on each cluster.
SQL throttling All throttling rules No SQL throttling is temporary. Throttling rules cannot be copied to secondary clusters via GDN. Apply separately on each cluster.

Table groups

PolarDB-X supports two types of table groups: explicit and implicit.

Explicit table groups are managed directly with DDL statements:

  • Create: CREATE TABLEGROUP

  • Delete: DROP TABLEGROUP

  • Modify: ALTER TABLEGROUP

For more information, see Table groups.

Implicit table groups are created automatically by PolarDB-X when you create, drop, or repartition a table. They are named sequentially (tg1, tg2, tg3, ...), but the sequence numbers are non-deterministic — parallel table creation produces random assignments, and rolled-back DDL tasks cause sequence numbers to be skipped.

This non-determinism creates a replication challenge: if the primary and secondary clusters independently generate implicit table groups, the same table may be assigned different table group names across clusters. To solve this, PolarDB-X extends DDL statements with explicit table group bindings before writing them to the binary log. Secondary clusters replay the extended statements and use the same table group names as the primary cluster.

Example: `CREATE TABLE`

Original statement submitted on the primary cluster:

CREATE TABLE IF NOT EXISTS tb1 (
  a int PRIMARY KEY,
  b int,
  c int,
  d varchar(10) UNIQUE,
  INDEX b(b),
  INDEX b_2(b),
  KEY b_3 (b),
  KEY b_4 (b),
  UNIQUE KEY b_5 (b),
  UNIQUE KEY b_6 (b),
  UNIQUE INDEX b_7 (b),
  UNIQUE INDEX b_8 (b),
  INDEX g1(b),
  KEY g2 (b),
  UNIQUE KEY g3 (b),
  UNIQUE INDEX g4 (b)
) DEFAULT CHARACTER SET = utf8mb4 DEFAULT COLLATE = utf8mb4_general_ci;

Example: `ALTER TABLE ... MERGE PARTITIONS`

Original statement submitted on the primary cluster:

ALTER TABLE tb1 MERGE PARTITIONS p1, p2 TO p12;

Extended statement recorded in the binary log:

ALTER TABLE tb1 MERGE PARTITIONS p1, p2 TO p12 WITH TABLEGROUP=tg29 IMPLICIT;

The WITH TABLEGROUP=tg29 IMPLICIT clause pins the implicit table group name so secondary clusters use the same name instead of generating their own.

Multi-stream replication

In single-stream replication, DDL statements are replicated one at a time, strictly following binary log order.

Multi-stream replication runs multiple replication links in parallel to increase throughput. This introduces a coordination problem for DDL: if one stream applies a DDL statement immediately upon receiving it, the schema becomes temporarily inconsistent with the other streams that haven't received it yet. Any DML arriving on those streams would run against the wrong schema, causing data errors or exceptions.

To prevent this, PolarDB-X includes a distributed DDL replication engine. After a DDL statement arrives on any stream, all streams pause and wait until every stream has received the statement. Only then does each stream apply the DDL and resume DML processing. This coordination is handled by an efficient multi-link coordination algorithm built into the engine.

Multi-stream DDL replication coordination

Limitations

Locality and DN node assignment

PolarDB-X supports the LOCALITY attribute to pin partitions to specific data nodes (DNs) by including the DN node ID in DDL statements. However, PolarDB-X does not map DN node IDs between the primary and secondary clusters. When a DDL statement containing DN node information is replicated, the DN-specific clauses are stripped before the statement is applied on secondary clusters.

The following table describes what happens in each scenario.

Operation on primary cluster Result on secondary clusters Action required
CREATE TABLE with LOCALITY 'dn=<node-id>' on specific partitions Table is created without locality constraints; partitions are distributed by default rules Log in to each secondary cluster and manually adjust the partition distribution
ALTER TABLE ... MOVE PARTITIONS (...) TO '<node-id>' The statement is replicated as ALTER TABLE <table_name>; — no partition movement occurs Log in to each secondary cluster and manually move the partitions

Example: `CREATE TABLE` with locality

Statement executed on the primary cluster:

CREATE TABLE test_pg3 (
  id int
) DEFAULT CHARSET = utf8mb4 DEFAULT COLLATE = utf8mb4_general_ci
PARTITION BY RANGE (id) (
  PARTITION p0 VALUES LESS THAN (1000) LOCALITY 'dn=xdevelop-240524092100-31ef-bngl-dn-1',
  PARTITION p1 VALUES LESS THAN (2000) LOCALITY 'dn=xdevelop-240524092100-31ef-bngl-dn-1'
);

Statement replicated to secondary clusters (DN locality stripped):

CREATE TABLE test_pg3 (
  id int
) DEFAULT CHARACTER SET = utf8mb4 DEFAULT COLLATE = utf8mb4_general_ci
PARTITION BY RANGE (id) (
  PARTITION p0 VALUES LESS THAN (1000),
  PARTITION p1 VALUES LESS THAN (2000)
) WITH TABLEGROUP = tg3778 IMPLICIT;

Example: `MOVE PARTITIONS` to a specific DN

Statement executed on the primary cluster:

ALTER TABLE special_dml_test1
  MOVE PARTITIONS (p2, p4, p6, p8) TO 'xdevelop-240524092100-31ef-bngl-dn-0';

Statement replicated to secondary clusters (movement stripped):

ALTER TABLE special_dml_test1;

SET PARTITION_HINT

PolarDB-X supports SET PARTITION_HINT to route SQL statements to specific partitions. In GDN replication, SET PARTITION_HINT is not passed through to secondary clusters. Data written to a specific partition on the primary cluster is not guaranteed to land on the same partition on secondary clusters.