Cómo solucionar el error Lock wait timeout exceeded (1205) en Magento 2

Comprendiendo el error Lock wait timeout exceeded en Magento 2

El error SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction es una de las incidencias más críticas y complejas a las que se enfrenta un administrador de sistemas o desarrollador en Magento 2 (Adobe Commerce). Este fallo se manifiesta comúnmente durante operaciones concurrentes intensivas, tales como la sincronización de inventario mediante ERP, la ejecución simultánea de tareas cron de reindexación, o picos elevados de tráfico en momentos de checkout donde múltiples hilos intentan escribir o bloquear las mismas filas o tablas en la base de datos MySQL/MariaDB.

A diferencia de un error de sintaxis PHP o una caída de caché, este fallo no indica necesariamente un código defectuoso, sino una saturación o contención a nivel de motor de almacenamiento InnoDB. Cuando una transacción inicia un bloqueo exclusivo sobre determinados registros (por ejemplo, en las tablas sales_order, cataloginventory_stock_item o catalog_product_index_price), cualquier otra transacción que requiera esos datos debe esperar. Si la transacción previa no completa sus operaciones antes del umbral definido por la variable del sistema innodb_lock_wait_timeout, el motor de base de datos interrumpe la transacción entrante y lanza la excepción 1205.

Causas principales de los bloqueos transaccionales en Magento 2

Para abordar una solución duradera, resulta indispensable identificar el vector exacto que propicia la retención prolongada de transacciones:

• Modo de indexación en Update on Save: Si los indexadores de Magento están configurados en modo sincrónico, cada actualización de producto, pedido o cliente bloqueará tablas completas o índices pesados mientras se recalcula la información, impidiendo que el frontend complete ventas concurrentes.
• Solapamiento masivo de tareas Cron: Cuando el programador de Magento ejecuta múltiples procesos simultáneos (como limpieza de registros, actualización de precios y agregación de reportes) sobre las mismas estructuras transaccionales.
• Configuración insuficiente de MySQL/InnoDB: Parámetros predeterminados en my.cnf que no se adaptan al volumen transaccional de una tienda de comercio electrónico moderna, provocando que hilos queden atascados ante la falta de memoria en el búfer o lentitud en disco I/O.
• Deadlocks encubiertos y transacciones de larga duración: Módulos de terceros mal optimizados que abren transacciones con $connection->beginTransaction() y realizan llamadas externas a APIs lentas (gateways de pago, ERPs, CRMs) antes de ejecutar el correspondiente commit().

Método 1: Diagnóstico en tiempo real y detección de consultas bloqueantes

Antes de modificar variables o matar procesos indiscriminadamente, es obligatorio monitorear qué transacción mantiene bloqueados los recursos en InnoDB. Accede a tu consola MySQL como usuario privilegiado y ejecuta las siguientes consultas de inspección:

SHOW FULL PROCESSLIST;

SELECT * FROM information_schema.innodb_locks;
SELECT * FROM information_schema.innodb_lock_waits;

Para versiones modernas de MySQL 8.0 y MariaDB 10.5+, la información detallada de contención se encuentra en el esquema de rendimiento (Performance Schema). Puedes consultar los hilos bloqueados y los bloqueadores mediante la siguiente instrucción:

SELECT 
    r.trx_id AS waiting_trx_id,
    r.trx_mysql_thread_id AS waiting_thread,
    r.trx_query AS waiting_query,
    b.trx_id AS blocking_trx_id,
    b.trx_mysql_thread_id AS blocking_thread,
    b.trx_query AS blocking_query
FROM performance_schema.data_lock_waits w
JOIN information_schema.innodb_trx b 
    ON b.trx_id = w.blocking_engine_transaction_id
JOIN information_schema.innodb_trx r 
    ON r.trx_id = w.requesting_engine_transaction_id;

Si detectas un hilo residual en estado de suspensión o ejecutando una consulta que excede cientos de segundos, puedes terminarlo manualmente utilizando su ID de hilo de proceso:

KILL 12485;

Sustituye 12485 por el valor obtenido en blocking_thread. Esto liberará los bloqueos de forma inmediata y descongestionará las peticiones en cola.

Método 2: Cambiar los indexadores a Update by Schedule

El estándar de oro en cualquier despliegue de Magento 2 en producción es desacoplar las operaciones transaccionales directas del recalculo de índices. Si tus indexadores están operando en modo Update on Save, el riesgo de experimentar bloqueos 1205 es inminente durante actualizaciones de catálogo o sincronizaciones masivas.

