Replicación transaccional con Azure SQL Managed Instance (versión preliminar)
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.
La replicación transaccional está actualmente en versión preliminar pública para SQL Managed Instance.
Información general
Puede usar la replicación transaccional para insertar los cambios realizados en una instancia administrada de Azure SQL en:
Una base de datos de SQL Server, en el entorno 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 Instancia administrada de Azure SQL, debe 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:

| 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 versión del publicador).
El suscriptor recibe los cambios realizados en el publicador. Una instancia de SQL Server y una instancia administrada de Azure SQL pueden ser suscriptores de inserción y de extracción, aunque una suscripción de extracción no se admite 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:
SQL Server 2016 y posterior
SQL Server 2014 RTM CU10 (12.0.4427.24) o SP1 CU3 (12.0.2556.4)
SQL Server 2012 SP2 CU8 (11.0.5634.1), SP3 (11.0.6020.0) o SP4 (11.0.7001.0)
Nota
- Para otras versiones de SQL Server que no admiten la publicación en los objetos de Azure e puede utilizar el método de volver a publicar datos para mover datos a versiones más recientes de SQL Server.
- Al intentar configurar la replicación con una versión anterior, puede producirse el error número MSSQL_REPL20084 (El proceso no pudo conectarse al suscriptor) y MSSQL_REPL40532 (No se puede abrir el servidor <name> solicitado por el inicio de sesión. Error de inicio de 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 2019 | SQL Server 2019 | SQL Server 2019 SQL Server 2017 SQL Server 2016 |
| SQL Server 2017 | SQL Server 2019 SQL Server 2017 |
SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 |
| SQL Server 2016 | 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 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 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 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 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

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 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.

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

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 Instancia administrada de SQL sea el publicador o el distribuidor y no el suscriptor. Es posible que también deba cambiar la regla de seguridad de salida del grupo de seguridad de red de Instancia administrada de SQL en
allow_linkedserver_outboundde la Etiqueta de servicio de destino del puerto 1433 devirtualnetworkainternet. - 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.
Con grupos de conmutación por error
Si una instancia de SQL Managed Instance que es publicador o distribuidor se encuentra en un grupo de conmutación por error, el administrador de SQL Managed Instance debe limpiar todas las publicaciones en 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:
Detenga todos los trabajos de replicación que se ejecutan en la base de datos, si hay alguno.
Quite los metadatos de suscripción del publicador. Para ello, ejecute el siguiente script en la base de datos del publicador:
EXEC sp_dropsubscription @publication='<name of publication>', @article='all',@subscriber='<name of subscriber>'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:
EXEC sp_subscription_cleanup @publisher = N'<full DNS of publisher, e.g. example.ac2d23028af5.database.windows.net>', @publisher_db = N'<publisher database>', @publication = N'<name of publication>';Quite forzosamente todos los objetos de replicación del publicador. Para ello, ejecute el siguiente script en la base de datos publicada:
EXEC sp_removedbreplicationQuite forzosamente el distribuidor anterior de la instancia administrada de SQL principal original (si realiza la conmutación por recuperación a una instancia principal anterior que solía tener un distribuidor). Ejecute el siguiente script en la base de datos maestra de la instancia administrada de SQL de distribuidor anterior:
EXEC sp_dropdistributor 1,1
Si un suscriptor de SQL Managed Instance 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 del suscriptor. En el caso de una conmutación por error, la acción posterior por parte del administrador de instancia administrada 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, la replicación también funcionará. Se replicarán de nuevo los cambios perdidos.
- En 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 Instancia administrada de SQL tiene que reinicializar la base de datos de suscripciones.
Pasos siguientes
Para obtener más información sobre la configuración de la replicación transaccional, vea los siguientes tutoriales:
- Configuración de la replicación entre un publicador y un suscriptor de Instancia administrada de SQL
- Configuración de la replicación entre un publicador de Instancia administrada de SQL, un distribuidor de Instancia administrada de SQL y un suscriptor de SQL Server
- Cree una publicación.
- Creación de una suscripción de inserción mediante el nombre del servidor como suscriptor (por ejemplo,
N'azuresqldbdns.database.windows.net) y el nombre de Azure SQL Database como base de datos de destino (por ejemplo, AdventureWorks. )
Consulte también
- Replicación con Instancia administrada de SQL y un grupo de conmutación por error
- Replicación en SQL Database
- Replicación en una instancia administrada
- Create a Publication (Creación de una publicación)
- Create a Push Subscription (Creación de una suscripción de inserción)
- Tipos de replicación
- Supervisión (replicación)
- Inicializar una suscripción