Historias de bases de datos espeluznantemente aterradoras – Percona Database Performance Blog

Las noches son cada vez más largas y se acerca el día más espeluznante del año, ¡Halloween! Con el espíritu de las fiestas, le hemos pedido a nuestro equipo que comparta sus historias más aterradoras sobre sustos en las bases de datos, fallas sangrientas del BIOS y destrucción de datos, y algunas de las respuestas son francamente frívolas.

¡Toma algunos dulces y mira las historias de las que los perconianos están demasiado asustados para hablar después del anochecer!

Brian Walters, Director de Ingeniería de Soluciones:

DBA novato en una empresa con un presupuesto bajo = desarrollo, prueba y producción en el mismo servidor. ¿Qué podría estar mal?

Entonces, tengo alrededor de dos años en mi carrera como DBA y parte de mi trabajo es mantener la base de datos para el sistema MRP de la empresa. Este sistema es crítico, sin él toda la planta se cerrará.

Durante la implementación del sistema MRP, la empresa había caído en la mala práctica de utilizar el servidor de base de datos de producción también para el desarrollo y las pruebas. Hice algunas preguntas sobre el hardware de desarrollo/prueba dedicado, pero esto no parecía ser una prioridad para quienes controlan el presupuesto.

Mis días suelen comenzar con las mismas pocas tareas: verificar las copias de seguridad de la noche anterior, eliminar la base de datos de prueba del día anterior y crear un nuevo entorno de prueba para restaurar la copia de seguridad de la noche anterior. Tenía mi rutina bastante apretada, la mayor parte estaba escrita. Todo lo que tenía que hacer era cambiar una variable de entorno y ejecutar los scripts diarios.

Todo esto funcionó bien hasta que un día… esa mañana, estaba un poco más cansada que de costumbre. Inicié sesión en el servidor de la base de datos y pensé que había configurado las variables de entorno como se indica en la base de datos de prueba. Debido a la fuerza de un mal hábito, una falla mental o una alucinación temporal espeluznante, en realidad configuré accidentalmente las variables de entorno para que produjeran… y luego ejecuté los scripts de eliminación de la base de datos. .

De alguna manera, me di cuenta de mi error casi antes de que la contraseña estuviera completamente presionada. Pero para entonces ya era demasiado tarde. La primera llamada telefónica tardó menos de diez segundos en llegar. Por supuesto, lo envié a mi correo de voz, junto con las siguientes tres llamadas telefónicas que siguieron de inmediato. Mi siguiente instinto fue presionar el botón Enviar todas las llamadas. Dirigiéndome a mis manos, entendiendo completamente lo que acababa de suceder, luché por descubrir cómo hacerlo.

Después de una conversación rápida con mi jefe, que también es el director financiero, se eliminó mi archivo del día. Pasé el resto de la mañana practicando mis habilidades de Recuperación de Punto en el Tiempo. Hasta el día de hoy, estoy agradecido de haber tenido un plan de restauración y seguridad sólido y probado. Me fui a casa más temprano ese día. Y fue la última vez que cometí un error así. Compramos desarrollo/prueba de hardware dedicado aproximadamente un mes después.

Robert Bernier, consultor de PostgreSQL

Estaba trabajando como un DBA senior recién asociado cuando dos desarrolladores aparecieron repentinamente en mi escritorio en un estado mental muy agitado y emocionado. Estaban enojados porque accidentalmente enviaron actualizaciones del sistema operativo a los dispositivos integrados que estaban instalados en muchos de nuestros dispositivos cliente. Estas actualizaciones prematuras los bloquearon de manera efectiva, sumando decenas de miles.

No creo que deba ser una sorpresa, pero en realidad «requiere» que realice una reversión de inmediato. No hace falta decir que, siendo un asociado nuevo, había algunas cosas que no siempre sabía y estaba ansioso por evitar que la situación se equivoque. Así que lo invité a buscar un par de sillas, se sentó a mi lado y se tomó su tiempo para “explicarme” quiénes eran y qué habían hecho en la empresa. Eventualmente, llegué a los eventos que llevaron al incidente. Disminuir la velocidad era su principal preocupación, ya que el éxito de la reversión impulsó su forma de pensar. Al mismo tiempo, pudieron demostrar el problema y su resolución. En un par de horas, hicimos la reversión a través de los dispositivos afectados y los desbloqueamos.

En retrospectiva, podría ser malo, ya que el almacén de datos que administraba contenía varios cientos de TB que representaban 600 000 dispositivos integrados.

