# synch/cond/sql/MDL\$1context::COND\$1wait\$1status 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. **Topics** + [Versiones del motor admitidas](#ams-waits.cond-wait-status.context.supported) + [Contexto](#ams-waits.cond-wait-status.context) + [Causas probables del aumento de las esperas](#ams-waits.cond-wait-status.causes) + [Acciones](#ams-waits.cond-wait-status.actions) ## 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](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) en la documentación de MySQL. 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) en la documentación de MySQL. ## 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 TABLE` de 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. **Topics** + [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.cond-wait-status.actions.identify) + [Verificar eventos pasados](#ams-waits.cond-wait-status.actions.past-events) + [Ejecutar consultas en Aurora MySQL versión 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57) + [Responder a la sesión de bloqueo](#ams-waits.cond-wait-status.actions.blocker) ### 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** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, seleccione **Información sobre rendimiento**. 1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos. 1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**. 1. 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](https://aws.amazon.com/blogs/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.11.5 | +-----------+------------------+ 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](mysql-stored-proc-ending.md). Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) en la documentación de MySQL.