Compartir por

Replicación, seguimiento de cambios y captura de datos modificados - Grupos de disponibilidad AlwaysOn

Se aplica a:SQL Server

SQL Server En Grupos de disponibilidad AlwaysOnse admiten la replicación, la captura de datos modificados (CDC) y el seguimiento de cambios (CT). Grupos de disponibilidad AlwaysOn ayuda a proporcionar alta disponibilidad y otras funcionalidades de recuperación de base de datos.

Información general de la replicación con grupos de disponibilidad

Redireccionamiento del publicador

Cuando una base de datos publicada se basa en Grupos de disponibilidad AlwaysOn, el distribuidor que proporciona el acceso del agente a la base de datos de publicación se configura con entradas de publicadores redirigidos. Estas entradas redirigirán el par publicador/base de datos configurado originalmente, haciendo uso de un nombre de agente de escucha del grupo de disponibilidad para conectarse al publicador y a la base de datos de publicación. Las conexiones establecidas a través del nombre del agente de escucha del grupo de disponibilidad producen un error en la conmutación por error. Cuando el agente de replicación se reinicia después de la conmutación por error, la conexión se redirige automáticamente a la nueva principal.

En un grupo de disponibilidad (AG), una base de datos secundaria no puede ser un publicador. La acción de volver a publicar solo se admite cuando la replicación transaccional se combina con Grupos de disponibilidad AlwaysOn.

Si una base de datos publicada es miembro de un grupo de disponibilidad y el publicador está redirigido, se debe redirigir a un nombre de agente de escucha del grupo de disponibilidad asociado al grupo de disponibilidad. Es posible que no se redirija a un nodo explícito.

Nota

Después de la conmutación por error a una réplica secundaria, el Monitor de replicación no puede ajustar el nombre de la instancia de publicación de SQL Server y continúa mostrando información de replicación bajo el nombre de la instancia principal original de SQL Server. Después de la conmutación por error, no se puede escribir un token de seguimiento mediante el Monitor de replicación; sin embargo, un token de seguimiento escrito en el nuevo publicador mediante Transact-SQL, es visible en el Monitor de replicación.

Cambios generales en los agentes de replicación para admitir grupos de disponibilidad

Tres agentes de replicación se han modificado para admitir Grupos de disponibilidad AlwaysOn. Los agentes de registro del LOG, de instantáneas y de mezcla se han modificado para consultar la base de datos de distribución del publicador redirigido y utilizar el nombre de agente de escucha del grupo de disponibilidad devuelto, si se ha declarado un publicador redirigido, para conectarse al publicador de la base de datos.

De forma predeterminada, cuando los agentes consultan al distribuidor para determinar si se ha redirigido al publicador original, se comprueba la idoneidad del destino o redireccionamiento actual antes de devolver el host redirigido al agente. Este es el comportamiento recomendado. Sin embargo, si el inicio del agente se produce con frecuencia, la sobrecarga asociada al procedimiento almacenado de validación podría considerarse demasiado costosa. Se ha agregado un nuevo modificador de la línea de comandos, BypassPublisherValidation, a los agentes del lector del registro, de instantáneas y de combinación. Cuando se utiliza el modificador, el publicador redirigido se devuelve inmediatamente al agente y se omite la ejecución del procedimiento almacenado de validación.

Los errores devueltos por el procedimiento almacenado de validación se registran en los registros de historial del agente. Esos errores con gravedad mayor o igual que 16 hacen que los agentes finalicen. Algunas capacidades de reintento se han integrado en los agentes para controlar la desconexión esperada de una base de datos publicada cuando se conmuta por error a una principal.

Modificaciones del agente de registro del log

