Recuperación ante desastres de WSFC mediante quórum forzado (SQL Server)

Se aplica a:SQL Server

El error de quórum se produce normalmente por un desastre sistémico, un error de comunicaciones persistente o una configuración incorrecta que afecta a varios nodos del clúster WSFC. Es necesaria la intervención manual para la recuperación de un error de quórum.

Requisitos previos

El procedimiento de quórum forzado presupone que existía un quórum en estado correcto antes de que se produjera el error.

Advertencia

El usuario debe conocer perfectamente los conceptos y las interacciones de los clústeres de conmutación por error de Windows Server, los modelos de quórum de WSFC, SQL Servery la configuración de implementación específica del entorno.

Para obtener más información, consulte: Clúster de conmutación por error de Windows Server (WSFC) con SQL Server, Modos de cuórum y configuración de votación de WSFC (SQL Server)

Seguridad

El usuario debe ser una cuenta de dominio que pertenezca al grupo local Administradores en cada nodo del clúster de WSFC.

Recuperación ante desastres de WSFC con el procedimiento de quórum forzado

Recuerde que el error de quórum provocará que todos los servicios de clúster, instancias de SQL Server y Grupos de disponibilidad AlwaysOndel clúster WSFC se pongan sin conexión porque el clúster, tal y como está configurado, no puede asegurar la tolerancia a errores de nivel de nodo. Un error de cuórum significa que los nodos de votación en buen estado del clúster WSFC ya no satisfacen el modelo de cuórum. Puede que algunos nodos hayan fallado por completo, y puede que otros simplemente hayan detenido el servicio WSFC y, por lo demás, estén en buen estado, salvo por la pérdida de la capacidad de comunicarse con el cuórum.

Para poner de nuevo en línea el clúster WSFC, debe corregir la causa principal del error de quórum en virtud de la configuración existente, recuperar las bases de datos afectadas según sea necesario y puede volver a configurar los nodos restantes del clúster WSFC para reflejar la topología de clúster superviviente.

Puede usar el procedimiento quórum forzado en un nodo del clúster WSFC para invalidar los controles de seguridad que pusieron el clúster fuera de conexión. Esto indica al clúster de forma eficaz que suspenda las comprobaciones de votación de quórum y le permite poner de nuevo en línea los recursos del clúster WSFC y SQL Server en cualquiera de los nodos del clúster.

Este tipo de proceso de recuperación de desastres debe incluir los siguientes pasos:

Para recuperarse de un fallo de quórum:

  1. Determinar el ámbito del error. Identifique los grupos de disponibilidad o las instancias de SQL Server que no responden, los nodos de clúster que están en línea y disponibles para uso después de los desastres, y examine los registros de eventos de Windows y los registros del sistema de SQL Server. Cuando sea posible, debería conservar los datos forenses y los registros del sistema para su posterior análisis.

    Sugerencia

    En una instancia de SQL Server con capacidad de respuesta, puede obtener información sobre el estado de los grupos de disponibilidad que tienen una réplica de disponibilidad en la instancia de servidor local mediante una consulta a la vista de administración dinámica (DMV) sys.dm_hadr_availability_group_states.

  2. Iniciar el clúster WSFC mediante quórum forzado en un único nodo. Identifique un nodo con un número mínimo de fallos de componentes, aparte de que se haya detenido el servicio de clúster de WSFC. Compruebe que este nodo puede comunicarse con una mayoría de los demás nodos.

    En este nodo, fuerce manualmente el clúster para ponerlo en línea mediante el procedimiento de quórum forzado. Para minimizar la posible pérdida de datos, seleccione un nodo que alojó por última vez una réplica principal de un grupo de disponibilidad.

    Para más información, vea: Forzar el inicio de un clúster WSFC sin un quórum

    Nota

    La configuración de quórum forzado afecta a todo el clúster, ya que bloquea las comprobaciones de quórum hasta que el clúster lógico de WSFC logra una mayoría de votos y pasa automáticamente a un modo de funcionamiento de quórum normal.

  3. Inicie el servicio WSFC normalmente en cada nodo que, por lo demás, esté en buen estado, uno a la vez. No tiene que especificar la opción de quórum forzado cuando inicia el servicio de clúster de los demás nodos.

    Mientras el servicio del clúster WSFC en cada nodo vuelve a estar en línea, negocia con los otros nodos en buen estado para sincronizar el nuevo estado de configuración del clúster. Recuerde realizar esta operación en un solo nodo cada vez para evitar posibles condiciones de carrera al determinar el último estado conocido del clúster.

    Advertencia

    Asegúrese de que cada nodo que inicia puede comunicarse con los demás nodos recientemente en línea. Considere deshabilitar el servicio WSFC en los demás nodos. De lo contrario, corre el riesgo de crear más de un conjunto de nodos de cuórum; esto es un escenario de división de cerebro. Si los resultados del paso 1 son precisos, esto no debe suceder.

  4. Aplicar una nueva configuración al modo de quórum y voto de nodo. Si al forzar el quórum se reiniciaron correctamente todos los nodos del clúster y la causa del error de quórum se ha corregido, no es necesario realizar cambios en el modo de quórum original y la configuración de voto de nodo.

    De lo contrario, debe evaluar el nodo de clúster recién recuperado y la disponibilidad de la topología de réplica, así como cambiar el modo de quórum y las asignaciones de votos para cada nodo según corresponda. Los nodos no recuperados deben estar establecidos como sin conexión o tener sus votos de nodo establecidos en cero.

    Sugerencia

    En este punto, puede parecer que los nodos y las instancias de SQL Server del clúster se han restablecido a un funcionamiento normal. Sin embargo, puede que aún no exista un quórum en buen estado. Mediante el Administrador de clústeres de conmutación por error, el panel de Always On de SQL Server Management Studio o las DMV adecuadas, compruebe que se ha restablecido el cuórum.

  5. Restaurar las réplicas de bases de datos del grupo de disponibilidad según sea necesario. Las bases de datos del grupo sin disponibilidad deben recuperarse y volver a ponerse en línea por sí mismas como parte del proceso normal de inicio de SQL Server.

    Puede minimizar la posible pérdida de datos y tiempo de recuperación de las réplicas del grupo de disponibilidad poniéndolas en línea de nuevo con esta secuencia: réplica principal, réplicas secundarias sincrónicas, réplicas secundarias asincrónicas.

Nota

Después de usar el cuórum forzado, es necesario realizar una conmutación por error forzada con posible pérdida de datos para volver a poner el grupo de disponibilidad en línea. Para obtener más información, consulte Realizar una conmutación por error manual forzada de un grupo de disponibilidad (SQL Server).

  1. Reparar o reemplazar componentes con errores y volver a validar el clúster. Ahora que se haya recuperado del desastre inicial y del error de quórum, debe reparar o reemplazar los nodos que han fallado y ajustar las configuraciones correspondientes de WSFC y Always On según corresponda. Esto puede incluir eliminar las réplicas del grupo de disponibilidad, expulsar nodos del clúster o reformatear y volver a instalar el software en un nodo.

    Debe reparar o quitar todas las réplicas de disponibilidad con errores. SQL Server no truncará el registro de transacciones más allá del último punto conocido de la réplica de disponibilidad más retrasada. Si una réplica con errores no se repara o se quita del grupo de disponibilidad, los registros de transacciones crecerán y se correrá el riesgo de quedarse sin espacio para los registros de transacciones en las otras réplicas.

    Nota

    Si ejecuta el Asistente para validar una configuración de WSFC cuando hay un agente de escucha de un grupo de disponibilidad en el clúster de WSFC, el asistente genera el siguiente mensaje de advertencia incorrecto:

    "La propiedad RegisterAllProviderIP para el nombre de red 'Name:<nombre_red>' está establecida en 1. Para la configuración de clúster actual, este valor debería estar establecido en 0".

    Omita este mensaje.

  2. Repetir el paso 4 según sea necesario. El objetivo es volver a establecer el nivel adecuado de tolerancia a errores y la alta disponibilidad para las operaciones en buen estado.

  3. Realizar un análisis de RPO/RTO. Debe analizar los registros del sistema de SQL Server, las marcas de tiempo de la base de datos y los registros de eventos de Windows para determinar la causa principal del error, así como para documentar las experiencias reales del punto de recuperación y del tiempo de recuperación.

Tareas relacionadas

Contenido relacionado

Consulte también

Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server

  • Last updated on