Tous les produits
Search

Ce produit

    PolarDB:Afficher l'état d'exécution des instructions DDL et l'état MDL

    Centre de documentation

    PolarDB:Afficher l'état d'exécution des instructions DDL et l'état MDL

    Dernière mise à jour :Oct 13, 2026

    PolarDB prend en charge Polar Performance Schema, qui surveille l'état d'exécution des instructions DDL et l'état MDL dans la base de données. Polar Performance Schema est une fonctionnalité de surveillance légère. Par rapport à la fonctionnalité MySQL Performance Schema, elle consomme moins de mémoire et engendre une surcharge de performance plus faible. Cette rubrique explique comment utiliser Polar Performance Schema pour afficher l'état d'exécution des instructions DDL et l'état MDL.

    Prérequis

    La version du cluster PolarDB for MySQL doit être :

    • 5,7 avec la révision 5.7.1.0.35 ou ultérieure.

    • 8.0.1 avec la révision 8.0.1.1.21 ou ultérieure.

    • 8.0.2 avec la révision 8.0.2.2.8 ou ultérieure.

    Pour savoir comment afficher la version du cluster, reportez-vous à la section Interroger le numéro de version.

    Précautions

    Les instructions DDL sont toujours exécutées sur le nœud principal du cluster. Vous devez donc interroger l'état d'exécution des instructions DDL sur le nœud principal.

    • Si vous vous connectez au cluster via le point de terminaison principal, vous pouvez interroger directement l'état d'exécution des instructions DDL sur le nœud principal. Pour afficher le point de terminaison principal, consultez la section Afficher les points de terminaison et les ports.

    • Si vous vous connectez au cluster via le point de terminaison de cluster, utilisez une indication (hint) dans l'instruction SQL pour spécifier que l'état d'exécution des instructions DDL doit être interrogé sur le nœud principal. Pour plus d'informations, consultez la section Répartition lecture/écriture.

    Une fois la fonctionnalité Performance Schema activée, la fonctionnalité Polar Performance Schema est automatiquement désactivée.

    Procédure

    Remarque

    La méthode décrite dans cette rubrique s'applique uniquement aux tables utilisant le moteur de stockage InnoDB.

    1. Activez Polar Performance Schema.

      Définissez le paramètre loose_polar_performance_schema sur ON dans la console. Ce paramètre prend effet après le redémarrage du cluster. Pour plus d'informations, consultez la section Définir les paramètres de cluster et de nœud.

      Le tableau suivant décrit les paramètres liés à Polar Performance Schema.

      Paramètre

      Description

      loose_polar_performance_schema

      Indique si Polar Performance Schema est activé. Valeurs possibles :

      • ON : active Polar Performance Schema.

      • OFF : désactive Polar Performance Schema.

      loose_polar_performance_schema_enable_row_locks

      Indique si les informations de surveillance des verrous de ligne sont activées lorsque Polar Performance Schema est activé.

      • OFF (par défaut) : désactive les informations de surveillance des verrous de ligne.

      • ON : active les informations de surveillance des verrous de ligne.

      Remarque

      Ce paramètre prend effet uniquement dans PolarDB for MySQL 8.0.1 et 8.0.2.

      performance_schema_max_thread_instances

      Nombre maximal de threads surveillés par Polar Performance Schema. Valeurs possibles : -1 à 65536. La valeur -1 indique un réglage automatique.

      Remarque

      Ce paramètre a été optimisé. Nous vous recommandons de ne pas le modifier.

      performance_schema_max_metadata_locks

      Nombre maximal de MDL surveillés par Polar Performance Schema. Valeurs possibles : -1 à 1048576. La valeur -1 indique un réglage automatique.

      Remarque

      Ce paramètre a été optimisé. Nous vous recommandons de ne pas le modifier.

      Après le démarrage du cluster, exécutez l'instruction suivante pour vérifier que Polar Performance Schema est activé.

      SHOW VARIABLES LIKE 'polar_performance_schema';

      Exemple de sortie :

      +--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| polar_performance_schema | ON    |
+--------------------------+-------+
1 row in set (0.00 sec)

    2. Affichez l'état d'exécution des instructions DDL et l'état MDL.

      • Pendant l'exécution d'une instruction DDL, exécutez l'instruction suivante pour interroger la table performance_schema.events_stages_current afin d'obtenir l'état d'exécution de l'instruction DDL actuelle :

        SELECT THREAD_ID,EVENT_ID, EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED,(WORK_COMPLETED/WORK_ESTIMATED)*100 as PROGRESS FROM performance_schema.events_stages_current;

        Exemple de sortie :

        +-----------+----------+------------------------------------------------------+----------------+----------------+----------+
