Guía de actualización de bases de datos autohospedadas: volcado, instantánea, migración y reversión
El enfoque seguro consiste en tratar una actualización gradual mediante volcados nativos, instantáneas de almacenamiento, un ensayo de restauración aislado y un punto de reversión claramente delimitado como una secuencia de comprobaciones observables, no como un único comando.
En una base de datos PostgreSQL o MariaDB en contenedores alojada en un servidor doméstico, el riesgo práctico es que una base de datos autoalojada necesita una actualización de versión sin perder objetos lógicos ni una vía de reversión viable. Registra la identidad actual y el punto de recuperación, empieza por el criterio menos invasivo, interpreta los resultados correctos e incorrectos antes de cambiar otra variable y detente cuando el almacenamiento se vuelva inestable o la única copia recuperable pudiera quedar expuesta. El flujo de trabajo siguiente termina solo cuando la carga de trabajo original funciona correctamente o las evidencias alcanzan un límite que requiere escalar el problema.
Define la compatibilidad y la reversión antes de hacer la copia de seguridad
Registra el motor de base de datos y la versión exacta de origen, la versión de destino, la versión de la aplicación, las extensiones o complementos, el juego de caracteres, las reglas de autenticación, las tareas programadas y el tiempo de inactividad disponible. Lee las notas de actualización de la aplicación además de las relativas a la base de datos, porque una migración de la aplicación puede hacer que los binarios antiguos sean incompatibles con el nuevo esquema.
Las actualizaciones principales suelen requerir un volcado lógico y una restauración, o una herramienta de migración compatible, en lugar de montar el directorio de datos antiguo en una imagen nueva. Un flujo independiente de actualización de versión principal de una base de datos en Compose explica una actualización de versión principal de PostgreSQL basada en Compose y muestra por qué el contenedor y el volumen antiguos deben mantenerse separados del destino.
Escribe ahora el plazo y el desencadenante de la reversión: comprobaciones de integridad fallidas, roles o extensiones ausentes, errores de la aplicación o un rendimiento inaceptable. La reversión sigue siendo viable solo hasta que comiencen las escrituras de producción en el destino, a menos que se haya probado un plan de migración de datos inversa.
Crea dos puntos de recuperación independientes
Ejecuta la copia de seguridad lógica nativa del motor con los objetos globales cuando corresponda y guarda el comando, la versión, el estado de salida, el manifiesto y la suma de comprobación. Verifica que se incluyan los usuarios, las concesiones, las extensiones, los esquemas, las tareas programadas y los objetos grandes, en lugar de suponer que un único volcado de base de datos contiene todas las dependencias del servidor.
Realiza una instantánea coordinada o una copia de la base de datos con el servicio detenido después de confirmar que la base de datos se encuentra en un estado compatible. El volcado lógico proporciona portabilidad e inspección a nivel de objeto; la copia del almacenamiento conserva un punto exacto de reversión de la versión antigua. Ninguna debe sobrescribir la otra.
Usa la lista de comprobación de verificación de ZimaSpace para comprobar si la lista de comprobación de integridad de la copia de seguridad de la base de datos está completa. La comprobación de la copia de seguridad se supera solo cuando el volcado se puede leer, el punto de recuperación del almacenamiento está identificado y ambos se guardan fuera del volumen que se va a actualizar.
Ensaya la migración en un destino aislado
Inicia la base de datos de destino en un volumen y puerto independientes, instala las extensiones necesarias, restaura la copia de seguridad lógica y guarda todas las advertencias. Una guía de Percona sobre la ruta de actualización mediante volcado lógico y restauración destaca la secuencia de volcado y restauración, así como la necesidad de usar herramientas que coincidan con la ruta de actualización de PostgreSQL prevista.
Conecta una instancia desechable de la aplicación a la base de datos restaurada. Prueba el inicio de sesión, las lecturas, las escrituras, las tareas en segundo plano, la búsqueda, los archivos adjuntos, las zonas horarias y un reinicio. Compara los recuentos de filas y las agregaciones críticas en lugar de confiar únicamente en un código de salida de restauración correcto.
No continúes si las extensiones no están disponibles, los cambios de intercalación no están resueltos, las migraciones fallan o el tiempo de restauración supera la ventana de mantenimiento. Corrige el ensayo y crea un volcado nuevo; producción no es el lugar para descubrir incompatibilidades con la versión de destino.
Cambia las escrituras y mantén limpia la reversión
Entra en modo de mantenimiento, detén los procesos que escriben en la aplicación y las tareas, confirma que las conexiones activas se han cerrado y crea después el volcado final o el diferencial compatible. Restáuralo en un destino limpio, ejecuta comprobaciones de integridad y de objetos, actualiza la conexión de la aplicación e inicia los servicios en el orden de sus dependencias.
Observa las tasas de error, los bloqueos, la ejecución de tareas, las copias de seguridad y las transacciones reales de la aplicación. Mantén la base de datos antigua detenida y en modo de solo lectura, con su volumen original y el resumen criptográfico de su imagen. Nunca permitas que ambas bases de datos acepten escrituras independientes con la misma identidad de aplicación.
Declara el éxito solo después de que la aplicación, la tarea de copia de seguridad nativa, el reinicio y una restauración de prueba desde la nueva versión hayan superado todas las comprobaciones. Si se activa un desencadenante de reversión antes del límite de escritura, vuelve a apuntar la aplicación a la instancia antigua conservada; después de las nuevas escrituras, detente y utiliza el plan de conciliación documentado en lugar de fingir que un simple reinicio revierte los datos.
Productos recomendados
Soporte y Consejos
Más para leer
Lista de verificación de migración de NFS para conjuntos de datos renombrados y controladores de archivo estables
Supón que los identificadores de archivo pueden cambiar cuando cambia la identidad del almacenamiento. Pon en pausa a los clientes, realiza deliberadamente la conmutación...
Guía de solución de problemas del cliente SMB para Windows, macOS y Linux
Usa el mismo servidor, cuenta, recurso compartido y operación de archivos en cada cliente para que los problemas de descubrimiento, credenciales, políticas y almacenamiento...
Lista de verificación para rotar secretos del servidor doméstico en aplicaciones, bases de datos y copias de seguridad
Trata la rotación como una migración de dependencias: identifica cada consumidor, mantén las credenciales superpuestas cuando sea posible, verifica el nuevo valor y, después,...