Para verificar el estado de tus indexadores y conmutarlos al modo asíncrono programado, ejecuta los siguientes comandos desde el directorio raíz de Magento:

bin/magento indexer:status
bin/magento indexer:set-mode schedule
bin/magento indexer:status

Al cambiar a schedule, los eventos de cambio simplemente insertan identificadores en tablas de cola (sufijo _cl, como catalog_product_price_cl). Posteriormente, el proceso de cron de Magento (cron:run) procesará estas colas por lotes controlados en segundo plano mediante hilos independientes, eliminando drásticamente los bloqueos sobre las tablas principales utilizadas durante la navegación y el checkout de los usuarios.

Método 3: Optimización de variables InnoDB en my.cnf

El valor por defecto de innodb_lock_wait_timeout suele ser de 50 segundos. Si bien incrementarlo de forma desmedida puede enmascarar transacciones muertas, en entornos con alto tráfico o almacenes complejos con catálogos pesados es recomendable ajustarlo en combinación con el tamaño de los registros de rehacer (redo logs) y el buffer pool.

Edita tu archivo de configuración de base de datos (habitualmente ubicado en /etc/mysql/my.cnf o /etc/mysql/mysql.conf.d/mysqld.cnf) y añade o modifica los siguientes parámetros dentro de la sección [mysqld]:

[mysqld]
# Tiempo maximo de espera para bloqueos de fila InnoDB (en segundos)
innodb_lock_wait_timeout = 120

# Deteccion automatica de interbloqueos
innodb_deadlock_detect = ON

# Asignar entre el 60% y el 75% de la memoria RAM disponible al Buffer Pool
innodb_buffer_pool_size = 12G

# Optimizar la concurrencia de hilos del motor
innodb_thread_concurrency = 0
innodb_read_io_threads = 8
innodb_write_io_threads = 8

# Estrategia de volcado a disco segura y optimizada para transacciones
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

Tras realizar estas modificaciones, reinicia el servicio de base de datos para que los cambios surtan efecto:

sudo systemctl restart mysql
# O en el caso de MariaDB:
sudo systemctl restart mariadb

Nota técnica: Establecer innodb_flush_log_at_trx_commit = 2 escribe el log de transacciones en caché del sistema operativo en cada commit y lo descarga a disco una vez por segundo. Esto reduce de manera exponencial la latencia en escrituras concurrentes intensivas, mitigando en gran medida las colas de espera que derivan en el error 1205.

Método 4: Detección y corrección de bloqueos originados por crons paralelos

Un escenario clásico en Magento 2 ocurre cuando el demonio cron del sistema invoca bin/magento cron:run mientras una ejecución previa todavía no ha concluido. Si un proceso de reindexación o sincronización de inventario se prolonga por más de un minuto, el siguiente ciclo del crontab iniciará un nuevo subproceso que intentará adquirir los mismos bloqueos sobre las tablas de inventario o catálogos, provocando una colisión directa en cascada.

Para verificar si tienes múltiples procesos de cron compitiendo por recursos, revisa los procesos activos en tu servidor:

ps aux | grep bin/magento

Si observas decenas de procesos en paralelo consumiendo CPU y reteniendo hilos de base de datos, procede a detenerlos de forma controlada:

pkill -f 'bin/magento cron:run'

Posteriormente, accede a la base de datos y purga los registros de cron que hayan quedado en estado running huérfano, ya que estos pueden provocar colisiones en los candados lógicos internos de la aplicación:

DELETE FROM cron_schedule WHERE status = 'running';

Para prevenir que esto ocurra en el futuro, asegúrate de que tus indexadores y procesos pesados estén correctamente particionados en grupos cron dedicados (como el grupo index) y evita planificaciones que solapen tareas masivas durante las horas de mayor afluencia de clientes en el sitio web.

Verificación final y monitoreo preventivo

Una vez aplicadas las correcciones en la base de datos y en los indexadores de Magento, es imperativo vaciar las cachés de la plataforma para asegurar que ningún esquema desactualizado persista en Redis o en el sistema de archivos local:

bin/magento cache:clean
bin/magento cache:flush

Monitorea activamente el archivo var/log/exception.log durante los siguientes picos de venta. Con los indexadores operando de forma programada, las variables de InnoDB calibradas para alta concurrencia y la eliminación de procesos cron solapados, el error Lock wait timeout exceeded quedará solventado de manera definitiva, garantizando una experiencia de compra fluida y una operativa transaccional estable en tu tienda Magento.