Solucione el error de Zimbra "DB Error: DB Failure / Corruption" en los registros del buzón: Diagnóstico y recuperación seguros.

El mensaje “DB Error: DB Failure” en el registro de un buzón de Zimbra es un síntoma, no un diagnóstico. Puede indicar que la base de datos se ha detenido, que la conexión ha fallado, que se ha agotado el espacio en disco, que hay demasiadas conexiones o que la tabla o la base de datos InnoDB están dañadas. La solución segura depende de las líneas de registro circundantes y del servidor afectado. Comience con comprobaciones de solo lectura, proteja los datos y no ejecute un comando de reparación genérico solo porque aparezca la palabra “corrupción”.

Esta guía utiliza rutas y comandos comunes de Zimbra documentados en el Centro de soporte técnico de Zimbra. Algunas páginas wiki relacionadas están archivadas o incompletas, por lo que le recomendamos verificar cada comando y procedimiento de recuperación con su edición y versión exactas de Zimbra utilizando el índice de documentación oficial de Zimbra . Los ejemplos a continuación no presuponen una versión específica.

¿Qué significa realmente un fallo de la base de datos en mailbox.log?

La base de datos de buzones de Zimbra almacena metadatos de los buzones, como carpetas, etiquetas, estado de los mensajes y punteros a los archivos de mensajes. Los índices de búsqueda se almacenan por separado, y el contenido de los mensajes se almacena en el repositorio de mensajes. Por lo tanto, un error en la base de datos no implica automáticamente que todos los archivos de correo electrónico estén dañados. Tampoco un error de índice es prueba suficiente de que la base de datos esté dañada. Zimbra describe estos sistemas de almacenamiento separados en su documentación de referencia sobre la arquitectura del servidor .

La pista decisiva suele ser el error subyacente de la base de datos que aparece cerca de la excepción del buzón, especialmente en /opt/zimbra/log/mysql_error.log. Las notas de solución de problemas de Zimbra identifican mailbox.logy mysql_error.logcomo puntos de partida útiles, y zmmailboxd.outproporcionan detalles de inicio del servicio de buzón. Consulte la referencia de solución de problemas de registro de Zimbra .

¿Qué debes hacer antes de intentar una solución?

• Registre la hora de la primera ocurrencia, la zona horaria, el nombre de host del servidor, la cuenta o cuentas afectadas y la excepción completa, incluyendo las líneas adyacentes. Oculte las contraseñas, el contenido de los mensajes y los datos personales antes de compartir los registros.
• Determina el alcance: un buzón, varios buzones en un mismo almacén o usuarios en varios almacenes. Un síntoma en una sola cuenta no justifica el reinicio de la base de datos en todo el clúster.
• Verifique que exista una copia de seguridad reciente y utilizable e identifique el procedimiento de restauración específico de la versión. Si los errores se repiten o los usuarios se ven afectados, evite reiniciar y escribir repetidamente hasta que se comprenda el estado de la base de datos.
• Utilice una ventana de mantenimiento para las comprobaciones que analizan las tablas de la base de datos. Incluso una comprobación de integridad puede aumentar las operaciones de entrada/salida y ralentizar el servicio de correo electrónico.

¿Cómo se diagnostica de forma segura?

1. Compruebe el estado del servicio.

En el servidor de correo, cambie a la cuenta de Zimbra y verifique el estado del servicio. Ejecute los comandos con la cuenta que se muestra en cada solicitud; no pegue ningún símbolo de solicitud como $parte del comando.

su - zimbra
zmcontrol status

Compruebe si el buzón de correo está en funcionamiento y si el problema detectado es local en un servidor de buzones. Que el proceso del buzón esté detenido no es suficiente para concluir que la base de datos está dañada. La página de solución de problemas de buzones de Zimbra también incluye el estado del servicio y el inicio de sesión/configuración de la base de datos como comprobaciones independientes; dicha página está marcada como archivada, así que utilícela como referencia y siga la documentación correspondiente a su versión.

2. Comparar los registros del buzón de correo y de la base de datos al mismo tiempo.

Lea el mismo intervalo de tiempo en ambos registros. El primer error de la secuencia suele ser más útil que la línea final de "fallo del sistema".

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

Busque el mensaje subyacente de la base de datos, el nombre de la base de datos o del grupo de buzones, marcas de tiempo repetidas, fallos de inicio o un error del sistema operativo que coincida. Considere estas frases como pistas, no como soluciones automáticas:

3. Compruebe la capacidad del disco y los errores del sistema operativo.

Los volúmenes de datos o de registro llenos, los inodos agotados o los fallos de almacenamiento pueden simular un fallo de la base de datos. Ejecute comprobaciones no destructivas en el host de almacenamiento:

df -h /opt/zimbra
df -i /opt/zimbra