| THREAD_ID | EVENT_ID | EVENT_NAME                                           | WORK_COMPLETED | WORK_ESTIMATED | PROGRESS |
+-----------+----------+------------------------------------------------------+----------------+----------------+----------+
|   3057989 |       13 | stage/innodb/alter table (read PK and internal sort) |          56634 |         330135 |  17.1548 |
+-----------+----------+------------------------------------------------------+----------------+----------------+----------+
1 row in set (0.00 sec)

        En utilisant les tables performance_schema.threads et information_schema.PROCESSLIST, exécutez l'instruction suivante pour afficher l'instruction SQL correspondant à l'événement actuel.

        SELECT esc.THREAD_ID, esc.EVENT_NAME, esc.WORK_COMPLETED, esc.WORK_ESTIMATED, pl.INFO FROM performance_schema.events_stages_current esc LEFT JOIN performance_schema.threads th ON esc.thread_id = th.thread_id LEFT JOIN information_schema.PROCESSLIST pl ON th.PROCESSLIST_ID = pl.ID;

        Exemple de sortie :

        +-----------+------------------------------------------------------+----------------+----------------+-----------------------------------------------------------------------------------------+
| THREAD_ID | EVENT_NAME                                           | WORK_COMPLETED | WORK_ESTIMATED | INFO                                                                                    |
+-----------+------------------------------------------------------+----------------+----------------+-----------------------------------------------------------------------------------------+
|   3057989 | stage/innodb/alter table (read PK and internal sort) |          77034 |         330519 | ALTER TABLE test.test ALGORITHM=INPLACE, ADD testA VARCHAR(20) NOT NULL DEFAULT 'testA' |
+-----------+------------------------------------------------------+----------------+----------------+-----------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

      • Exécutez l'instruction suivante pour interroger la table performance_schema.metadata_locks afin d'obtenir l'utilisation des MDL dans le cluster actuel :

        SELECT * FROM performance_schema.metadata_locks;

        Exemple de sortie :

        +-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+------------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME      | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE           | LOCK_DURATION | LOCK_STATUS | SOURCE                 | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+------------------------+-----------------+----------------+
| GLOBAL      | NULL               | NULL             | NULL        |       139949462878336 | INTENTION_EXCLUSIVE | STATEMENT     | GRANTED     | sql_base.cc:3103       |         3055785 |              1 |
| TABLE       | test               | test             | NULL        |       139931318980224 | SHARED_WRITE        | TRANSACTION   | GRANTED     | sql_parse.cc:6479      |         3055785 |              1 |
| COMMIT      | NULL               | NULL             | NULL        |       139931318980480 | INTENTION_EXCLUSIVE | EXPLICIT      | GRANTED     | handler.cc:1669        |         3055785 |              1 |
| TABLE       | performance_schema | metadata_locks   | NULL        |       139934227366144 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:6479      |         3057612 |              1 |
| GLOBAL      | NULL               | NULL             | NULL        |       139934216849664 | INTENTION_EXCLUSIVE | STATEMENT     | GRANTED     | sql_base.cc:5519       |         3057989 |             13 |
| SCHEMA      | test               | NULL             | NULL        |       139934216849408 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | sql_base.cc:5506       |         3057989 |             13 |
| TABLE       | test               | test             | NULL        |       139934216848640 | SHARED_UPGRADABLE   | TRANSACTION   | GRANTED     | sql_parse.cc:6479      |         3057989 |             13 |
| BACKUP LOCK | NULL               | NULL             | NULL        |       139934216849280 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | sql_base.cc:5526       |         3057989 |             13 |
| TABLESPACE  | NULL               | test/test        | NULL        |       139934216848384 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | lock.cc:815            |         3057989 |             13 |
| TABLE       | test               | #sql-17d9_2ea89a | NULL        |       139934216848896 | EXCLUSIVE           | STATEMENT     | GRANTED     | sql_table.cc:15054     |         3057989 |             13 |
| GLOBAL      | NULL               | NULL             | NULL        |       139934216850176 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | dictionary_impl.cc:416 |         3057989 |             13 |
| TABLESPACE  | NULL               | test/test        | NULL        |       139934216849920 | EXCLUSIVE           | TRANSACTION   | GRANTED     | dictionary_impl.cc:397 |         3057989 |             13 |
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+------------------------+-----------------+----------------+
12 rows in set (0.00 sec)

        Utilisez le champ OWNER_THREAD_ID pour exécuter l'instruction suivante et afficher les informations du thread détenteur du MDL dans la table performance_schema.threads.

        SELECT * FROM performance_schema.threads WHERE THREAD_ID = "OWNER_THREAD_ID in performance_schema.metadata_locks table ";

    Bonnes pratiques

    • Waiting for table metadata lock

      En pratique, une cause fréquente de blocage des DDL est l'impossibilité d'obtenir un MDL, ce qui entraîne l'état Waiting for table metadata lock. Grâce à la table metadata_lock, vous pouvez identifier rapidement la cause du blocage DDL.

      Exemple :

      Exécutez la commande show processlist pour vérifier l'état après avoir exécuté alter table t1 add column d varchar(10),algorithm = inplace. Exemple de sortie :

      /*force_node='pi-bp10k7631d6k3****'*/ SHOW PROCESSLIST;