El agente de registro del log tiene los siguientes cambios.

  • Coherencia de la base de datos replicada

    Cuando una base de datos publicada es miembro de un grupo de disponibilidad, de forma predeterminada, el lector de registros no procesa los registros de registro que aún no se han protegido en todas las réplicas secundarias del grupo de disponibilidad. Esto garantiza que, en la conmutación por error, todas las filas replicadas a un suscriptor también estarán presentes en el nuevo elemento principal.

    Cuando el publicador solo tiene dos réplicas de disponibilidad (una principal y otra secundaria) y se produce una conmutación por error, la réplica principal original permanece inactiva porque el lector de registros no avanza hasta que todas las bases de datos secundarias se vuelven a poner en línea o hasta que las réplicas secundarias con error se quitan del grupo de disponibilidad. El lector de registros, que ahora se ejecuta en la base de datos secundaria, no avanza, ya que el grupo de disponibilidad no puede proteger ningún cambio en ninguna base de datos secundaria. Para que el lector del registro pueda continuar y seguir disfrutando de la capacidad de recuperación ante desastres, quite la réplica principal original del grupo de disponibilidad usando ALTER AVAILABITY GROUP <nombre_de_grupo> REMOVE REPLICA. Después, agregue una nueva réplica secundaria al grupo de disponibilidad.

  • Marca de seguimiento 1448

    La marca de seguimiento 1448 permite que el lector del registro de replicación avance incluso si las réplicas secundarias asincrónicas no han confirmado la recepción de un cambio. Incluso con esta marca de seguimiento habilitada, el lector de registros siempre espera las réplicas secundarias sincrónicas (podrían convertirse en modo de confirmación asincrónica, por lo que el lector de registros puede avanzar). El lector de registros no va más allá del mínimo de las réplicas secundarias sincrónicas. Esta marca de seguimiento se aplica a la instancia de SQL Server, no solo a un grupo disponibilidad, una base de datos de disponibilidad o una instancia del lector de registros. Esta marca de seguimiento debe estar habilitada en la instancia del publicador. Surte efecto inmediatamente sin reiniciar. Se puede activar de antemano o cuando se produce un error en una réplica secundaria asincrónica.

Procedimientos almacenados que admiten grupos de disponibilidad

  • sp_redirect_publisher

    El procedimiento almacenado sp_redirect_publisher sirve para especificar un publicador redirigido para un par publicador/base de datos existente. Si la base de datos del publicador pertenece a un grupo de disponibilidad, el publicador redirigido es el nombre de agente de escucha del grupo de disponibilidad.

  • sp_get_redirected_publisher

    Los agentes de replicación usan el procedimiento almacenado sp_get_redirected_publisher para consultar un distribuidor y saber si un par publicador/base de datos tiene un publicador redirigido definido. Este procedimiento almacenado cumple dos fines. Primero, permite al agente determinar si se ha redirigido el publicador original. En segundo lugar, también podría iniciar una ejecución de procedimiento almacenado de validación en el distribuidor (sp_validate_redirected_publisher) que comprueba la idoneidad del nodo de destino de la redirección para servir como publicador para la base de datos con nombre.

    Para ejecutar este procedimiento almacenado, el autor de la llamada debe ser miembro del rol de servidor sysadmin , del rol de base de datos db_owner para la base de datos de distribución o de una lista de acceso a la publicación para una publicación definida asociada a la base de datos del publicador.

  • sp_validate_redirected_publisher

    Este procedimiento almacenado intenta validar que el publicador actual es capaz de hospedar la base de datos publicada. Se le puede llamar en cualquier momento para comprobar que el host actual de la base de datos publicada es capaz de admitir la replicación.

  • sp_validate_replicate_hosts_as_publishers

    Aunque resulta útil para los agentes asegurarse de que la principal actual puede funcionar como publicador de replicación para una base de datos de publicador, se necesita una funcionalidad de validación más general para establecer la validez de una topología de replicación completa en una base de datos de grupo de disponibilidad. El procedimiento sp_validate_replica_hosts_as_publishers almacenado está diseñado para satisfacer esta necesidad.

    Este procedimiento almacenado se ejecuta siempre manualmente. El autor de la llamada debe tener el rol sysadmin en el distribuidor, el rol dbowner de la base de datos de distribución o ser miembro de la lista de acceso a la publicación de una publicación de la base de datos del publicador. Además, el inicio de sesión del autor de la llamada debe ser un inicio de sesión válido para todos los hosts de réplicas de disponibilidad y tener determinados privilegios en la base de datos de disponibilidad asociada a la base de datos del publicador.

