Resolución de problemas de base de datos de disponibilidad AlwaysOn en estado de recuperación o sospechoso en SQL Server

  • 08/03/2020
  • 12 minutos de lectura
    • r
    • o

Este artículo describe los errores y limitaciones de una base de datos de disponibilidad en Microsoft SQL Server, al Recovery Pending Estado o y Suspect restauración de la base de datos a la funcionalidad completa en un grupo de disponibilidad.

Versión original del producto: SQL Server 2012
Número inicial de la base de conocimientos: 2857849

Resumen

Supongamos que una base de datos de disponibilidad definida en un grupo de disponibilidad AlwaysOn pasa a un Recovery PendingSuspect Estado o en SQL Server. Si esto ocurre en la réplica primaria del grupo de disponibilidad, la disponibilidad de la base de datos se ve afectada. En este caso, no se puede acceder a la base de datos a través de las aplicaciones cliente. Además, no puede eliminar la base de datos del grupo de disponibilidad ni borrarla.

Por ejemplo, suponga que SQL Server se está ejecutando y que una base de datos de disponibilidad está configurada en el Recovery PendingSuspect Estado o. Al consultar las vistas de gestión dinámicas (DMV) en la réplica principal mediante el siguiente script SQL. la base de datos puede informarse en el estado NOT_HEALTHY y en el estado RECOVERY_PENDING o en un estado SUSPECT de la siguiente manera:

SELECT dc.database_name, d.synchronization_health_desc, d.synchronization_state_desc, d.database_state_descFrom sys.dm_hadr_database_replica_states d JOIN sys.availability_databases_cluster dc ON d.group_database_id = dc.group_database_id AND d.is_local = 1
database_name synchronization_health_desc synchronization_state_desc database_state_desc-------------------- ------------------------------ ------------------------------ ---------------------<DatabaseName> NOT_HEALTHY NOT SYNCHRONIZING RECOVERY_PENDING(1 row(s) affected)

Captura de pantalla del resultado de la ejecución del script para comprobar el estado de la sincronización e integridad de la base de datos.

Además, esta base de datos puede ser marcada como en estado de no sincronización/recuperación pendiente o sospechosa en SQL Server Management Studio.

Captura de pantalla de la base de datos que no está en estado de sincronización/recuperación.

Cuando la base de datos está definida en un grupo de disponibilidad, la base de datos no puede ser eliminada ni restaurada. Por lo tanto, debe tomar medidas específicas para recuperar la base de datos y devolverla al uso en producción.

Más información

El siguiente contenido analiza los errores y las limitaciones de una base de datos de disponibilidad que se encuentra en un estado de recuperación pendiente en varias situaciones.

  • El estado de la base de datos impide su restauración.

    Intentas ejecutar el siguiente script SQL para restaurar la base de datos que contiene el parámetro RECOVERY:

    RESTORE DATABASE <DatabaseName> WITH RECOVERY

    Cuando ejecutas este script, recibes el siguiente mensaje de error porque la base de datos está configurada en un grupo de disponibilidad:

    MSG 3104, nivel 16, estado 1, línea 1
    La restauración no puede funcionar en el servidor de la base de datos, porque está configurado para la duplicación de la base de datos o está unido a un grupo de disponibilidad . Si tiene intención de restaurar la base de datos, utilice ALTER DATABASE para eliminar la réplica o para eliminar la base de datos de su grupo de disponibilidad.

    MSG 3013, nivel 16, estado 1, línea 1
    La restauración de la base de datos finaliza de forma anormal.

  • El estado de la base de datos impide el borrado de la misma

    Intentas ejecutar el siguiente script SQL para borrar la base de datos:

DROP DATABASE <DatabaseName>

Cuando se ejecuta este script, se recibe el siguiente mensaje de error porque la base de datos está definida en un grupo de disponibilidad:

MSG 3752, nivel 16, estado 1, línea 1
La base de datos DatabaseName está actualmente unida a un grupo de disponibilidad. Antes de poder eliminar la base de datos, debe eliminarla del grupo de disponibilidad.

El estado de la base de datos impide que se elimine la base de datos

Intenta ejecutar el siguiente script SQL para eliminar la base de datos del grupo de disponibilidad:

ALTER DATABASE <DatabaseName> SET hadr OFF

Cuando se intenta ejecutar este script, se recibe el siguiente mensaje de error, porque la base de datos de disponibilidad pertenece a la réplica principal:

MSG 35240, nivel 16, estado 14, línea 1
No se puede unir o desunir la base de datos AvailabilityGroupName. Esta operación no se admite en la réplica principal de AvailabilityGroup.

