Tous les produits
Search
Centre de documentation

PolarDB:Optimisation MDL (verrou de métadonnées)

Dernière mise à jour :Aug 11, 2026

Un verrou de métadonnées (MDL) est un verrou interne de la base de données qui garantit la cohérence des métadonnées de table lors des opérations de langage de définition de données (DDL). Les transactions standard de lecture/écriture doivent acquérir un verrou de lecture MDL sur la table cible, tandis que les opérations DDL nécessitent un verrou d'écriture MDL. Lors de l'exécution d'instructions DDL, prenez en compte les problématiques suivantes liées aux verrous de métadonnées :

  • Blocage

    Une transaction longue détenant un verrou de lecture MDL peut bloquer une opération DDL et provoquer son échec si l'attente pour obtenir un verrou d'écriture MDL est trop longue. De plus, MySQL utilisant un mécanisme de verrouillage équitable pour les MDL, une instruction DDL bloquée entraîne également le blocage de toutes les nouvelles transactions en attente d'un verrou de lecture MDL.

  • Risque d'interblocage

    L'exécution simultanée de plusieurs instructions DDL et transactions peut entraîner des demandes de MDL dans des ordres différents et provoquer un interblocage.

  • Exclusivité

    Le verrou d'écriture MDL est exclusif. Lorsqu'une opération DDL acquiert ce verrou, toutes les transactions entrantes sont bloquées car elles ne peuvent pas obtenir de verrou de lecture MDL. Cela peut entraîner une chute du trafic à zéro. Bien que MySQL prenne en charge le DDL en ligne, ces opérations doivent tout de même acquérir brièvement un verrou d'écriture MDL lors des phases critiques, sans pouvoir éviter totalement le verrouillage de la table.

Si ces problèmes surviennent pendant l'exécution d'un DDL, ils peuvent générer un grand nombre de connexions métier bloquées et, dans les cas graves, provoquer une interruption temporaire du trafic. PolarDB-X intègre des optimisations ciblées pour résoudre ces problèmes de verrous de métadonnées et éliminer ces risques.

Optimisation MDL préemptible

PolarDB-X prend en charge l'optimisation MDL préemptible. Cette fonctionnalité supprime le risque de blocage lié aux verrous de métadonnées lors de l'exécution des DDL.

Versions prises en charge

Cette fonctionnalité est disponible dans PolarDB-X version 5.4.17-16952556 et ultérieures.

Fonctionnement

Lorsque vous exécutez une instruction DDL nécessitant un verrou d'écriture MDL et que le temps d'attente pour obtenir ce verrou est trop long, PolarDB-X met automatiquement fin à la connexion de la transaction longue qui bloque le DDL.

Le tableau suivant illustre un scénario où une instruction DDL et une nouvelle transaction sont bloquées par une transaction longue, en l'absence de cette optimisation.

Tableau 1

Étape

Session 1

Session 2

Session 3

1

begin;

-

begin;

2

insert into tb0 values(1);

-- Acquisition d'un verrou de lecture MDL sur tb0.

-

-

3

-- La transaction n'est pas validée afin de simuler une transaction longue.

-

-

4

-

alter table tb0 add column col int;

-- Tentative d'acquisition d'un verrou d'écriture MDL sur tb0, bloquée par la transaction longue.

-

5

-

-

select id from tb0;

-- Tentative d'acquisition d'un verrou de lecture MDL sur tb0, bloquée.

La sortie suivante présente le processus d'exécution avec l'optimisation MDL préemptible activée. Les étapes correspondent à celles du Tableau 1.

-- session1
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into tb0 values(1);
Query OK, 1 row affected (0.16 sec)
mysql> select version();
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    46
-- session2
mysql> alter table tb0 add column col int;
Query OK, 0 rows affected (29.17 sec)
-- session3
mysql> select id from tb0;
Empty set (1.04 sec)

Comme le montre cette sortie, l'optimisation MDL préemptible met fin à la connexion de la transaction longue dans la Session 1. L'instruction DDL de la Session 2 s'exécute ainsi avec succès, tandis que la nouvelle transaction de la Session 3 fonctionne normalement.

Détection distribuée des interblocages de métadonnées

PolarDB-X prend en charge la détection distribuée des interblocages de métadonnées. Cette fonctionnalité détecte et résout les interblocages impliquant des verrous de métadonnées lors de l'exécution des DDL, permettant ainsi la poursuite des opérations DDL et des autres transactions.

Versions prises en charge

Cette fonctionnalité est disponible dans PolarDB-X version 5.4.17-16952556 et ultérieures.

