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.
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.