Replicación transaccional con Instancia administrada de Azure SQL

  • Artículo

Se aplica a:Azure SQL Managed Instance

La replicación transaccional es una característica de Instancia administrada de Azure SQL y SQL Server que permite replicar datos de una tabla de Instancia administrada de Azure SQL o SQL Server en tablas colocadas en bases de datos remotas. Esta característica permite sincronizar varias tablas en bases de datos diferentes.

Información general

La replicación transaccional se puede usar para insertar los cambios realizados en una instancia administrada de Azure SQL en:

  • Una base de datos de SQL Server (local o en una máquina virtual de Azure)
  • Una base de datos de Azure SQL Database
  • Una base de datos de instancia en Azure SQL Managed Instance

Nota:

Para usar todas las características de Azure SQL Managed Instance es preciso tener las versiones más recientes de SQL Server Management Studio (SSMS) y SQL Server Data Tools (SSDT).

Componentes

Los componentes clave de la replicación transaccional son el publicador, el distribuidor y el suscriptor, como se muestra en la siguiente imagen:

Diagram of replication with Azure SQL.

Role Azure SQL Database Instancia administrada de Azure SQL
Publicador No Sí
Distribuidor No Sí
Suscriptor de extracción No Sí
Suscriptor de inserción Sí Sí

El publicador publica los cambios realizados en algunas tablas (artículos) mediante el envío de las actualizaciones al distribuidor. El publicador puede ser una instancia administrada de Azure SQL o una instancia de SQL Server.

El distribuidor recopila los cambios en los artículos de un publicador y los distribuye a los suscriptores. El distribuidor puede ser una instancia administrada de Azure SQL o una instancia de SQL Server (cualquier versión, siempre que sea igual o superior a la del publicador).

El suscriptor recibe los cambios realizados en el publicador. Tanto una instancia de SQL Server como una instancia administrada de Azure SQL pueden ser suscriptores de inserción y de extracción, aunque las suscripciones de extracción no se admiten si el distribuidor es una instancia de administrada de Azure SQL y el suscriptor no. Una base de datos de Azure SQL Database solo puede ser un suscriptor de inserción.

Instancia administrada de Azure SQL puede ser un suscriptor de las siguientes versiones de SQL Server:

Nota:

En el caso de las versiones de SQL Server que no admiten la publicación en los objetos de Azure, se puede utilizar el método de volver a publicar datos para mover datos a versiones más recientes de SQL Server.

El intento de configuración de la replicación mediante una versión anterior puede provocar los errores MSSQL_REPL20084 (El proceso no pudo conectarse al suscriptor) y MSSQL_REPL40532 (No se puede abrir el <nombre> de servidor solicitado por el inicio de sesión. No se pudo iniciar la sesión).

Tipos de replicación

Existen distintos tipos de replicación:

Replicación Azure SQL Database Instancia administrada de Azure SQL
Transaccional estándar Sí (solo como suscriptor) Sí
Instantánea Sí (solo como suscriptor) Sí
Replicación de mezcla No No
Punto a punto No No
Bidireccional No Sí
Suscripciones actualizables No No

Matriz de compatibilidad

La matriz de compatibilidad de la replicación transaccional con Instancia administrada de Azure SQL es la misma que con SQL Server.

Publicador Distribuidor Suscriptor
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016		 SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014		 SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012		 SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Cuándo se usa

La replicación transaccional resulta útil en los siguientes escenarios:

  • Publique los cambios realizados en una o varias tablas de una base de datos y distribúyalos a una o varias bases de datos de una instancia de SQL Server o Azure SQL Database suscrita a los cambios.
  • Mantenga varias bases de datos distribuidas en estado sincronizado.
  • Migre las bases de datos de una instancia de SQL Server o Instancia administrada de Azure SQL a otra base de datos mediante la publicación continua de los cambios.

Comparación de Data Sync con una replicación transaccional

Category Sincronización de datos Replicación transaccional
Ventajas - Compatibilidad activo-activo
- Bidireccional entre el entorno local y Azure SQL Database		 - Menor latencia
- Coherencia transaccional
- Reutilización de la topología existente después de la migración
Inconvenientes - Sin coherencia transaccional
- Mayor impacto en el rendimiento		 - No se puede publicar desde Azure SQL Database
- Alto costo de mantenimiento

Configuraciones comunes

En general, el publicador y el distribuidor deben estar en la nube o en el entorno local. Se admiten las siguientes configuraciones:

Publicador con distribuidor local en Instancia administrada de SQL

Single instance as Publisher and Distributor.

El publicador y el distribuidor se configuran en una sola instancia administrada de SQL y los cambios se distribuyen a otra instancia administrada de SQL, SQL Database o SQL Server.

Publicador con distribuidor remoto en Instancia administrada de SQL

En esta configuración, una instancia administrada de SQL publica los cambios en un distribuidor que se encuentra en otra instancia administrada de SQL que puede atender a muchas instancias administradas de SQL de origen y distribuir los cambios a uno o varios destinos de Azure SQL Database, Instancia administrada de Azure SQL o SQL Server.

