Solución:
Los AG se basan en la agrupación en clústeres de Windows. Se aplican los procedimientos de WSFC para la pérdida de quórum.
- Recuperación ante desastres de WSFC mediante quórum forzado
- Forzar el inicio de un clúster WSFC sin quórum
Una vez que el WSFC se está ejecutando, puede forzar AG, si es necesario. Realice una conmutación por error manual forzada de un grupo de disponibilidad:
Después de forzar el quórum en el clúster WSFC (quórum forzado), debe forzar la conmutación por error de cada grupo de disponibilidad (con posible pérdida de datos). Es necesario forzar la conmutación por error porque es posible que se haya perdido el estado real de los valores del clúster WSFC. Sin embargo, puede evitar la pérdida de datos si puede forzar la conmutación por error en la instancia del servidor que hospedaba la réplica que era la réplica principal antes de forzar el quórum o en una réplica secundaria que se sincronizó antes de forzar el quórum. Para obtener más información, consulte Posibles formas de evitar la pérdida de datos después de forzar el quórum.
¿Qué hacer cuando su clúster AlwaysOn pierde quórum?
He estado en esta situación, especialmente con la agrupación en clústeres de varias subredes que abarcan diferentes países (NY-LD-HK).
¿Cómo evitar la pérdida de quórum en un clúster de varias subredes?
- Cambie la configuración predeterminada del clúster a un estado de supervisión más relajado, especialmente la configuración de latido del clúster mediante
CrossSubnetDelay, oCrossSubnetThresholdpropiedad por esta revisión. - AG usa WSFC, que a su vez usa un enfoque basado en quórum para determinar el estado del clúster. Asegúrese de elegir y configurar correctamente el quórum. Esta publicación de blog profundiza en la configuración de votos de quórum para AlwaysON
-
Las cosas cambian en Windows Server 2016 con la introducción de clústeres con reconocimiento de sitios y testigos en la nube.
Los nodos en clústeres extendidos ahora se pueden agrupar en función de su ubicación física (sitio). El conocimiento del sitio del clúster mejora las operaciones clave durante el ciclo de vida del clúster, como el comportamiento de la conmutación por error, las políticas de ubicación, el pulso entre los nodos y el comportamiento del quórum.
Testigo de la nube es un nuevo tipo de clúster de conmutación por error testigo de quórum que aprovecha Microsoft Azure como punto de arbitraje. Utiliza Microsoft Azure Blob Storage para leer / escribir un archivo de blob que luego se usa como punto de arbitraje en caso de resolución de cerebro dividido.
¿Qué hacer cuando se pierde el quórum?
- Si el clúster deja de funcionar debido a una interrupción o un desastre no planificado, se requiere la intervención manual. Un administrador de Windows o un administrador de clúster tiene que forzar manualmente el quórum (enlazando de nuevo a la respuesta de @ Remus ya que cubre este punto) y conecte los nodos supervivientes.
Como siempre, para hacer un análisis de causa raíz (RCA), recopile los registros del clúster de Windows, para AlwaysON RCA: use los registros de diagnóstico del clúster de conmutación por error de SQL Server. Estos archivos en el directorio de registro de SQL Server tienen el siguiente formato: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.