captura de datos modificados

Las bases de datos habilitadas para la captura de datos modificados (CDC) pueden usar Grupos de disponibilidad AlwaysOn para asegurarse de que no solo la base de datos sigue estando disponible en caso de error, sino que los cambios en las tablas de la base de datos se siguen supervisando y depositando en las tablas de cambios de CDC. El orden en que se configuran los grupos de disponibilidad CDC y AlwaysOn no es importante. Las bases de datos habilitadas para CDC se pueden agregar a grupos de disponibilidad AlwaysOn y las bases de datos que son miembros de un grupo de disponibilidad se pueden habilitar para CDC. Sin embargo, en ambos casos, la configuración de CDC se realiza siempre en la réplica principal prevista o actual. CDC usa el agente de registro del log y tiene las mismas limitaciones que se describen en la sección Modificaciones del agente de registro del log anteriormente en este artículo.

  • Recopilación de cambios para la captura de datos modificados sin replicación

    Si CDC está habilitado para una base de datos, pero la replicación no es así, el proceso de captura usado para recopilar los cambios del registro y depositarlos en las tablas de cambios CDC se ejecuta en el host CDC como su propio trabajo del Agente SQL.

    Para reanudar la recolección de cambios después de la conmutación por error, el procedimiento almacenado sp_cdc_add_job se debe ejecutar en el nuevo elemento principal para crear el trabajo de captura local.

    En el ejemplo siguiente se crea el trabajo de captura.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Recopilación de cambios para la captura de datos modificados con replicación

    Si CDC y la replicación están habilitadas para una base de datos, el agente de registro del LOG controla el rellenado de las tablas de cambios de CDC. En este caso, las técnicas usadas por la replicación para usar grupos de disponibilidad AlwaysOn garantizan que los cambios se sigan recopilando del registro y se depositen en las tablas de cambios CDC después de la conmutación por error. No es necesario realizar ninguna acción más para CDC en esta configuración para garantizar que las tablas de cambios se van a rellenar.

  • Limpieza de captura de datos modificados

    Para garantizar que se produce la limpieza apropiada en la nueva base de datos principal, siempre debe crearse un trabajo de limpieza local. En el ejemplo siguiente se crea el trabajo de limpieza.

    EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';

    Nota

    Debe crear los trabajos en la nueva réplica principal después de la conmutación por error. Los trabajos de CDC que se ejecutan en la base de datos principal anterior deben estar deshabilitados cuando la base de datos local se convierte en una base de datos secundaria. Si la réplica original vuelve a ser principal, debe volver a habilitar los trabajos CDC en la réplica de esa réplica. Para deshabilitar y habilitar trabajos, use la opción @enabled de sp_update_job. Para obtener más información sobre cómo crear trabajos CDC, consulte sys.sp_cdc_add_job.

  • Adición de roles CDC a una réplica de base de datos principal

    Cuando una tabla está habilitada para CDC, es posible asociar un rol de base de datos a la instancia de captura. Si se especifica un rol, el usuario que desea utilizar funciones con valores de tabla CDC para tener acceso a los cambios de la tabla no solo debe tener acceso de selección a las columnas de la tabla sometida a seguimiento, sino que también debe ser miembro del rol con nombre. Si el rol especificado aún no existe, se crea el rol. Cuando los roles de base de datos se agregan automáticamente a una base de datos principal de un grupo de disponibilidad, los roles también se propagan a las bases de datos secundarias del grupo de disponibilidad.

  • Aplicaciones cliente que acceden a los datos modificados cdc y los grupos de disponibilidad

    Las aplicaciones cliente que usan funciones con valores de tabla (TVF) o servidores vinculados para tener acceso a datos de las tablas de cambios también necesitan poder encontrar un host de CDC apropiado después de la conmutación por error. El nombre de agente de escucha del grupo de disponibilidad es el mecanismo proporcionado por Grupos de disponibilidad AlwaysOn para permitir de forma transparente la redirección de una conexión a un host diferente. Una vez que un nombre de agente de escucha del grupo de disponibilidad está asociado a un grupo de disponibilidad, está disponible para usarse en cadenas de conexión TCP. Se admiten dos escenarios de conexión diferentes mediante el nombre de agente de escucha del grupo de disponibilidad.

    • En uno se garantiza que las solicitudes de conexión se dirigen siempre a la réplica principal actual.
    • En el otro se garantiza que las solicitudes de conexión se dirigen a una réplica secundaria de solo lectura.

    Si se usa para buscar una réplica secundaria de solo lectura, también se debe definir una lista de enrutamiento de solo lectura para el grupo de disponibilidad. Para obtener más información sobre el enrutamiento del acceso a secundarias legibles, consulte Configuración del enrutamiento de solo lectura para un grupo de disponibilidad AlwaysOn.

    Nota

    Hay algún retraso de propagación asociado a la creación de un nombre de agente de escucha de grupo de disponibilidad y su uso por parte de las aplicaciones cliente para acceder a una réplica de base de datos del grupo de disponibilidad.

    Utilice la consulta siguiente para determinar si se ha definido un nombre de agente de escucha del grupo de disponibilidad para el grupo de disponibilidad que hospeda una base de datos CDC. La consulta devuelve el nombre del agente de escucha del grupo de disponibilidad si se ha creado uno.

    SELECT dns_name
FROM sys.availability_group_listeners AS l
     INNER JOIN sys.availability_databases_cluster AS d
         ON l.group_id = d.group_id
WHERE d.database_name = N'MyCDCDB';

  • Redirigir la carga de consultas a una réplica secundaria legible

    Aunque en muchos casos una aplicación cliente siempre quiere conectarse a la réplica principal actual, esta no es la única manera de usar grupos de disponibilidad AlwaysOn. Si se configura un grupo de disponibilidad para que admita réplicas secundarias legibles, también se pueden recopilar los datos modificados de nodos secundarios.

    Cuando se configura un grupo de disponibilidad, el atributo ALLOW_CONNECTIONS asociado a SECONDARY_ROLE se usa para especificar el tipo de acceso secundario admitido. Si se configura como ALL, se permiten todas las conexiones a la base de datos secundaria, pero solo las que requieren acceso de solo lectura se realizan correctamente. Si se configura como READ_ONLY, es necesario especificar la intención de solo lectura al realizar la conexión a la base de datos secundaria para que la conexión se realice correctamente. Para obtener más información, consulte Configuración del acceso de solo lectura a una réplica secundaria de un grupo de disponibilidad AlwaysOn.

    Se puede usar la siguiente consulta para determinar si se necesita la intención de solo lectura para conectarse a una réplica secundaria legible.

    SELECT g.name AS AG,
          replica_server_name,
          secondary_role_allow_connections_desc
FROM sys.availability_replicas AS r
     INNER JOIN sys.availability_groups AS g
          ON r.group_id = g.group_id
WHERE g.name = N'MY_AG_NAME';

    Se puede usar el nombre de agente de escucha del grupo de disponibilidad o el nombre de nodo explícito para buscar la réplica secundaria. Si se usa el nombre del agente de escucha del grupo de disponibilidad, el acceso se dirige a cualquier réplica secundaria adecuada.

    Cuando sp_addlinkedserver se usa para crear un servidor vinculado para acceder a la base de datos secundaria, el parámetro @datasrc se usa para el nombre del agente de escucha del grupo de disponibilidad o el nombre de servidor explícito, y el parámetro @provstr se usa para especificar la intención de solo lectura.

    EXECUTE sp_addlinkedserver
    @server = N'linked_svr',
    @srvproduct = N'SqlServer',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'AG_Listener_Name',
    @provstr = N'ApplicationIntent=ReadOnly',
    @catalog = N'MY_DB_NAME';

  • Acceso de cliente a los datos modificados por CDC y los inicios de sesión de dominio

    En general, debe usar inicios de sesión de dominio para el acceso de cliente para cambiar los datos que residen en bases de datos que son miembros de grupos de disponibilidad. Para garantizar el acceso continuo a los datos modificados después de la conmutación por error, el usuario del dominio necesita privilegios de acceso en todos los hosts que admiten réplicas del grupo de disponibilidad. Si se agrega un usuario de base de datos a una base de datos en una réplica principal y el usuario está asociado a un inicio de sesión de dominio, el usuario de base de datos se propaga a las bases de datos secundarias y continúa asociado al inicio de sesión de dominio especificado. Si el nuevo usuario de base de datos está asociado a un inicio de sesión de autenticación de SQL Server, el usuario de las bases de datos secundarias se propaga sin un inicio de sesión. Mientras que el inicio de sesión de autenticación de SQL Server asociado se puede utilizar para acceder a los datos modificados del elemento principal donde se definió originalmente el usuario de base de datos, ese nodo es el único donde sería posible el acceso. El inicio de sesión de autenticación de SQL Server no podría tener acceso a datos desde ninguna base de datos secundaria ni desde ninguna base de datos principal nueva que no sea la base de datos original en la que se definió el usuario de la base de datos.

  • Deshabilitación de la captura de datos modificados

    Si necesita deshabilitar la captura de datos modificados (CDC) en una base de datos que forma parte de un grupo de disponibilidad y está en SQL Server 2016 SP2 o posterior, no es necesario realizar ningún paso adicional para el truncamiento automático del registro. Si está en una versión anterior a SQL Server 2016 SP2 y deshabilita CDC en una base de datos que forma parte de un grupo de disponibilidad, deberá implementar uno de los pasos siguientes para evitar el truncamiento del registro después de deshabilitar CDC:

    • Reiniciar el servicio SQL Server en cada instancia de réplica secundaria.

    • Quite la base de datos de todas las instancias de réplica secundaria del grupo de disponibilidad y, a continuación, agréguela a cada instancia de réplica del grupo de disponibilidad mediante la propagación automática o manual.

Seguimiento de cambios

Una base de datos habilitada para el seguimiento de cambios (CT) puede formar parte de un grupo de disponibilidad. No se necesita ninguna configuración más. Las aplicaciones cliente de seguimiento de cambios que usan las funciones con valores de tabla CDC (TVF) para acceder a los datos modificados necesitan la capacidad de localizar la réplica principal después de la conmutación por error. Si la aplicación cliente se conecta a través del nombre del agente de escucha del grupo de disponibilidad, las solicitudes de conexión siempre se dirigen correctamente a la réplica principal actual.

Los datos del seguimiento de cambios deben obtenerse siempre de la réplica principal. Un intento de acceder a los datos modificados desde una réplica secundaria produce el siguiente error:

Msg 22117, Level 16, State 1, Line 1

En el caso de las bases de datos que son miembros de una réplica secundaria (es decir, para las bases de datos secundarias), no se admite el seguimiento de cambios. Como alternativa a la ejecución de consultas de seguimiento de cambios en la réplica principal, puede crear una instantánea de base de datos de una base de datos de grupo de disponibilidad a partir de la réplica secundaria y, a continuación, usarla para consultar los datos de cambio. Una instantánea de base de datos es una vista estática de solo lectura de una base de datos de SQL Server (la base de datos de origen), por lo que los datos de seguimiento de cambios en la instantánea de base de datos son de la hora en que se tomó la instantánea en la base de datos de grupo de disponibilidad desde la réplica secundaria.

Nota

Cuando se produce una conmutación por error en una base de datos con el seguimiento de cambios habilitado, el tiempo de recuperación en la nueva réplica principal puede tardar más de lo habitual, ya que el seguimiento de cambios requiere un reinicio completo de la base de datos.

Requisitos previos, restricciones y consideraciones para usar la replicación

En esta sección se describe las consideraciones para implementar la replicación con Grupos de disponibilidad AlwaysOn, incluidos los requisitos previos, las restricciones y las recomendaciones.

Requisitos previos

  • Cuando se utiliza la replicación transaccional y la base de datos de publicación está en un grupo de disponibilidad, tanto el publicador como el distribuidor deben ejecutar al menos SQL Server 2012 (11.x). El suscriptor puede utilizar un nivel inferior de SQL Server.

  • Cuando se utiliza la replicación de mezcla y la base de datos de publicación está en un grupo de disponibilidad:

    • Suscripción de inserción: tanto el publicador como el distribuidor deben ejecutar como mínimo SQL Server 2012 (11.x).

    • Suscripción de extracción: las bases de datos del publicador, el distribuidor y el suscriptor deben ser al menos de SQL Server 2012 (11.x). Esto se debe a que el agente de mezcla el suscriptor debe entender cómo un grupo de disponibilidad puede realizar la conmutación por error a su réplica secundaria.

  • Las instancias del publicador cumplen todos los requisitos previos necesarios para participar en un grupo de disponibilidad. Para obtener más información, consulte Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn.

Restricciones

Combinaciones admitidas de replicación en Grupos de disponibilidad AlwaysOn:

Replicación Publicador Distribuidor 1 Suscriptor
Transaccional Sí

Nota: No incluye compatibilidad con la replicación transaccional bidireccional y recíproca.		 Sí Sí
Punto a punto2 Sí Sí 3 Sí
Combinar Sí No No
Instantánea Sí No Sí
Suscripciones actualizables: para la replicación transaccional No No No

1 La base de datos del distribuidor no se admite para su uso con la creación de reflejo de la base de datos.

2 Requiere SQL Server 2019 CU13 o versiones posteriores.

3 Requiere SQL Server 2019 CU 17 o versiones posteriores.

Consideraciones

  • La base de datos de distribución no se admite para su uso con la creación de reflejo de la base de datos, pero se admite con grupos de disponibilidad AlwaysOn sujetos a ciertas limitaciones. Para obtener más información, vea Configurar el grupo de disponibilidad de distribución. La configuración de replicación se acopla a la instancia de SQL Server donde se configura el distribuidor; por lo tanto, la base de datos de distribución no se puede reflejar ni replicar. También es posible proporcionar alta disponibilidad para el distribuidor mediante un clúster de conmutación por error de SQL Server. Para obtener más información, vea Instancias de clúster de conmutación por error AlwaysOn (SQL Server).

  • La conmutación por error del suscriptor a una base de datos de secundaria, aunque se admite, es un procedimiento para suscriptores de replicación de mezcla. El procedimiento es básicamente idéntico al método utilizado para la conmutación por error de una base de datos de suscriptor reflejada. Los suscriptores de replicación transaccional no necesitan un control especial al participar en grupos de disponibilidad AlwaysOn. Los suscriptores deben ejecutar SQL Server 2012 (11.x) o una versión posterior para participar en un grupo de disponibilidad. Para obtener más información, vea Suscriptores de replicación y grupos de disponibilidad AlwaysOn (SQL Server)

  • Los metadatos y los objetos que existen fuera de la base de datos no se propagan a las réplicas secundarias, incluidos los inicios de sesión, los trabajos y los servidores vinculados. Si se necesitan los metadatos y los objetos en la nueva base de datos principal después de la conmutación por error, se deben copiar manualmente. Para obtener más información, consulte Administración de inicios de sesión para trabajos mediante bases de datos en un grupo de disponibilidad AlwaysOn.

Grupos de disponibilidad distribuidos

El publicador o la base de datos de distribución de un grupo de disponibilidad no se pueden configurar como parte de un grupo de disponibilidad distribuido. La base de datos del publicador de un grupo de disponibilidad y la base de datos de distribución de un grupo de disponibilidad requieren un punto de conexión de escucha para la configuración y el uso adecuados. Sin embargo, no es posible configurar un punto de conexión de agente de escucha para un grupo de disponibilidad distribuido.

Replicación

captura de datos modificados

Seguimiento de cambios

Contenido relacionado

  • Last updated on