+-----------+-----------------+-----------------------+--------------------+----------------+---------+---------------------------------+-------------------------------------------------------------+
| Id        | User            | Host                  | db                 | Command        | Time    | State                           | Info                                                        |
+-----------+-----------------+-----------------------+--------------------+----------------+---------+---------------------------------+-------------------------------------------------------------+
|        98 | event_scheduler | localhost             | NULL               | Daemon         | 1306586 | Waiting on empty queue          | NULL                                                        |
|       109 | replicator      | 11.111.XX.XX:62549    | NULL               | Polar Log Dump |       1 | Reading log from innodb         | NULL                                                        |
|       113 | replicator      | 11.111.XX.XX:62560    | NULL               | Polar Log Ack  |       1 | Receiving from client           | NULL                                                        |
|       133 | replicator      | 10.13.64.70:42712     | NULL               | Polar Log Dump |       1 | Reading log from innodb         | NULL                                                        |
|       138 | replicator      | 10.13.64.70:42723     | NULL               | Polar Log Ack  |       0 | Receiving from client           | NULL                                                        |
|       369 | aurora          | 10.111.211.209:33334  | NULL               | Sleep          |       0 |                                 | NULL                                                        |
|       370 | aurora          | 10.111.211.209:33336  | NULL               | RDS Push LSN   | 1306413 | starting                        | NULL                                                        |
|       372 | aurora          | 10.111.204.224:37010  | NULL               | Sleep          |       0 |                                 | NULL                                                        |
|       373 | aurora          | 10.111.204.224:37019  | NULL               | RDS Push LSN   | 1306413 | starting                        | NULL                                                        |
|   3064011 | root            | 127.0.0.1:59703       | NULL               | Sleep          |     716 |                                 | NULL                                                        |
|   3064013 | root            | 127.0.0.1:59710       | NULL               | Sleep          |      25 |                                 | NULL                                                        |
|   3064015 | root            | 127.0.0.1:59713       | NULL               | Sleep          |      55 |                                 | NULL                                                        |
|   3064018 | root            | 127.0.0.1:59716       | NULL               | Sleep          |       1 |                                 | NULL                                                        |
|   3067041 | zyg_root        | 172.17.XX.XX:48594    | test               | Query          |      22 | Waiting for table metadata lock | alter table t1 add column d varchar(10),algorithm = inplace |
|   3067443 | zyg_root        | 172.17.XX.XX:48602    | test               | Sleep          |      27 |                                 | NULL                                                        |
|   3069716 | aurora          | 100.104.XX.XX:33017   | information_schema | Sleep          |      30 |                                 | NULL                                                        |
|   3069859 | aurora          | 100.104.XX.XX:41872   | information_schema | Sleep          |      30 |                                 | NULL                                                        |
|   3069925 | aurora          | 10.111.204.224:20916  | NULL               | Sleep          |       2 |                                 | NULL                                                        |
|   3069932 | aurora          | 10.111.211.209:51263  | NULL               | Sleep          |       2 |                                 | NULL                                                        |
| 270526156 | zyg_root        | 172.17.28.253:46272   | test               | Query          |       0 | starting                        | /*force_node='pi-bp10k7631d6k3****'*/ show processlist      |
+-----------+-----------------+-----------------------+--------------------+----------------+---------+---------------------------------+-------------------------------------------------------------+
20 rows in set (0.00 sec)

      Vous constatez que l'instruction DDL est dans l'état Waiting for table metadata lock.

      Dans ce cas, interrogez la table performance_schema.metadata_locks pour afficher l'état MDL de l'opération DDL. Exemple de sortie :

      /*force_node='pi-bp10k7631d6k3****'*/ SELECT * FROM performance_schema.metadata_locks;
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME      | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE           | LOCK_DURATION | LOCK_STATUS | SOURCE             | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
| TABLE       | performance_schema | metadata_locks   | NULL        |       139742994307712 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3810041 |              1 |
| TABLE       | test               | t1               | NULL        |       139742992122240 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3810574 |              1 |
| GLOBAL      | NULL               | NULL             | NULL        |       139742992172544 | INTENTION_EXCLUSIVE | STATEMENT     | GRANTED     | sql_base.cc:5637   |         3810086 |              3 |
| SCHEMA      | test               | NULL             | NULL        |       139742993150592 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | sql_base.cc:5624   |         3810086 |              3 |
| TABLE       | test               | t1               | NULL        |       139742993150848 | SHARED_UPGRADABLE   | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3810086 |              3 |
| BACKUP LOCK | NULL               | NULL             | NULL        |       139742993844096 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | sql_base.cc:5644   |         3810086 |              3 |
| TABLESPACE  | NULL               | test/t1          | NULL        |       139742991805696 | INTENTION_EXCLUSIVE | TRANSACTION   | GRANTED     | lock.cc:815        |         3810086 |              3 |
| TABLE       | test               | #sql-1b34_2ecca1 | NULL        |       139742992091136 | EXCLUSIVE           | STATEMENT     | GRANTED     | sql_table.cc:15532 |         3810086 |              3 |
| TABLE       | test               | t1               | NULL        |       140266021234688 | EXCLUSIVE           | TRANSACTION   | PENDING     | mdl.cc:4124        |         3810086 |              3 |
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
9 rows in set (0.00 sec)

      Vous constatez que le thread 3810574 détient un verrou SHARED_READ sur la table test/t1, ce qui empêche le thread 3810086 d'acquérir le verrou EXCLUSIVE. Utilisez la table performance_schema.threads pour obtenir des informations détaillées sur les threads correspondants. Exemple de sortie :

      /*force_node='pi-bp10k7631d6k3****'*/ SELECT * FROM performance_schema.threads WHERE THREAD_ID IN (3810086,3810574)\G