Separate instances for Publisher and Distributor.

El publicador y el distribuidor se configuran en dos Instancias administradas. Esta configuración presenta algunas restricciones:

  • Las dos instancias administradas están en la misma red virtual.
  • Las dos Instancias administradas están en la misma ubicación.

Publicador o distribuidor local con un suscriptor remoto

Azure SQL Database as subscriber.

En esta configuración, una base de datos de Azure SQL Database o Instancia administrada de Azure SQL es un suscriptor. Esta configuración admite la migración desde el entorno local a Azure. Si un suscriptor es una base de datos de Azure SQL Database, debe estar en modo de inserción.

Requisitos

  • Use la autenticación de SQL para la conectividad entre los participantes en la replicación.
  • Use un recurso compartido de cuenta de Azure Storage para el directorio de trabajo empleado por la replicación.
  • Abra el puerto de salida TCP 445 en las reglas de seguridad de la subred para acceder al recurso compartido de archivos de Azure.
  • Abra el puerto de salida TCP 1433 cuando la instancia administrada de SQL sea el publicador o el distribuidor, no el suscriptor. Es posible que también deba cambiar la regla de seguridad de salida del grupo de seguridad de red de la instancia administrada de SQL en allow_linkedserver_outbound de la Etiqueta de servicio de destino del puerto 1433 de virtualnetwork a internet.
  • Coloque el publicador y el distribuidor en la nube, o ambos en local.
  • Configure el emparejamiento de VPN entre las redes virtuales de los participantes en la replicación si las redes virtuales son diferentes.

Nota:

Podría producirse el error 53 al conectarse a un archivo de Azure Storage si el puerto 445 del grupo de seguridad de red (NSG) de salida está bloqueado cuando el distribuidor es una base de datos de Instancia administrada de Azure SQL y el suscriptor es local. Actualice el NSG de la red virtual para resolver este problema.

Limitaciones

La replicación transaccional tiene algunas limitaciones específicas de Azure SQL Managed Instance. En esta sección, obtendrá más información sobre estas limitaciones.

Los archivos de instantáneas no se eliminan de la cuenta de Azure Storage

Azure SQL Managed Instance usa la cuenta de Azure Storage configurada por el usuario para los archivos de instantánea que se usan para la replicación transaccional. A diferencia de SQL Server en el entorno local, Azure SQL Managed Instance no elimina los archivos de instantáneas de la cuenta de Azure Storage. Una vez que los archivos no se necesiten, debe eliminarlos, lo que se puede hacer a través de la interfaz de Azure Storage en Azure Portal, Explorador de Microsoft Azure Storage, o bien a través de clientes de línea de comandos (Azure PowerShell o CLI) o la API REST de Azure Storage Management.

Este es un ejemplo de cómo eliminar un archivo y cómo eliminar una carpeta vacía.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Número de agentes de distribución que se ejecutan continuamente

En Azure SQL Managed Instance, el número de agentes de distribución configurados para ejecutarse continuamente está limitado a 30. Para tener más agentes de distribución, es preciso que se ejecuten a petición o con una programación definida. La programación se puede definir con una frecuencia diaria y una repetición de cada 10 segundos (o más), por lo que aunque no sea continua, se puede tener un distribuidor que introduce latencia que es solo varios segundos. Cuando se necesita un gran número de distribuidores, se recomienda usar la configuración programada, en lugar de la continua.

Con grupos de conmutación por error

Se admite el uso de la replicación transaccional con instancias que se encuentran en un grupo de conmutación por error. Sin embargo, si configura la replicación antes de agregar una instancia administrada de SQL a un grupo de conmutación por error, la replicación se detiene temporalmente cuando empiece a crear el grupo de conmutación por error y el monitor de replicación muestra el estado Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. La replicación se reanuda una vez que el grupo de conmutación por error se crea correctamente.

Si una instancia administrada de SQL de un publicador o distribuidor se encuentra en un grupo de conmutación por error, el administrador de la instancia administrada de SQL debe limpiar todas las publicaciones de la instancia principal anterior y volver a configurarlas en la nueva instancia principal después de una conmutación por error. En este escenario, debe llevar a cabo las siguientes acciones:

  1. Detenga todos los trabajos de replicación que se ejecutan en la base de datos, si hay alguno.

  2. Quite los metadatos de suscripción del publicador. Para ello, ejecute el siguiente script en la base de datos del publicador. Reemplace los valores <name of publication> y <name of subscriber>:

    EXEC sp_dropsubscription @publication = '<name of publication>',
    @article = 'all',
    @subscriber = '<name of subscriber>'

  3. Quite los metadatos de suscripción del suscriptor. Ejecute el siguiente script en la base de datos de suscripciones de la instancia administrada de SQL de suscriptor. Reemplace el valor <full DNS of publisher>. Por ejemplo, example.ac2d23028af5.database.windows.net:

    EXEC sp_subscription_cleanup
   @publisher = N'<full DNS of publisher>',
   @publisher_db = N'<publisher database>',
   @publication = N'<name of publication>';

  4. Quite forzosamente todos los objetos de replicación del publicador. Para ello, ejecute el siguiente script en la base de datos publicada:

    EXEC sp_removedbreplication;

  5. Fuerce la eliminación del distribuidor anterior de la instancia administrada de SQL principal original (si realiza la conmutación por recuperación a una instancia principal anterior que tenía un distribuidor). Ejecute el siguiente script en la base de datos master de la instancia administrada de SQL de distribuidor anterior:

    EXEC sp_dropdistributor 1, 1;

Si la instancia administrada de SQL de un suscriptor se encuentra en un grupo de conmutación por error, la publicación debe configurarse para conectarse al punto de conexión del cliente de escucha del grupo de conmutación por error para la instancia administrada de SQL del suscriptor. En el caso de una conmutación por error, la acción posterior por parte del administrador de instancia administrada de SQL depende del tipo de conmutación por error que se produjo:

  • Para una conmutación por error sin pérdida de datos, la replicación seguirá funcionando después de la conmutación por error.
  • En el caso de una conmutación por error con pérdida de datos, también se puede realizar una replicación. Vuelve a replicar los cambios perdidos.
  • En el caso de una conmutación por error con pérdida de datos fuera del período de retención de la base de datos de distribución, el administrador de la instancia administrada de SQL tiene que reinicializar la base de datos de suscripciones.

Solución de problemas comunes

Registro de transacciones y replicación transaccional

En circunstancias habituales, el registro de transacción se usa para registrar los cambios de los datos dentro de una base de datos. Los cambios se registran en el registro de transacciones y esto hace que el consumo de almacenamiento de registros aumente. También hay un proceso automático que permite el truncamiento seguro del registro de transacciones y este proceso reduce el espacio de almacenamiento usado para el registro. Cuando se configura la publicación para la replicación transaccional, se impide el truncamiento del registro de transacciones hasta que el trabajo del lector del registro procesa los cambios en el registro. En algunas circunstancias, el procesamiento del registro de transacciones se bloquea eficazmente y ese estado puede dar lugar a llenar todo el almacenamiento reservado para el registro de transacciones. Cuando no hay espacio disponible para el registro de transacciones y no hay más espacio para que crezca el registro de transacciones, tenemos un registro de transacciones completo. En este estado, la base de datos ya no puede procesar ninguna carga de trabajo de escritura y, de hecho, se convierte en una base de datos de solo lectura.

Agente de registro de registro deshabilitado

A veces, la publicación de replicación transaccional está configurada para una base de datos, pero el agente de registro del log no está configurado para ejecutarse. En ese caso, los cambios se acumulan en el registro de transacciones y no se procesan. Esto conduce al crecimiento constante del registro transaccional y, finalmente, al registro de transacción completo. El usuario debe asegurarse de que el trabajo del lector de registros existe y está activo. La alternativa sería deshabilitar la replicación transaccional, si no es necesaria.

Tiempos de espera de consulta del agente de registro

A veces, el trabajo del lector de registros no puede realizar un progreso efectivo debido a tiempos de espera de consulta repetidos. Una manera de corregir los tiempos de espera de consulta es aumentar la configuración de tiempo de espera de consulta para el trabajo del agente de registro del log.

Es posible incrementar el tiempo de espera de consulta para el trabajo del lector de registros a través de SSMS. En el explorador de objetos, en Agente SQL Server, busque el trabajo que desea modificar. En primer lugar, deténgalo y, a continuación, abra sus propiedades. Busque step 2 y edítelo. Anexe el valor del comando con -QueryTimeout <timeout_in_seconds>. Como valor de tiempo de espera de consulta, pruebe 21600 o superior. Por último, vuelva a iniciar el trabajo.

El tamaño de almacenamiento de registros ha alcanzado el límite máximo de 2 TB

Cuando el tamaño de almacenamiento del registro de transacciones alcanza el límite máximo, que es de 2 TB, el registro no puede crecer más que eso físicamente. En este caso, la única mitigación disponible es marcar todas las transacciones que se van a replicar como procesadas, para permitir que se trunque el registro de transacciones. En la práctica, esto significa que las transacciones restantes del registro no se replicarán y deberá reinicializar la replicación.

Nota:

Después de realizar la mitigación, tendrá que reinicializar la replicación, lo que significa volver a replicar todo el conjunto de datos. Se trata de una operación que se aplica al tamaño completo de los datos y puede tomar mucho tiempo, en función de la cantidad de datos que se deban replicar.

Para realizar la mitigación, primero debe detener el agente lector de registros en el distribuidor. A continuación, debe ejecutar el procedimiento almacenado sp_repldone con la marca reset establecida en 1 en la base de datos del publicador para permitir el truncamiento del registro de transacciones. Este comando debe asemejarse a: EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1. Después de esto, deberá reinicializar la replicación.

Pasos siguientes

Para obtener más información sobre la configuración de la replicación transaccional, vea los siguientes tutoriales:

Consulte también