Skip to content

Actualizaciones de rutina y crisis existenciales

Todos hemos escuchado la típica historia de tragedia que sucede cuando una actualización de rutina en un sistema que funciona sin problemas resulta en un fallo catastrófico. Son historias muy interesantes hasta que te sucede a ti.

No es ningún secreto mi afinidad hacia sistemas operativos basados en Unix/Linux. Para todos los sistemas y sitios web que he colaborado en construir o simplemente dar un lugar para alojarlos siempre utilizo alguna variación de Linux, y como buen administrador de sistemas hago actualizaciones periódicas para mantener al día los paquetes y parches de seguridad. Esto es siempre una buena práctica y se recomienda hacierlo de forma seguida.

El otro día sin embargo un inofensivo yum update -y resultó ser el detonante de una crisis que me tomó varias horas revertir y dejar todo de regreso funcionando con normalidad. Este blog incluido estuvo dentro de las víctimas de esta actualización. Luego de minutos tensos de análisis forense para determinar qué había salido mal encontré que mi instalación local de MariaDB/MySQL se había detenido y no había forma de levantar el servicio de nuevo. Pánico total.

Sin entrar a detalles muy técnicos, luego de infinidad de intentos fallidos por levantar el servicio me di cuenta que mi versión de MariaDB estaba congelada en una versión 5.x cuando la versión estable actual se encuentra ya por la numeración 10.x. Luego de hacer un backup minucioso de los archivos físicos de base de datos de este y varios sitios más que están alojados en el servidor afectado, me encomendé en las manos de Dios e hice un último intento desesperado: desinstalé por completo el manejador de base de datos y todas las librerías asociadas, actualicé los repositorios a los que tiene acceso dicho servidor e instalé la versión 10.x de base de datos.

En cuestión de segundos se encontraba todo instalado, pero aún tenía dudas acerca de si luego de tantas horas de angustia y de batallar contra errores aparentemente sin sentido se iban a solucionar con simplemente reemplazar la base de datos con una versión más reciente. Y mi sorpresa fue mayúscula cuando al levantar el servicio de base de datos, todos los sitios regresaron a la vida tal como si nada hubiera sucedido nunca. Una tarde completa perdida, frustración y crisis existencial incluída.

Luego de superada la crisis y analizar lo sucedido, creo firmemente que la versión de la base de datos no era en sí el problema real. Esa versión de base de datos la he venido utilizando hace ya bastante tiempo y si bien no era la más actual era una versión estable que no hacía falta actualizarla de forma urgente. Terminé tomando esta solución drástica debido a que luego de horas de leer documentación y no encontrar ningún problema similar en ningún lado, me resultaba muy sospechoso que el error fuera que no reconocía una variable que no estaba seteando yo en ningún archivo de configuración explícitamente. Quitar por completo la versión existente y reemplazarla por la versión más reciente fue ciertamente una apuesta bastante arriesgada y que en mi caso resultó acertada. Probablemente algún paquete que se actualizó en el sistema operativo durante la actualización de rutina entró en conflicto con esa versión tan antigua de base de datos e impedía levantar el servicio… nunca lo sabré.

La moraleja de la historia es sencilla. Siempre que se hace una actualización y hay una advertencia de tener un backup preparado previo a comenzar, por salud mental hay que hacer caso y hacer el bendito backup. Si es un servidor virtualizado y el proveedor del servicio ofrece la opción, es muy recomendable hacer snapshots regulares del mismo, algún día pueden salvarte la vida.

Published inBases de datosOpinión