Historias de terror: el día que rompí producción con una consulta
Josefina
Nivel 3 ·
Josefina
Nivel 3 ·
Tomás N.
Nivel 2 ·
DELETE FROM pedidos; con el WHERE en la línea de abajo, que no quedó seleccionada en el editor. Ejecuté solo la primera línea. Clásico.
Benja75
Nivel 3 ·
Desde que me pasó algo así escribo primero el SELECT con el WHERE, veo que traiga lo que quiero, y recién después lo cambio por DELETE.
Benjamín F.
Nivel 3 ·
Yo trabajo siempre dentro de una transacción: BEGIN; ... reviso las filas afectadas ... y después COMMIT o ROLLBACK. Me salvó más de una vez.
Mario P.
Nivel 3 ·
Hay clientes de base de datos que te avisan o bloquean UPDATE y DELETE sin WHERE. Activalo, en serio.
Daniela
Nivel 3 ·
MySQL tiene el modo safe updates, que rechaza UPDATE y DELETE sin WHERE por clave. Lo tengo prendido en la consola.
Benjamín R.
Nivel 3 ·
El mío: DROP TABLE en la base equivocada porque tenía dos pestañas abiertas, una de desarrollo y otra de producción. Ahora la conexión de producción tiene fondo rojo.
Gabriel B.
Nivel 3 ·
Lo del fondo rojo es oro. Lo hacemos en todo el equipo.
HechiceroCoyote
Nivel 3 ·
Lo peor no fue el error sino descubrir que el backup 'diario' no corría hacía tres semanas. Un backup que nunca probaste restaurar no es un backup.
Josefina
Nivel 3 ·
Esa última es mi pesadilla. Por suerte el nuestro andaba. Desde ese día probamos restaurar una vez por mes.
Gabriel B.
Nivel 3 ·
Una migración que creaba un índice en una tabla de 200 millones de filas, en horario pico, bloqueando escrituras. Postgres tiene CREATE INDEX CONCURRENTLY por algo jaja
Mario P.
Nivel 3 ·
Leer este hilo me da ansiedad y paz a la vez. No soy el único.
Natalia G.
Nivel 3 ·
Regla de oro: en producción, permisos de solo lectura por defecto. Si necesitás escribir, lo pedís y queda registrado.