Debido a este mensaje de error, es posible que se vea obligado a realizar una conmutación por error de la base de datos. Una vez que la base de datos se conmuta, la réplica que tiene la base de datos de recuperación pendiente está en el papel secundario. En este caso, se intenta ejecutar de nuevo el siguiente script SQL para eliminar la base de datos del grupo de disponibilidad de la réplica secundaria:

ALTER DATABASE <DatabaseName> SET hadr OFF

Sin embargo, sigue sin poder eliminar la base de datos del grupo de disponibilidad y se muestra el siguiente mensaje de error porque la base de datos sigue en estado de recuperación:

MSG 921, nivel 16, estado 112, línea 1
La base de datos DatabaseName aún no se ha recuperado. Espere y vuelva a intentarlo.

Resolución cuando la base de datos está en el rol secundario

Para resolver este problema, haga lo siguiente:

  • Quite la réplica que aloja la base de datos dañada del grupo de disponibilidad cuando la base de datos está en el rol secundario.
  • Resolver cualquier problema que afecte al sistema y que pueda haber contribuido al fallo de la base de datos.
  • Restaurar la réplica al grupo de disponibilidad.

Para realizar estas acciones, inicie sesión en la nueva réplica primaria y, a continuación, ejecute la secuencia de comandos ALTER AVAILABILITY GROUP SQL para eliminar la réplica que aloja la base de datos de disponibilidad que ha fallado. Para ello, haga lo siguiente.