Compruebe el registro del sistema operativo o el registro del sistema en busca de errores de E/S de disco, del sistema de archivos o de falta de memoria en el mismo intervalo de tiempo. Si un volumen está lleno, libere o añada espacio siguiendo su procedimiento de almacenamiento habitual. No elimine archivos de base de datos, registros de InnoDB ni registros activos de Zimbra para liberar espacio; esto puede dificultar la recuperación o destruir pruebas.

4. Realice una comprobación de integridad solo después de revisar el impacto.

Si el servicio de base de datos de Zimbra es accesible y los registros no muestran ya un problema claro de conexión o almacenamiento, un administrador puede considerar el informe de integridad estándar durante una ventana de mantenimiento de bajo tráfico:

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

La documentación de Zimbra sobre informes de integridad describe esta acción como una comprobación de la base de datos y advierte que puede aumentar la E/S y la latencia del buzón. También documenta una -ropción para intentar la reparación automática de tablas. No la incluya -rcomo paso rutinario: la página está marcada como trabajo en progreso y la acción correcta depende del motor de la base de datos, el tipo de tabla, la versión del producto y el estado de la copia de seguridad. Un informe que solo menciona un mensaje conocido e inofensivo de bloqueo de la tabla de registro debe interpretarse según la nota de esa página; no trate todos los encabezados de "Errores de base de datos encontrados" como iguales.

¿Qué solución se ajusta a la evidencia?

• El servicio de base de datos se ha detenido, pero no se observan indicios de corrupción: primero, solucione el error específico de inicio, configuración, credenciales o recursos. Una vez corregido, utilice el procedimiento de recuperación del servicio correspondiente a su topología de lanzamiento e implementación. Evite reinicios a ciegas repetidos.
• Demasiadas conexiones: investigue la carga, los clientes bloqueados y la capacidad del servicio. No lo atribuya a corrupción de la base de datos ni copie una recomendación antigua para aumentar los límites sin consultar las directrices actuales de dimensionamiento y lanzamiento.
• Problema de disco o sistema de archivos: estabilice el almacenamiento y confirme que el sistema de archivos funciona correctamente. Si la base de datos registra errores de escritura o errores de InnoDB, considérelo como un posible incidente de integridad incluso después de que se haya restaurado el espacio.
• El informe de integridad marca las tablas: guarde la salida exacta, los nombres de las tablas/bases de datos, las marcas de tiempo y los registros relevantes. Realice una copia de seguridad o una instantánea del volumen de la base de datos mediante un método compatible antes de cualquier operación de escritura. Un administrador debe seguir el procedimiento de reparación o restauración compatible con el proveedor para la versión de Zimbra instalada.
• Una cuenta permanece afectada aunque el motor de la base de datos funcione correctamente: investigue por separado los metadatos del buzón, el almacén de mensajes o el índice. Evite editar manualmente las filas SQL o eliminar archivos para "reconstruir" la cuenta.

Ante la sospecha de corrupción de InnoDB, la reparación más segura suele ser una recuperación específica de la versión a partir de una copia de seguridad verificada o una recuperación guiada por el soporte técnico, no una REPAIR TABLEreinicialización genérica de la base de datos ni una secuencia de comandos copiada. Algunos artículos antiguos de la wiki de Zimbra sobre recuperación incluyen pasos destructivos y están archivados explícitamente; no los aplique a un sistema actual sin la confirmación directa del soporte técnico de Zimbra y una copia de seguridad probada.

¿Cómo puede confirmar que el problema se ha resuelto?

Tras la acción correctiva aprobada, confirme que los servicios de base de datos y buzón de correo siguen activos, que las nuevas entradas ya no muestran el mismo error subyacente en la base de datos y que la cuenta afectada puede realizar operaciones de correo habituales. Vuelva a ejecutar el informe de integridad estándar solo si corresponde a su ventana de carga y versión. Confirme que la copia de seguridad se completa y conserve los registros y el registro de reparación. Si el problema se repite, informe a su administrador o al canal de soporte de Zimbra la versión/compilación exacta de Zimbra, la configuración de servidor único o multiservidor, el alcance del buzón, la hora del primer fallo, los extractos de registro relevantes, el estado del disco, el resultado del informe de integridad y la marca de tiempo de la copia de seguridad.

Punto clave: antes de modificar los datos, diagnostique el error de la base de datos que origina la excepción del buzón. El simple mensaje "Fallo de la base de datos" no permite determinar si la solución consiste en una corrección de credenciales, un cambio de capacidad, una reparación del almacenamiento o una recuperación de la base de datos.

Referencias principales: Índice de la documentación de Zimbra ; Arquitectura del servidor Zimbra ; Solución de problemas de registros de Zimbra ; Referencia del informe de integridad de la base de datos de Zimbra ; Referencia del error 1040 de Zimbra MySQL ; y Referencia de solución de problemas de buzones de correo de Zimbra . Algunas páginas del Centro Tecnológico están archivadas o marcadas como en desarrollo, como se indica en el artículo.