*************************** 1. row ***************************
          THREAD_ID: 3810086
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 3067041
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 41
  PROCESSLIST_STATE: Waiting for table metadata lock
   PROCESSLIST_INFO: alter table t1 add column d varchar(10),algorithm = inplace
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: TCP/IP
       THREAD_OS_ID: 64852
     RESOURCE_GROUP: NULL
*************************** 2. row ***************************
          THREAD_ID: 3810574
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 3067443
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 46
  PROCESSLIST_STATE: NULL
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: TCP/IP
       THREAD_OS_ID: 65845
     RESOURCE_GROUP: NULL
2 rows in set (0.01 sec)

      Vous constatez que le thread 3810086 est le thread DDL bloqué et que le thread 3810574 correspond à une requête lente. Le thread 3810574 détient le verrou, ce qui empêche l'instruction alter table t1 add column d varchar(10),algorithm = inplace d'acquérir le MDL. L'instruction est donc bloquée. Dans ce cas, attendez que la transaction soit validée selon vos besoins métier, ou utilisez la commande KILL processlist_id pour terminer la transaction, puis réexécutez l'instruction alter table t1 add column d varchar(10),algorithm = inplace.

    • Wait for syncing with replicas

      PolarDB utilise une architecture de cluster. Par conséquent, lorsqu'une opération DDL est exécutée sur le nœud principal, elle doit attendre que tous les nœuds en lecture seule libèrent le MDL correspondant. Si vous observez l'opération DDL dans l'état Wait for syncing with replicas lors de l'utilisation de show processlist, cela indique qu'un nœud en lecture seule détient le MDL sur la table correspondante. Dans ce cas, suivez cette procédure pour identifier rapidement les informations du thread détenteur du verrou sur le nœud en lecture seule.

      Exemple :

      Sur le nœud principal du cluster, exécutez la commande show processlist pour vérifier l'état après avoir exécuté alter table t1 add column d varchar(10),algorithm = inplace. Exemple de sortie :

      /*force_node='pi-bp10k7631d6k3****'*/ SHOW PROCESSLIST;