Estos pasos suponen que la réplica primaria aloja la base de datos que ha fallado. Por lo tanto, primero debe producirse una conmutación por error para hacer la transición de la réplica que aloja la base de datos dañada a un rol secundario.

  1. Conéctese al servidor que ejecuta SQL Server y aloja la réplica secundaria.

  2. Ejecute la siguiente secuencia de comandos SQL:

    ALTER AVAILABILITY GROUP <AvailabilityGroupName> FAILOVER
  3. Ejecute la siguiente secuencia de comandos SQL para eliminar la réplica que aloja la base de datos dañada del grupo de disponibilidad:

    ALTER AVAILABILITY GROUP AvailabilityGroupName REMOVE REPLICA ON '<SQLServerNodeName>'
  4. Resolver los problemas en el servidor que ejecuta SQL Server que pueden estar contribuyendo a un fallo de la base de datos.

  5. Agregar la réplica al grupo de disponibilidad.

    1. Resolver cuando la réplica primaria es la única réplica en el grupo de disponibilidad

      Si la réplica primaria aloja la base de datos dañada y es la única réplica operativa en el grupo de disponibilidad, el grupo de disponibilidad debe abandonarse. Una vez eliminado el grupo de disponibilidad, su base de datos puede recuperarse a partir de una copia de seguridad o pueden aplicarse otros esfuerzos de recuperación de desastres para restaurar las bases de datos y reanudar la producción.

      Para eliminar el grupo de disponibilidad, utilice el siguiente script SQL:

      DROP AVAILABILITY GROUP <AvailabilityGroupName>

      En este punto, puede intentar recuperar la base de datos problemática. También puede restaurar la base de datos a partir de la última copia de seguridad buena conocida.

      Resolución al eliminar el grupo de disponibilidad

      Cuando se elimina un grupo de disponibilidad, el recurso de escucha también se elimina e interrumpe la conectividad de la aplicación con las bases de datos de disponibilidad.

      Para reducir el tiempo de inactividad de la aplicación, utilice uno de los siguientes métodos para mantener la conectividad de la aplicación a través del listener y eliminar el grupo de disponibilidad:

      Método 1: Asociar el listener con un nuevo grupo de disponibilidad (rol) en el Failover Cluster Manager

      Este método permite mantener el listener mientras se elimina y se vuelve a crear el grupo de disponibilidad

      1. En la instancia de SQL Server a la que el listener del grupo de disponibilidad existente dirige las conexiones, cree un grupo de disponibilidad vacío. Para simplificar este proceso, utilice el comando Transact-SQL para crear un grupo de disponibilidad que no tenga una réplica o una base de datos secundaria:

        USE masterGOCREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH ( ENDPOINT_URL = 'tcp://sqlnode1:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL)
      2. Inicie el Administrador de clústeres de conmutación por error y, a continuación, haga clic en roles en el panel izquierdo. En el panel que enumera los roles, seleccione el Grupo de disponibilidad de origen.

      3. En el panel central, en la pestaña de recursos , haga clic con el botón derecho en el recurso del Grupo de disponibilidad y, a continuación, haga clic en Propiedades. Haga clic en la pestaña de dependencias , elimine la dependencia del oyente y, a continuación, haga clic en Aceptar.

        Captura de pantalla de la pestaña de dependencias de las propiedades del grupo de disponibilidad.

        Debajo de recursos, haga clic con el botón derecho en el oyente, haga clic en otras acciones y, a continuación, haga clic en asignar a otro rol.

      4. En el cuadro de diálogo asignar origen a rol , seleccione el nuevo grupo de disponibilidad y haga clic en Aceptar.

        Captura de pantalla de la asignación de un origen a un rol, con la adición de un nuevo grupo de disponibilidad mostrado.

      5. En el panel de roles , seleccione el nuevo grupo de disponibilidad. En el panel central, en la pestaña de recursos, debería ver ahora el nuevo grupo de disponibilidad y el recurso de escucha. Haga clic con el botón derecho del ratón en el nuevo recurso del grupo de disponibilidad y, a continuación, haga clic en Propiedades.
      6. Haga clic en la pestaña de dependencias , seleccione el recurso de escucha en el cuadro desplegable y, a continuación, haga clic en Aceptar.

        Captura de pantalla de la pestaña de dependencias de las propiedades del nuevo grupo de disponibilidad.

      7. En SQL Server Management Studio, utilice Object Explorer para conectarse a la instancia de SQL Server que aloja la réplica primaria del nuevo grupo de disponibilidad. Haga clic en AlwaysOn High Availability, haga clic en el nuevo grupo de disponibilidad y, a continuación, haga clic en Availability Group Listeners. Hay que encontrar el puerto del oyente.

      8. Haga clic con el botón derecho del ratón en el oyente, haga clic en Propiedades, escriba el número de puerto adecuado para el oyente y, a continuación, haga clic en Aceptar.

        Captura de pantalla de las propiedades del Listener del Grupo de Disponibilidad, mostrando la configuración del listener

        Esto asegura que las aplicaciones que utilizan el listener pueden utilizarlo siempre para conectarse a la instancia de SQL Server que aloja las bases de datos de producción sin interrupción. El grupo de disponibilidad original se puede eliminar completamente y volver a crear. O bien, las bases de datos y las réplicas pueden añadirse al nuevo grupo de disponibilidad.

        Si vuelve a crear el grupo de disponibilidad original, debe reasignar el oyente al rol del grupo de disponibilidad, configurar la dependencia entre el nuevo recurso del grupo de disponibilidad y el oyente y, a continuación, reasignar el puerto al oyente. Para ello, haga lo siguiente:

        1. Inicie el Administrador de clústeres de conmutación por error y, a continuación, haga clic en roles en el panel izquierdo. En el panel que enumera los roles, haga clic en el nuevo grupo de disponibilidad que aloja el oyente.
        2. En el panel inferior central, bajo la pestaña de recursos, haga clic con el botón derecho en el oyente, haga clic en otras acciones y, a continuación, haga clic en asignar a otro rol. En el cuadro de diálogo, seleccione el grupo de disponibilidad recreado y, a continuación, haga clic en Aceptar.
        3. En el panel de roles , haga clic en el grupo de disponibilidad recreado. En el panel central inferior, en la pestaña de recursos, debería ver ahora el grupo de disponibilidad recreado y el recurso de escucha. Haga clic con el botón derecho del ratón en el recurso del grupo de disponibilidad recreado y, a continuación, haga clic en Propiedades.
        4. Haga clic en la pestaña de dependencias , seleccione el recurso de escucha en el cuadro desplegable y, a continuación, haga clic en Aceptar.
        5. En SQL Server Management Studio, utilice Object Explorer para conectarse a la instancia de SQL Server que aloja la réplica primaria del grupo de disponibilidad recreado. Haga clic en AlwaysOn High Availability, haga clic en el nuevo grupo de disponibilidad y, a continuación, haga clic en Availability Group Listeners. Se debe encontrar el puerto del oyente.
        6. Haga clic con el botón derecho del ratón en el oyente, haga clic en Propiedades, escriba el número de puerto adecuado para el oyente y, a continuación, haga clic en Aceptar.

        Método 2: asociar el listener con un clúster de conmutación por error de SQL Server (SQLFCI)

        Si aloja su grupo de disponibilidad en una instancia de clúster de conmutación por error de SQL Server (SQLFCI), puede asociar el recurso en clúster del listener con el grupo de recursos en clúster de SQLFCI cuando libere y vuelva a crear el grupo de disponibilidad.

        1. Inicie el Administrador de clústeres de conmutación por error y, a continuación, haga clic en roles en el panel izquierdo.

        2. En el panel que enumera los roles, seleccione el grupo de disponibilidad original.

        3. En el panel central inferior, bajo la pestaña de recursos , haga clic con el botón derecho en el recurso de Grupo de disponibilidad y, a continuación, haga clic en Propiedades.

        4. Haga clic en la pestaña de dependencias , elimine la dependencia del receptor y, a continuación, haga clic en Aceptar.

        5. En el panel central inferior, bajo la pestaña de recursos , haga clic con el botón derecho en el oyente, haga clic en otras acciones y, a continuación, en asignar a otro rol.

        6. En el cuadro de diálogo asignar recurso a rol , haga clic en la instancia ICF de SQL Server y, a continuación, haga clic en Aceptar.

          Captura de pantalla del cuadro de diálogo asignar recurso a rol.

        7. En el panel de roles , seleccione el grupo SQLFCI. En el panel inferior central, en la pestaña de recursos , ahora debería ver el nuevo recurso Listener.

        8. Esto garantiza que las aplicaciones que utilizan el Listener pueden seguir utilizándolo para conectarse a la instancia de SQL Server que aloja las bases de datos de producción sin interrupción. El grupo de disponibilidad original se puede eliminar y volver a crear. O bien, las bases de datos y las réplicas pueden añadirse al nuevo grupo de disponibilidad.

          Una vez que se haya recreado el grupo de disponibilidad, reasigne el oyente al rol del grupo de disponibilidad. A continuación, configure la dependencia entre el nuevo recurso del grupo de disponibilidad y el listener y, a continuación, reasigne el puerto al listener:

          1. Inicie el Failover Cluster Manager y, a continuación, haga clic en roles en el panel izquierdo.
          2. En el panel que enumera los roles, haga clic en el rol SQLFCI original.
          3. En el panel central inferior, bajo la pestaña de recursos , haga clic con el botón derecho en el oyente, haga clic en otras acciones y, a continuación, haga clic en asignar a otro rol.
          4. En el cuadro de diálogo, haga clic en el grupo de disponibilidad recreado y, a continuación, haga clic en Aceptar.
          5. En el panel de roles , seleccione el nuevo grupo de disponibilidad.
          6. Bajo la pestaña de recursos , debería ver el nuevo grupo de disponibilidad y el recurso oyente. Haga clic con el botón derecho del ratón en el nuevo recurso del grupo de disponibilidad y, a continuación, haga clic en Propiedades.
          7. Haga clic en la pestaña de dependencias , seleccione el recurso de escucha en el cuadro desplegable y, a continuación, haga clic en Aceptar.
          8. En SQL Server Management Studio, utilice Object Explorer para conectarse a la instancia de SQL Server que aloja la réplica primaria del nuevo grupo de disponibilidad.
          9. Haga clic en AlwaysOn High Availability, haga clic en el nuevo grupo de disponibilidad y, a continuación, haga clic en Availability Group Listeners. Debería encontrarse el puerto del oyente.
          10. Haga clic con el botón derecho del ratón en el oyente, haga clic en Propiedades, escriba el número de puerto adecuado para el oyente y, a continuación, haga clic en Aceptar.

          Método 3: Eliminar el grupo de disponibilidad y, a continuación, volver a crear el grupo de disponibilidad y el oyente con el mismo nombre de oyente

          Este método provoca un pequeño fallo en las aplicaciones que están conectadas en ese momento porque el grupo de disponibilidad y el oyente se eliminan y, a continuación, se vuelven a crear:

            Eliminar el grupo de disponibilidad.

            Notas

            Esto también hará que se elimine el listener.

            Inmediatamente, cree un nuevo grupo de disponibilidad vacío que incluya la definición del listener en el mismo servidor que aloja las bases de datos de producción.

            Por ejemplo, suponga que el listener de su grupo de disponibilidad es aglisten. La siguiente sentencia Transact-SQL crea un grupo de disponibilidad sin una base de datos primaria o secundaria, pero también crea un listener llamado aglisten. Las aplicaciones pueden utilizar este listener para conectarse.

            USE masterGO CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH ( ENDPOINT_URL = 'tcp://sqlnode1:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ) LISTENER 'aglisten' ( WITH IP ((N'11.0.0.25', N'255.0.0.0')), PORT = 1433 )GO
          1. Recuperar la base de datos dañada. A continuación, añádelo junto con la réplica secundaria al grupo de disponibilidad.

          2. Por lo tanto, añade la réplica secundaria al grupo de disponibilidad.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *