When a DDL operation runs on the primary node, it holds a metadata lock (MDL). Read-only nodes must wait for that lock information to sync before they can resume parsing redo logs — causing DDL operations to stall. Async MDL replication decouples MDL synchronization from redo log parsing so read-only nodes continue applying redo logs while waiting for lock information, reducing the impact of DDL on cluster performance.
Supported versions
| Version | Minimum revision |
|---|---|
| PolarDB for MySQL 5.6 | All revision versions |
| PolarDB for MySQL 5.7 | All revision versions |
| PolarDB for MySQL 8.0 | 8.0.1.1.10 or later |
To check your cluster version, see Query the engine version.
How it works
Without async MDL replication, MDL synchronization and redo log parsing are coupled on read-only nodes:
| Primary node | Read-only node |
|---|---|
| Runs DDL — acquires MDL | Receives signal to sync MDL |
| DDL holds MDL | Waits for MDL sync to complete |
| Stops parsing redo logs while waiting | |
| DDL completes — releases MDL | MDL sync completes — resumes redo log parsing |
With async MDL replication, the read-only node decouples these two operations: it continues parsing and applying redo logs in the background while a dedicated worker thread handles MDL synchronization in parallel.
Monitor MDL synchronization
The feature is enabled by default on supported clusters. No configuration is required.
Two INFORMATION_SCHEMA views let you inspect MDL synchronization state on a read-only node.
Both queries require the following minimum revision versions. If your cluster does not meet these requirements, upgrade the cluster version.
MySQL 8.0.1: revision 8.0.1.1.24 or later
MySQL 5.7: revision 5.7.1.0.20 or later
MySQL 5.6: revision 5.6.1.0.33 or later To run a query on a specific node, see the "Hint" section of Overview.
Query MDL slot state
Run the following statement on a read-only node to view all active MDL synchronization slots:
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOG_MDL_SLOT;Example output:
+---------+------------+-------------------+----------+-------------------+
| slot_id | slot_state | slot_name | slot_lsn | thread_id |
+---------+------------+-------------------+----------+-------------------+
| 0 | SLOT_NONE | no targeted table | 0 | no running thread |
| 1 | SLOT_NONE | no targeted table | 0 | no running thread |
| 2 | SLOT_NONE | no targeted table | 0 | no running thread |
| 3 | SLOT_NONE | no targeted table | 0 | no running thread |
| 4 | SLOT_NONE | no targeted table | 0 | no running thread |
+---------+------------+-------------------+----------+-------------------+Each row represents one MDL synchronization slot. The slot_name column identifies the target table, and slot_state shows the current synchronization phase:
slot_state | Meaning |
|---|---|
SLOT_NONE | Initialization state. No active MDL request. |
SLOT_RESERVED | The read-only node received an MDL request and is waiting for a worker thread from the scheduler. |
SLOT_ACQUIRING | A worker thread is assigned and the read-only node is sending the MDL request. If the MDL is held by another connection, the slot remains in this state until the lock is released. |
SLOT_LOCKED | The MDL has been acquired and is held by the read-only node. |
SLOT_RELEASING | The read-only node received an MDL release request and is waiting for a worker thread from the scheduler. |
Diagnosing a lock wait: A slot stuck in SLOT_ACQUIRING indicates the read-only node is likely waiting for an MDL held by another connection. Use the worker thread query below to confirm, then check whether any connection on the primary node is holding a lock on the table shown in slot_name.
Query worker thread state
Run the following statement on a read-only node to view the worker threads processing MDL synchronization requests:
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOG_MDL_THREAD;Example output:
+-----------+-----------+------------------+-------------------+----------+
| thread_id | thr_state | slot_state | slot_name | slot_lsn |
+-----------+-----------+------------------+-------------------+----------+
| 0 | free | not in acquiring | no targeted table | 0 |
| 1 | free | not in acquiring | no targeted table | 0 |
| 2 | free | not in acquiring | no targeted table | 0 |
| 3 | free | not in acquiring | no targeted table | 0 |
+-----------+-----------+------------------+-------------------+----------+If INNODB_LOG_MDL_SLOT shows a slot in SLOT_ACQUIRING and the corresponding worker thread in INNODB_LOG_MDL_THREAD has thr_state not equal to free, the read-only node is waiting for an MDL at a high probability. Check whether any connection on the primary node holds a lock on the table shown in slot_name.
Contact us
If you have questions about DDL operations, contact us.
Contact us
If you have any questions about DDL operations, please contact technical support.