El modo de Coordinación de Activación del Centro de Datos (DAC) es una propiedad de un Grupo de Disponibilidad de Base de Datos (DAG). Este modo se utiliza para controlar el montaje de la base de datos en el comportamiento de arranque del Grupo de Disponibilidad de Base de Datos (DAG). La característica está diseñada para evitar que se produzca la división del cerebro a nivel de base de datos cuando se produce una conmutación.
¿Qué es un cerebro dividido? Un cerebro dividido, también conocido como síndrome del cerebro dividido, es una situación en la que una base de datos de buzón de correo se establece como copia activa de dos miembros del grupo de disponibilidad de bases de datos. Esto provoca problemas de comunicación entre los dos servidores y bases de datos.
Para evitar un cerebro dividido, puede activar el modo de coordinación de activación del centro de datos (DAC), ya que requiere permiso para montar la base de datos de los miembros del grupo de disponibilidad de bases de datos (DAG) antes de la activación. Piense en ello como una opción a prueba de fallos.
¿Cómo comprobar y activar el modo DAC?
Cuando se activa el modo de coordinación de activación del centro de datos (DAC), además de evitar que su clúster tenga una situación de cerebro dividido, también activa nuevos cmdlets, incluidos Stop-DatabaseAvailabilityGroup, Start-DatabaseAvailabilityGroup y Restore-DatabaseAvailabilityGroup. Estos comandos resultan muy útiles durante la conmutación del centro de datos.
Para confirmar si el modo DAC está activo o no, puede utilizar el comando Get-DatabaseAvailabilityGroup con los siguientes parámetros para obtener la información.
Get-DatabaseAvailabilityGroup | Select Name,Servers,DatacenterActivationMode
Si no se ha activado, la salida aparecerá como “desactivada”.
Para habilitar el modo DAC, debe utilizar el cmdlet Set-DatabaseAvailabilitGroup como se indica a continuación. Set-DatabaseAvailabilityGroup servername -DatacenterActivationMode DagOnly /servername
Una vez completado esto, el DataCenterActivationMode cambiará a DagOnly.
Aspectos a tener en cuenta antes de activar el modo DAC
El modo DAC está desactivado por defecto cuando se configura un Exchange Server de alta disponibilidad. Debe habilitarse para todos los grupos de disponibilidad de bases de datos que tengan dos o más miembros configurados para utilizar la replicación continua.
Si tiene instalado software o hardware de replicación de terceros, se recomienda no activar esta función. Esto también se aplica al modo de replicación de terceros. Tampoco es compatible si su DAG sólo tiene un miembro en el clúster.
Otra cosa a tener en cuenta es que el modo DAC puede habilitarse en cualquier Grupo de Disponibilidad de Bases de Datos que exista dentro de una única ubicación de centro de datos, aunque no es probable que se produzca un split-brain. Se recomienda habilitarlo ya que aún existe la posibilidad de que esto ocurra. El cerebro dividido puede ocurrir fácilmente cuando se tiene una configuración multi-sitio donde un Exchange Server está en el sitio principal y los otros en una ubicación geográfica diferente para la recuperación de desastres y la continuidad del negocio. Esto puede ocurrir debido a latencia, desconexiones o incluso una configuración incorrecta entre los sitios.
Es importante saber estas cosas, ya que podría haber problemas si no está bien configurado o configurado con una configuración no compatible. No le gustará enfrentarse a una caída de la configuración con registros de transacciones de Exchange dañados o desajustes en la base de datos entre el sitio y la pérdida de datos. Si hay dos bases de datos activas, tendrá problemas con la replicación e incluso con la integridad de los datos.
¿Qué hacer si se produce una escisión cerebral?
Si se produce el proceso de split-brain, ambos servidores pensarán que son servidores activos. Esto causará estragos en los datos del sitio y provocaría la corrupción de la base de datos Exchange o incluso daños en las bases de datos o registros.
En tales casos, acabaría restaurando los servidores desde la copia de seguridad, ya que resolver el asunto puede llevar un buen número de horas. La restauración a partir de la copia de seguridad provocaría la pérdida de datos, dependiendo de la hora del día en que esto ocurra. Tener bases de datos o registros de transacciones corruptos no es agradable porque las bases de datos no se montarán.
Puede utilizar ESEUtil para realizar una recuperación rápida o una recuperación dura para solucionar el problema. Sin embargo, no se recomienda la recuperación dura, ya que borrará cualquier dato que se considere dañado. Después de todo este calvario, no hay garantía de que la base de datos se monte.
Una solución alternativa
Las aplicaciones de recuperación de Exchange de terceros, como Stellar Repair for Exchange, pueden ser útiles en estas situaciones. Stellar Repair for Exchange puede abrir varias bases de datos de Exchange Server de cualquier versión y en cualquier estado. Puede navegar por el almacén de datos y exportar a PST y otros formatos de archivo. En caso de que la base de datos de Exchange no esté montada, puede crear fácilmente una nueva base de datos y exportar directamente desde la base de datos dañada a la nueva. También puede exportar directamente a un inquilino de Office 365. Cuenta con asignación automática o manual de buzones, recuperación paralela de buzones, exportaciones con prioridad VIP y continuación en caso de que el proceso se interrumpa. Esto reducirá al mínimo el coste y el tiempo de recuperación.
Was this article helpful?