+-----------+-----------------+-----------------------+--------------------+----------------+---------+--------------------------------+-------------------------------------------------------------+
| Id        | User            | Host                  | db                 | Command        | Time    | State                          | Info                                                        |
+-----------+-----------------+-----------------------+--------------------+----------------+---------+--------------------------------+-------------------------------------------------------------+
|        98 | event_scheduler | localhost             | NULL               | Daemon         | 1307512 | Waiting on empty queue         | NULL                                                        |
|       109 | replicator      | 11.111.XX.XX:62549    | NULL               | Polar Log Dump |       1 | Reading log from innodb        | NULL                                                        |
|       113 | replicator      | 11.111.XX.XX:62560    | NULL               | Polar Log Ack  |       1 | Receiving from client          | NULL                                                        |
|       133 | replicator      | 10.13.64.70:42712     | NULL               | Polar Log Dump |       1 | Reading log from innodb        | NULL                                                        |
|       138 | replicator      | 10.13.64.70:42723     | NULL               | Polar Log Ack  |       0 | Receiving from client          | NULL                                                        |
|       369 | aurora          | 10.111.211.209:33334  | NULL               | Sleep          |       0 |                                | NULL                                                        |
|       370 | aurora          | 10.111.211.209:33336  | NULL               | RDS Push LSN   | 1307339 | starting                       | NULL                                                        |
|       372 | aurora          | 10.111.204.224:37010  | NULL               | Sleep          |       0 |                                | NULL                                                        |
|       373 | aurora          | 10.111.204.224:37019  | NULL               | RDS Push LSN   | 1307339 | starting                       | NULL                                                        |
|   3064011 | root            | 127.0.0.1:59703       | NULL               | Sleep          |     742 |                                | NULL                                                        |
|   3064013 | root            | 127.0.0.1:59710       | NULL               | Sleep          |      21 |                                | NULL                                                        |
|   3064015 | root            | 127.0.0.1:59713       | NULL               | Sleep          |      21 |                                | NULL                                                        |
|   3064018 | root            | 127.0.0.1:59716       | NULL               | Sleep          |       1 |                                | NULL                                                        |
|   3067041 | zyg_root        | 172.17.28.253:48594   | test               | Query          |       6 | Wait for syncing with replicas | alter table t1 add column d varchar(10),algorithm = inplace |
|   3067443 | zyg_root        | 172.17.28.253:48602   | test               | Sleep          |     751 |                                | NULL                                                        |
|   3071863 | aurora          | 100.104.XX.XX:32615   | information_schema | Sleep          |      56 |                                | NULL                                                        |
|   3072000 | aurora          | 100.104.XX.XX:41585   | information_schema | Sleep          |      56 |                                | NULL                                                        |
|   3072126 | aurora          | 10.111.204.224:47050  | NULL               | Sleep          |       2 |                                | NULL                                                        |
|   3072127 | aurora          | 10.111.211.209:41026  | NULL               | Sleep          |       1 |                                | NULL                                                        |
| 270526156 | zyg_root        | 172.17.28.253:46272   | test               | Sleep          |     362 |                                | NULL                                                        |
| 270530026 | zyg_root        | 172.17.28.253:46390   | test               | Query          |       0 | starting                       | /*force_node='pi-bp10k7631d6k3****'*/ show processlist      |
+-----------+-----------------+-----------------------+--------------------+----------------+---------+--------------------------------+-------------------------------------------------------------+
21 rows in set (0.00 sec)

      Vous constatez que l'instruction DDL est dans l'état Wait for syncing with replicas.

      Dans ce cas, utilisez une indication (hint) pour interroger la table performance_schema.metadata_locks sur un nœud en lecture seule spécifié afin d'afficher l'état MDL. Exemple de sortie :

      /*force_node='pi-bp186ko4o21wl****'*/ SELECT * FROM performance_schema.metadata_locks;
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME    | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE           | LOCK_DURATION | LOCK_STATUS | SOURCE             | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
| TABLE       | test               | t1             | NULL        |       139394298895872 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3513381 |              1 |
| TABLE       | test               | t1             | NULL        |       139394298602240 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3519277 |              1 |
| TABLE       | test               | t1             | NULL        |       139917548369664 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3519279 |              1 |
| TABLE       | test               | t1             | NULL        |       139394296661888 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3519278 |              1 |
| TABLE       | test               | t1             | NULL        |       139394297595520 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3519276 |              1 |
| SCHEMA      | test               | NULL           | NULL        |       139464322084864 | INTENTION_EXCLUSIVE | EXPLICIT      | GRANTED     | sql_table.cc:17404 |              57 |              1 |
| TABLE       | test               | t1             | NULL        |       139464322084992 | EXCLUSIVE           | EXPLICIT      | PENDING     | sql_table.cc:17410 |              57 |              1 |
| TABLE       | performance_schema | metadata_locks | NULL        |       139394296038784 | SHARED_READ         | TRANSACTION   | GRANTED     | sql_parse.cc:7688  |         3518506 |              1 |
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
8 rows in set (0.00 sec)

      Vous constatez que les threads 3513381, 3519277, 3519279, 3519278 et 3519276 sur le nœud en lecture seule détiennent des verrous SHARED_READ sur la table test/t1. Utilisez la table performance_schema.threads pour obtenir des informations détaillées sur les threads correspondants. Exemple de sortie :

      /*force_node='pi-bp186ko4o21wl****'*/SELECT * FROM performance_schema.threads WHERE THREAD_ID IN (3519278,3513381,3519279,3519276,3519277)\G
