¿Cuáles son las señales de advertencia de que un contenedor de base de datos se corrompió debido a un corte de energía?
Sospecha que hay corrupción cuando la base de datos no puede completar la recuperación normal tras un fallo o informa después de inconsistencias en las sumas de comprobación, páginas, secuencias de registro, tablas o índices.
Un apagado incorrecto no significa automáticamente que la base de datos esté dañada; PostgreSQL, MySQL, MariaDB y otros motores similares utilizan diarios o registros de escritura anticipada específicamente para recuperar el estado confirmado. La señal de advertencia aparece cuando la recuperación se repite, el motor se cierra, la misma consulta encuentra páginas no válidas, fallan las sumas de comprobación, desaparecen tablas, los índices contradicen los datos de las tablas o las copias de seguridad y las comprobaciones de integridad no pueden leer el clúster de forma coherente.
Distingue la recuperación normal tras un fallo de un bucle de recuperación
Conserva el primer registro de inicio después de que vuelva la alimentación. Anota si el motor reproduce los registros una sola vez y queda listo, o si se reinicia repetidamente, entra en recuperación forzada o se detiene en el mismo registro o página.
InnoDB puede informar de la restauración de posibles páginas escritas parcialmente tras una escritura interrumpida; el mensaje indica que el motor está intentando realizar una recuperación segura tras un fallo, pero los errores repetidos pueden apuntar a errores de InnoDB posteriores a un corte de electricidad.
Una única recuperación correcta seguida de comprobaciones normales no demuestra que haya corrupción. Un bucle, una afirmación fatal, una señal repetida o la imposibilidad de alcanzar el estado listo son señales para detenerse, copiar los archivos sin procesar y probar las copias de seguridad antes de que se produzcan más escrituras.
Busca errores de suma de comprobación y de páginas no válidas
Busca en los registros mensajes como discrepancia de suma de comprobación, fallo en la verificación de página, página no válida en el bloque, página dañada, lectura corta, número mágico incorrecto o fin de archivo inesperado. Anota la relación, tabla, bloque o espacio de tablas mencionado.
pganalyze muestra que la corrupción de PostgreSQL aparece como fallos en la suma de comprobación de páginas, seguidos de un error de página no válida cuando se lee el bloque dañado.
No silencies el error ni pongas a cero las páginas dañadas antes de conservar las pruebas y confirmar la cobertura de las copias de seguridad. Que el mismo bloque falle en varios reinicios es una evidencia más sólida que un tiempo de espera puntual de la aplicación.
Observa si las consultas fallan solo con filas o tablas específicas
Ejecuta comprobaciones de solo lectura en las tablas y consultas que la aplicación utiliza normalmente. La corrupción puede permanecer oculta hasta que un escaneo, una limpieza, una copia de seguridad o una solicitud acceda a una página dañada.
Un análisis de PostgreSQL explica que una discrepancia de suma de comprobación apunta hacia un problema por debajo de la base de datos, mientras que una página no válida sin una advertencia de suma de comprobación aún puede reflejar daños en el almacenamiento, la memoria, el sistema de archivos o los archivos. El síntoma práctico es una lectura de página no válida que se repite durante las consultas habituales.
Registra exactamente qué consulta y objeto fallan. No permitas que la aplicación continúe realizando escrituras generales mientras solo una parte de la base de datos siga siendo legible, porque el nuevo estado puede complicar la recuperación y las copias de seguridad.
Comprueba las inconsistencias en índices, transacciones y metadatos
Entre las señales de advertencia se incluyen claves duplicadas que infringen un índice único, filas ausentes a las que se puede acceder mediante una ruta pero no mediante otra, identificadores de transacción no válidos, fragmentos TOAST o de valores grandes dañados e índices que no superan la validación.
La revisión de credativ sobre la corrupción señala que los clústeres sin sumas de comprobación de datos pueden revelar daños mediante errores de bajo nivel, como páginas no válidas, problemas con los identificadores de transacción, inconsistencias de TOAST o bloqueos del backend. Algunas copias de seguridad realizadas copiando archivos pueden conservar páginas dañadas sin detectarlas.
Ejecuta comprobaciones de integridad e índices compatibles en una copia o durante una ventana de mantenimiento controlada. Volver a crear un índice puede reparar un índice derivado dañado, pero no repara los datos corruptos de las tablas ni el almacenamiento subyacente.
Relaciona los errores de la base de datos con las advertencias del sistema de archivos y el almacenamiento
Inspecciona los registros del núcleo del sistema, del sistema de archivos, del conjunto de almacenamiento, de las unidades, del controlador, del SAI y del entorno de ejecución de contenedores en torno al apagón. Busca errores de E/S, restablecimientos, errores de suma de comprobación, remontajes en modo de solo lectura, conjuntos degradados y archivos perdidos o truncados.
Una guía de recuperación de bases de datos señala que los cortes de electricidad y la memoria defectuosa pueden producir escrituras de páginas dañadas, especialmente cuando el comportamiento del almacenamiento no coincide con las suposiciones de durabilidad de la base de datos. Estos eventos a nivel del sistema ayudan a distinguir la corrupción de páginas de InnoDB de un reinicio normal de la aplicación.
Repara la ruta de almacenamiento antes de restaurar en ella una base de datos limpia. Una restauración lógica correcta en un medio defectuoso puede reproducir el incidente o dañar silenciosamente el reemplazo.
Detén las escrituras y demuestra la recuperación desde una copia de seguridad limpia
Cuando las señales de corrupción se repitan, detén las aplicaciones dependientes, crea una instantánea o clona el volumen afectado si es seguro hacerlo y conserva los registros y la configuración. Prueba la copia de seguridad más reciente en un almacenamiento independiente antes de modificar el clúster original.
La lista de comprobación de ZimaSpace para realizar copias de seguridad del estado de las aplicaciones de Docker define qué debe existir antes de intentar una recuperación destructiva de la base de datos.
El sistema solo es fiable cuando la base de datos restaurada se inicia correctamente, las comprobaciones de integridad se superan, las consultas y escrituras representativas funcionan, las copias de seguridad se completan y el almacenamiento del sistema no informa de nuevos errores. Los modos de recuperación forzada deben utilizarse para rescatar datos conforme a un plan de recuperación documentado, no como funcionamiento normal.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