Fonctionnement

PolarDB-X analyse périodiquement les relations d'attente de verrous entre les transactions et les instructions DDL. En cas de détection d'un interblocage, PolarDB-X interrompt automatiquement l'une des transactions en conflit afin de permettre la poursuite du DDL et des autres transactions.

Le tableau ci-dessous présente un scénario typique d'interblocage impliquant des verrous de métadonnées.

Tableau 2

Étape

Session 1

Session 2

Session 3

Session 4

1

begin;

-- Début de la transaction 1.

begin;

-- Début de la transaction 2.

-

-

2

insert into t1 values(1);

-- Acquisition d'un verrou de lecture MDL sur t1.

insert into t2 values(1);

-- Acquisition d'un verrou de lecture MDL sur t2.

-

-

3

-

-

alter table t1 add column col int;

-- Début du DDL 1, tentative d'acquisition d'un verrou d'écriture MDL sur t1, bloquée.

alter table t2 add column col int;

-- Début du DDL 2, tentative d'acquisition d'un verrou d'écriture MDL sur t2, bloquée.

4

insert into t2 values(2);

-- Tentative d'acquisition d'un verrou de lecture MDL sur t2, bloquée par le DDL 2 en raison du mécanisme de verrouillage équitable.

insert into t1 values(2);

-- Tentative d'acquisition d'un verrou de lecture MDL sur t1, bloquée par le DDL 1 en raison du mécanisme de verrouillage équitable.

-

-

La sortie suivante montre comment PolarDB-X résout l'interblocage du Tableau 2 grâce à la détection distribuée des interblocages de métadonnées. Les étapes d'exécution sont identiques à celles du tableau.

-- Session 1
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values(1);
Query OK, 1 row affected (0.12 sec)
mysql> insert into t2 values(2);
Query OK, 1 row affected (0.02 sec)
mysql> commit;
Query OK, 0 rows affected (0.99 sec)

-- Session 2
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t2 values(1);
Query OK, 1 row affected (0.08 sec)
mysql> insert into t1 values(2); -- An MDL deadlock is detected. The connection is killed and the transaction is rolled back.
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    14
Current database: d0

-- Session 3
mysql> alter table t1 add column col int;
Query OK, 0 rows affected (2 min 38.30 sec)

-- Session 4
mysql> alter table t2 add column col int;
Query OK, 0 rows affected (2 min 59.85 sec)

Une fois le scénario d'interblocage du Tableau 2 créé, PolarDB-X détecte l'interblocage et choisit d'interrompre la transaction 2. Cette annulation permet à la transaction 1, au DDL 1 et au DDL 2 de se terminer correctement.

Optimisation MDL à double version

Pour les DDL exécutés logiquement, PolarDB-X prend en charge les métadonnées à double version ainsi que les verrous de métadonnées correspondants. Ces opérations DDL peuvent ainsi s'exécuter sans jamais verrouiller les tables ni provoquer de chute du trafic à zéro.

Limites

Cette optimisation s'applique à toutes les instructions DDL exécutées logiquement dans PolarDB-X. Pour déterminer si une instruction DDL est exécutée logiquement, consultez Online DDL.

Fonctionnement

PolarDB-X implémente le DDL logique selon le principe du changement de schéma en ligne. Il divise la version des métadonnées d'une opération DDL logique en plusieurs versions mineures, permettant ainsi une évolution sécurisée des métadonnées au sein de l'instance PolarDB-X. Par exemple, une instruction CREATE GLOBAL INDEX DDL dans PolarDB-X implique plusieurs transitions de version : ABSENT(Vn), DELETE_ONLY(Vn+1), WRITE_ONLY(Vn+2) et PUBLISH(Vn+3). De plus, PolarDB-X associe un verrou de métadonnées distinct à chacune de ces versions mineures.

Grâce au mécanisme de changement de schéma en ligne, deux versions de métadonnées peuvent coexister, non seulement entre différents nœuds de calcul du cluster, mais aussi au sein d'un même nœud. Ainsi, lorsqu'une opération DDL logique entame l'évolution de la version des métadonnées, PolarDB-X acquiert uniquement le verrou d'écriture MDL correspondant à l'ancienne version lors de chaque transition. Les nouvelles transactions peuvent alors accéder à la nouvelle version des métadonnées et acquérir le verrou de lecture MDL associé.

Avec l'optimisation MDL à double version, les opérations DDL logiques dans PolarDB-X s'exécutent sans jamais verrouiller les tables ni interrompre le trafic.