Bloqueos por cambios de esquema (DDL) en producción Schema change lock (DDL / metadata lock)
ID de la causa db-ddl-lock · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si se añade una columna o un índice a una tabla con el servicio en marcha, un bloqueo que solo se necesita durante un instante puede dejar esperando a todas las solicitudes que usan esa tabla.
Por qué Un hotfix añade una columna o un índice a una tabla en producción → Efecto El cambio de esquema espera a una transacción larga que ya estaba abierta, y todas las solicitudes que llegan después esperan al cambio de esquema → En pantalla Las funciones que usan esa tabla (inventario, correo, etc.) se quedan congeladas por completo y dan timeout
De vez en cuando, al azar, Al conectar o tras un mantenimiento
Responsable
Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Acordar con el responsable de infraestructura de BD el calendario de los hotfixes con cambios de esquema, desplegar primero el código que funciona aunque la columna nueva no exista.
Tareas (Equipo de infraestructura)
Poner un límite de espera de bloqueo corto y reintentar si falla, ejecutar el cambio cuando no haya transacciones largas, usar herramientas de cambio online, hacer los cambios en tablas grandes durante el mantenimiento.
En el gráfico
Salto en escalón · Sesiones esperando un bloqueo, latencia de las consultas de esa tabla
Dónde mirar
En MySQL, contar las sesiones con State Waiting for table metadata lock en SHOW PROCESSLIST y buscar la sesión que bloquea (blocking_pid) con sys.schema_table_lock_waits. En PostgreSQL, las solicitudes con granted en false y AccessExclusiveLock en pg_locks, y la sesión que bloquea con pg_blocking_pids()
Se confirma si
Desde la hora en que empezó el cambio de esquema, todas las consultas a esa tabla se acumulan esperando el bloqueo, y al principio de la cola hay una transacción sin terminar o la sentencia del cambio de esquema
Se descarta si
Si las esperas se concentran en filas concretas y las demás filas de la misma tabla se procesan bien, apunta a una fila caliente (db-hot-row)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Para cambiar el esquema, MySQL retiene un momento un bloqueo de metadatos y PostgreSQL el bloqueo de tabla más fuerte. Aunque el cambio en sí sea instantáneo, si delante hay una transacción sin terminar, todas las solicitudes quedan esperando detrás.
Fuentes
Online DDL Performance and ConcurrencyMySQL Incluso el DDL online necesita un bloqueo exclusivo de metadatos durante un instante al terminar; si hay una transacción larga, espera, y esa solicitud de bloqueo en espera bloquea todas las transacciones posteriores
Server System VariablesMySQL lock_wait_timeout: límite de espera del bloqueo de metadatos, 31,536,000 segundos (1 año) por defecto