[HOW-TO] Exchange Server | Remediar Copia de Base de Datos “Failed and Suspended” en un DAG de Exchange 2010

A veces nos encontramos ante el incidente en una copia de una base de datos en un DAG de Exchange Server: uno de los nodos se encuentra con el estado de base de datos “Failed and Suspended”.

En este “How-To”vamos a analizar una posible remediación de este estado, a través del borrado de logs en la base de datos duplicada y su re-sincronización a través de Exchange.

En el presente artículo se expone: la bitácora, el análisis, diagnóstico y solución ejecutada.

[toc]

Introducción

Objetivo

Esta publicación tiene como objetivo mostrar cómo remediar un error puntual de copia de base de datos “”Failed and Suspended” en un DAG de Exchange Server 2010

Alcance

El objetivo técnico de esta publicación es mostrar paso a paso cómo hacer para remediar y solucionar el error “Failed and Suspended” en un DAG de Exchange Server 2010, de modo tal de dejar el estado de copias y replicación sanas.

De esta manera, el incidente detectado se considera remediado / solucionado cuando:

• Se dejan de encontrar bases de datos en estado “Failed and Suspended”.
• Las bases de datos se encuentran replicadas

Esta publicación puede aplicarse a:

• Exchange Server 2010.
• Database Availability Group en Exchange Server.

Escenario de Trabajo

Contamos con una plataforma Exchange Server 2010 con SP2 instalado en un dominio de Active Directory single forest / domain. Existen los siguientes equipos:

• PEX01: Client Access y Hub Transport.
• PEXMB01: Database.
• PEXMB02: Database.

En un control de operaciones diarias proactivas, se encontró una de las bases de datos del DAG con estado “Failed and Suspended” en uno de los nodos, mientas que en otro estaba operativa:

Debido a este error, los usuarios no tuvieron corte de servicio, razón por la cual no fue detectado reactivamente.

Desarrollo de la Solución

Análisis

Se realizó el siguiente análisis:

• Los usuarios tienen servicio, por lo cual no se registra disrupción del mismo.
• Resultado del comando Get-MailboxDatabaseCopyStatus –Identity “Database”:

• Como las restantes bases no tenían este error, se procedió a no realizar pruebas de conectividad entre nodos.
• Se revisó el Event Viewer de ambos nodos, y se encontró los siguientes eventos significativos:

Y el más importante:

• Se procedió a intentar continuar la replicación, a través del comando Resume-MailboxDatabaseCopy -Identity Database \Server sin resultados positivos.

Diagnóstico

Según los eventos encontrados y el análisis realizado, la base de datos copia tiene logs inconsistentes, razón por la cual no es consistente y fue suspendida del DAG. Esto se evidencia a través del mensaje encontrado en el Event Viewer “The required log 1 for xxxxxx\PEXMB01 is missing on the active copy…”.

Solución Ejecutada

Para solucionar el problema, si bien no es el objetivo inmediato buscar la causa raíz, realizamos el siguiente Workaround:

• Actualización de la base de datos copia: borrando logs existentes en la misma (re-sincronización completa) desde la base de datos activa.
• Comprobación del estado de la base de datos post-update
• Remediación del Catálgo de Contenido

Actualización de la base de datos copia

Desde el Shell de Exchange, ejecutamos el siguiente comando:

Update-MailboxDAtabaseCopy –DeleteExistingFiles –Identity “Database\PEXMB01”

De esta forma, estamos forzando la actualización de la base de datos “copia” borrando cualquier log existente en el nodo fallido. Podemos observar, mediante el comando “Get-MailboxDatabaseCopyStatus –Identity “Database” que el sistema nos indica que está en proceso “Seeding”:

Comprobación del estado de la base de datos post-update

Luego de unos minutos, vemos que el proceso finalizó:

Sin embargo, podemos observar que el “ContentIndexState” no está saludable.

Remediación del Catálgo de Contenido

Por este motivo, realizamos el siguiente update de base SOLO del catálogo:

Update-MailboxDatabaseCopy –Identity “Database\PEXMB01” –CatalogOnly

El resultado es el siguiente:

Como el error nos indica, vamos a revisar en el nodo PEXMB02 que el servicio “Microsoft Exchange Search” esté corriendo y lo iniciamos.

Corremos nuevamente el CMDLet “Update-MailboxDatabaseCopy –Identity “Database\PEXMB01” –CatalogOnly” y revisamos el estado de la base:

Conclusiones

A través del Workaround aplicado, se logró la remediación del estado suspendido de la copia de la base de datos que tenía asociado el incidente. De esta forma, la base de datos nuevamente quedó en línea y lista para asumir el rol de activa ante alguna eventualidad en su contraparte.

El origen del problema pudo ser detectado gracias a la aplicación de la metodología de documentación, análisis y diagnóstico ante un Incidente.

Comentarios y Corrección de Errores

Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.

Acerca del Autor