La moraleja de la historia, jejeje… Siempre sabes dónde encontrar tu toalla.

Audrey Swagerty, Gerente de Éxito del Cliente

Esta no es una historia de tecnología sino una verdadera pesadilla.

Cuando comencé como CSR, hace 3,5 años, no estaba familiarizado con nuestra industria y tecnologías, por lo que fue todo un desafío… una pesadilla recurrente. Una chica me perseguía por el bosque… y finalmente me alcanzaba, me levantaba y me preguntaba su nombre (no me pregunten por qué… en lugar de pedirle que no me mate 🙂)… Y ella decía : soy mongodb!!! ¡Entonces me despertaré!

No he pensado en esa historia en bastante tiempo (y no he tenido la misma pesadilla desde entonces), ¡así que fue divertido compartirla con ustedes nuevamente! Espero que no vuelva a suceder este fin de semana… ¡Intenté ayudar a un cliente con preguntas de Kubernetes para que nunca se sepa! ⁇

Marcos Albe, Ingeniero Jefe de Servicios Técnicos

La peor historia de terror es un hospital que introduce inconsistencias en una base de datos… ¡Siempre he temido que alguien con asma termine amputado debido a datos rotos!

Patrick Birch, redactor técnico sénior

Mientras era DBA de SQL Server, mi CTO permitía a los redactores de informes acceder a la base de datos de producción. Los redactores de informes eran personas muy agradables, pero carecían de ciertas cualidades, como la capacidad de escribir código SQL. Escribí sus preguntas y le pedí que cumpliera con sus requisitos a través de mí. Bueno, fui a almorzar un día, y cuando regresé, el CTO y otros gerentes estaban presentes. ¡Uno de los redactores del informe había escrito un cartesiano de enlace cruzado y la base de datos de producción se estaba ralentizando a paso de tortuga!

Apagué la conexión y tuve una larga conversación con los redactores del informe. Los gerentes aprobaron mi construcción de un almacén de datos al día siguiente.

Martin James, vicepresidente de ventas de EMEA y APAC

En mi última empresa, comencé a observar la aterradora realidad de la seguridad y la salud de los datos. Dado que la niebla y el dulce sabor afrutado proporcionan el telón de fondo perfecto para las tradiciones fantasmales de Halloween, el futuro fantasmal se ha descubierto en espacios inesperados. No en lúgubres cementerios o desvanecidos áticos, sino en las bases de datos de los médicos generales de Inglaterra.

En 2016, los datos de 57 millones de pacientes se mantuvieron en los registros de los médicos generales. Sin embargo, los datos del censo en ese momento sugieren que esto debería ser solo $ 54 millones. Entonces, ¿qué son estos 3 millones de personas adicionales? Estos registros pertenecen a «pacientes fantasma»: pacientes que han muerto o emigrado o tienen registros duplicados/inexactos. Sin embargo, tiene un impacto en las cirugías, la financiación y los servicios prestados, añadiendo una presión innecesaria al NHS y dejándolos incapaces de proporcionar una imagen precisa de sus pacientes y la atención que brindan.

Por lo tanto, NHS England ha iniciado una caza fantasma para rastrear e identificar a los propietarios de estos registros para que puedan actualizar sus datos y ahorrar dinero. Si un paciente no ha visto a su médico de cabecera durante cinco años, se le enviará una carta pidiéndole que responda. Si no responde, se enviará una segunda carta, luego de lo cual se eliminará del registro de pacientes. Esta podría ser una medida que haga una salvación inmediata, ya que, según un BBC, a los médicos de familia se les paga por cada paciente registrado en su lista (fantasma o no) y el Times estima que esto ronda los 400 millones de libras esterlinas al año.

Profundizar en los datos de los pacientes y las conexiones que contienen podría ser de gran beneficio para el servicio de salud. Permitirá un escrutinio más detallado de los datos e impulsará el cumplimiento, además de ayudar al NHS a mejorar la precisión y precisión en sus registros. Sus datos se convertirán en un activo y en un medio de inteligencia sanitaria nacional. ¿Una visión utópica? Tal vez, ¡pero nada de cazafantasmas!

¿Cuál es tu historia de base de datos más aterradora? Háganos saber en los comentarios o respondenos en las redes sociales ¡así podemos buscar en la base de datos de demonios y duendes! Y para aprender cómo Los expertos de Percona pueden quitarle el miedo a la gestión de bases de datos, consulte nuestra base de datos de código abierto apoyo, servicios gestionados, y consultar servicios.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario