synch/cond/sql/MDL_context::COND_wait_status
El evento synch/cond/sql/MDL_context::COND_wait_status se produce cuando hay subprocesos a la espera en un bloqueo de metadatos de tabla.
Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
-
Aurora MySQL, versiones 2 y 3
Contexto
El evento synch/cond/sql/MDL_context::COND_wait_status indica que hay subprocesos a la espera en un bloqueo de metadatos de tabla. En determinados casos, una sesión mantiene un bloqueo de metadatos en una tabla mientras otra sesión intenta adquirir el mismo bloqueo en la misma tabla. En tal caso, la segunda sesión espera en el evento de espera synch/cond/sql/MDL_context::COND_wait_status.
MySQL utiliza el bloqueo de metadatos para administrar el acceso simultáneo a los objetos de base de datos y garantizar la coherencia de los datos. El bloqueo de metadatos se aplica a tablas, esquemas, eventos programados, espacios de tabla y bloqueos de usuario adquiridos con la función get_lock y programas almacenados. Los programas almacenados incluyen procedimientos, funciones y desencadenadores. Para obtener más información, consulte Metadata locking
La lista de procesos de MySQL muestra esta sesión en el estado waiting for metadata
lock. En Información sobre rendimiento, si Performance_schema está activado, el evento synch/cond/sql/MDL_context::COND_wait_status aparece.
El tiempo de espera predeterminado de una consulta a la espera de un bloqueo de metadatos se basa en el valor del parámetro lock_wait_timeout, que por defecto es 31 536 000 segundos (365 días).
Para obtener más información sobre los distintos bloqueos de InnoDB y los tipos de bloqueos que pueden provocar conflictos, consulte InnoDB Locking
Causas probables del aumento de las esperas
Cuando el evento synch/cond/sql/MDL_context::COND_wait_status aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
- Transacciones de larga duración
-
Una o varias transacciones están modificando una gran cantidad de datos y mantienen bloqueos en las tablas durante mucho tiempo.
- Transacciones inactivas
-
Una o más transacciones permanecen abiertas durante mucho tiempo, sin confirmarse o revertirse.
- Instrucciones DDL en tablas de gran tamaño
-
Una o varias instrucciones de definición de datos (DDL), como, por ejemplo, los comandos
ALTER TABLE, se ejecutaron en tablas de gran tamaño. - Bloqueos de tabla explícitos
-
Hay bloqueos explícitos en tablas que no se están lanzando a tiempo. Por ejemplo, una aplicación puede ejecutar instrucciones
LOCK TABLEde manera incorrecta.
Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera y de la versión del clúster de Aurora MySQL DB.
Temas
Identificar las sesiones y consultas que provocan los eventos
Puede utilizar Información sobre rendimiento para mostrar las consultas que bloqueó el evento de espera synch/cond/sql/MDL_context::COND_wait_status. Sin embargo, para identificar la sesión de bloqueo, consulte las tablas de metadatos desde performance_schema y information_schema en el clúster de base de datos.
Normalmente, las bases de datos con una carga de moderada a significativa tienen eventos de espera. Los eventos de espera pueden ser aceptables si el rendimiento es óptimo. Si el rendimiento no es óptimo, examine dónde pasa más tiempo la base de datos. Preste atención a los eventos de espera que contribuyen a la carga más alta y averigüe si puede optimizar la base de datos y la aplicación para reducirlos.
Para buscar consultas SQL responsables de cargas elevadas
Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/
. -
En el panel de navegación, seleccione Performance Insights.
-
Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
-
En el cuadro Database load (Carga de base de datos), elija Slice by wait (Corte por espera).
-
En la parte inferior de la página, elija Top SQL (SQL principal).
El gráfico enumera las consultas SQL responsables de la carga. Las que están en la parte superior de la lista son las más importantes. Para resolver un cuello de botella, céntrese en estas instrucciones.
Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog de AWS Database Analyze Amazon Aurora MySQL Workloads with Performance Insights
Verificar eventos pasados
Puede obtener información sobre este evento de espera para verificar si hay ocurrencias anteriores del mismo. Para ello, complete las acciones siguientes:
-
Verifique el lenguaje de manipulación de datos (DML) y el rendimiento y la latencia de DDL para ver si se han producido cambios en la carga de trabajo.
Puede utilizar Información sobre rendimiento para buscar las consultas que están a la espera en este evento en el momento del problema. Además, puede ver el resumen de las consultas que se ejecutan cerca del momento del problema.
-
Si los registros de auditoría o los registros generales están activados para el clúster de base de datos, puede verificar si se ejecutan todas las consultas en los objetos (schema.table) involucrados en la transacción en espera. También puede verificar si se han completado las consultas que se ejecutaron antes de la transacción.
La información disponible para solucionar problemas de eventos pasados es limitada. La realización de estas verificaciones no muestra qué objeto está a la espera de información. Sin embargo, puede identificar tablas con cargas pesadas en el momento en que se produjo el evento y el conjunto de filas operadas con frecuencia que provocan conflictos en el momento del problema. A continuación, podrá utilizar esta información para reproducir el problema en un entorno de prueba y proporcionar información sobre su causa.
Ejecutar consultas en Aurora MySQL versión 2
En Aurora MySQL versión 2, puede identificar la sesión bloqueada directamente con la consulta de tablas performance_schema o vistas de esquema sys. Un ejemplo puede ilustrar cómo consultar tablas para identificar consultas y sesiones de bloqueo.
En el siguiente resultado de la lista de procesos, el ID de conexión 89 está a la espera en un bloqueo de metadatos y ejecuta el comando TRUNCATE TABLE. En una consulta sobre las tablas performance_schema o las vistas de esquema sys, el resultado muestra que la sesión de bloqueo es 76.
MySQL [(none)]> select @@version, @@aurora_version; +-----------+------------------+ | @@version | @@aurora_version | +-----------+------------------+ | 5.7.12 | 2.09.0 | +-----------+------------------+ 1 row in set (0.01 sec) MySQL [(none)]> show processlist; +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL | | 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL | | 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL | | 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL | | 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL | | 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL | | 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL | | 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL | | 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL | | 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL | | 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL | | 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL | | 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL | | 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist | | 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) | | 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ 18 rows in set (0.00 sec)
A continuación, una consulta sobre las tablas performance_schema o las vistas de esquema sys muestra que la sesión de bloqueo es 76.
MySQL [(none)]> select * from sys.schema_table_lock_waits; +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ 1 row in set (0.00 sec)
Responder a la sesión de bloqueo
Cuando identifique la sesión, puede seguir una de las opciones siguientes:
-
Ponerse en contacto con el propietario o el usuario de la aplicación.
-
Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte Finalización de una sesión o una consulta.
Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte Using InnoDB Transaction and Locking Information