*************************** 1. row ***************************
          THREAD_ID: 3513381
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 538961413
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Connect
   PROCESSLIST_TIME: 103
  PROCESSLIST_STATE: User sleep
   PROCESSLIST_INFO: select *,sleep(60) from t1
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: TCP/IP
       THREAD_OS_ID: 63826
     RESOURCE_GROUP: NULL
*************************** 2. row ***************************
          THREAD_ID: 3519276
               NAME: thread/sql/parallel_worker
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1855915
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 103
  PROCESSLIST_STATE: Sending data
   PROCESSLIST_INFO: select *,sleep(60) from t1
   PARENT_THREAD_ID: 3513381
               ROLE: NULL
       INSTRUMENTED: NO
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 7117
     RESOURCE_GROUP: NULL
*************************** 3. row ***************************
          THREAD_ID: 3519277
               NAME: thread/sql/parallel_worker
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1855917
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 103
  PROCESSLIST_STATE: Sending data
   PROCESSLIST_INFO: select *,sleep(60) from t1
   PARENT_THREAD_ID: 3513381
               ROLE: NULL
       INSTRUMENTED: NO
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 7116
     RESOURCE_GROUP: NULL
*************************** 4. row ***************************
          THREAD_ID: 3519278
               NAME: thread/sql/parallel_worker
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1855916
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 103
  PROCESSLIST_STATE: Sending data
   PROCESSLIST_INFO: select *,sleep(60) from t1
   PARENT_THREAD_ID: 3513381
               ROLE: NULL
       INSTRUMENTED: NO
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 7119
     RESOURCE_GROUP: NULL
*************************** 5. row ***************************
          THREAD_ID: 3519279
               NAME: thread/sql/parallel_worker
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1855918
   PROCESSLIST_USER: zyg_root
   PROCESSLIST_HOST: 172.17.28.253
     PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 103
  PROCESSLIST_STATE: Sending data
   PROCESSLIST_INFO: select *,sleep(60) from t1
   PARENT_THREAD_ID: 3513381
               ROLE: NULL
       INSTRUMENTED: NO
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 7118
     RESOURCE_GROUP: NULL
5 rows in set (0.00 sec)

      Vous constatez qu'une requête exécutée sur le nœud en lecture seule détient les verrous correspondants et ne les a pas libérés depuis longtemps. Comme la requête parallèle est activée, plusieurs threads parallel_worker détiennent simultanément des MDL. Dans ce cas, attendez que la transaction sur le nœud en lecture seule soit validée selon vos besoins métier, ou utilisez la commande KILL processlist_id pour terminer la transaction, puis réexécutez l'instruction alter table t1 add column d varchar(10),algorithm = inplace.

    Nous contacter

    Si vous avez des questions concernant les opérations DDL, Contactez-nous.