Mirroring de SQL Server en Fabric: Gateway y Gestión de Cambios
El mirroring de SQL Server en Microsoft Fabric representa el fin de las ETLs tradicionales de extracción masiva. No estamos ante una simple copia de tablas; es una replicación continua basada en el registro de transacciones (Transaction Log) que deposita los datos directamente en OneLake en formato Delta Parquet. Para un consultor de Business Intelligence, esto supone pasar de procesos Batch nocturnos a un escenario de disponibilidad de datos casi en tiempo real (near-real-time).
Sin embargo, la implementación no es automática ni está exenta de fricciones. En proyectos reales de sectores como el retail o la industria, donde el SQL Server suele ser el motor de un ERP crítico, el mirroring exige una planificación quirúrgica. El objetivo de este artículo es detallar los requisitos de versión, la configuración del Gateway y, lo más importante, cómo gestionar la salud de esa réplica para que no se convierta en un punto ciego de nuestra arquitectura en OneLake y el ecosistema de Microsoft Fabric.
Antes de empezar, debemos entender que el Mirroring en Fabric no usa el motor de réplica clásico de SQL Server (como el Log Shipping o Always On). Utiliza una tecnología que lee el log de transacciones y lo envía a través del Gateway hacia el servicio de Fabric, donde un motor de ingesta transforma esos datos binarios en archivos Parquet comprimidos.
Requisitos técnicos y versiones mínimas
No cualquier instancia de SQL Server puede ser origen de un Mirroring en Fabric. El primer filtro es la versión. A diferencia de otras integraciones, aquí Microsoft ha sido estricto para garantizar la estabilidad del flujo de datos. Para entornos On-Premises (locales), el requisito mínimo es SQL Server 2022 con el Cumulative Update 6 (CU6) o superior.
Además de la versión, la base de datos debe cumplir con ciertas precondiciones técnicas que a menudo olvidamos en la fase de preventa:
- Modelo de recuperación (Recovery Model): Debe estar configurado en Full o Bulk-Logged. El modelo Simple no es compatible porque el mirroring necesita mantener la cadena de logs para leer los cambios.
- Service Broker: Debe estar habilitado. Es el mecanismo de mensajería interna que permite la comunicación de los eventos de cambio.
- Cifrado: Si la base de datos utiliza TDE (Transparent Data Encryption), debemos asegurar que el Gateway tiene acceso a los certificados correspondientes, aunque el flujo hacia Fabric cifra los datos en tránsito de forma nativa.
El Gateway: El puente crítico hacia OneLake
En el Mirroring de SQL Server local, el On-premises data gateway no es un simple pasapurés de consultas. Aquí actúa como el agente de transporte de los registros del log. He visto proyectos fracasar porque el Gateway se instaló en una máquina virtual infradimensionada, pensando que solo pasaría «un poco de tráfico».
El Gateway debe estar en la misma red que el SQL Server, con una latencia mínima. Cada vez que ocurre un COMMIT en tu base de datos de producción (Ventas, Stocks, etc.), el sistema de mirroring intenta enviar ese cambio. Si el Gateway tiene cuellos de botella en la CPU o en el ancho de banda de subida, el log de transacciones en el servidor origen empezará a crecer desmesuradamente porque SQL Server no podrá truncar el log hasta que Fabric confirme que ha recibido los datos.
Es vital que la versión del Gateway sea la más reciente. Microsoft lanza actualizaciones mensuales y las mejoras en la estabilidad de las conexiones de Mirroring son constantes, como ya analizamos en el artículo sobre Fabric September 2026: Implementación técnica y optimización de modelos en producción.
Configuración del entorno local (T-SQL)
Para preparar la base de datos, no basta con pulsar un botón en el portal de Fabric. Debemos ejecutar scripts de preparación que habiliten los permisos y las funcionalidades necesarias. Un error común es intentar configurar el mirroring con una cuenta de usuario con permisos limitados. Se requiere CONTROL SERVER o, al menos, ser db_owner de la base de datos específica.
-- 1. Habilitar Service Broker
ALTER DATABASE [GestionVentas] SET ENABLE_BROKER;
GO
-- 2. Crear una credencial específica para Fabric
-- Es recomendable no usar 'sa' por seguridad
CREATE LOGIN [FabricMirroringUser] WITH PASSWORD = 'TuPasswordSeguro123!';
CREATE USER [FabricMirroringUser] FOR LOGIN [FabricMirroringUser];
-- 3. Asignar permisos necesarios para leer el log y metadatos
GRANT VIEW SERVER STATE TO [FabricMirroringUser];
ALTER ROLE [db_owner] ADD MEMBER [FabricMirroringUser];
GO
Una vez ejecutado esto, el siguiente paso es la creación del ítem «Mirrored Azure SQL Database» (que también sirve para SQL Server On-Prem) en el espacio de trabajo de Fabric. Al configurar la conexión, seleccionaremos el Gateway previamente instalado. Es aquí donde ocurre la magia: Fabric detectará las tablas que tienen una Clave Primaria (Primary Key) definida. Sin Primary Key, no hay Mirroring. Es un requisito innegociable para la captura de cambios.
Monitorización de la réplica y salud del dato
Como consultores, nuestro trabajo no termina cuando los datos empiezan a fluir. Debemos establecer un sistema de vigilancia. ¿Qué pasa si el mirroring se detiene? La monitorización gratuita es posible mediante vistas de sistema en el propio SQL Server, algo que ya mencionamos al hablar de monitorización gratuita de SQL Server.
En el lado de Fabric, disponemos de una pestaña de «Monitorización» dentro del ítem de Mirroring. Nos muestra el estado de cada tabla: Initial replication, Running o Stopped. Pero la métrica que realmente importa es el Latency (Latencia). Si la latencia supera los 15-20 minutos en un entorno que debería ser near-real-time, tenemos un problema en la red o en el tamaño del log.
-- Consulta para verificar el estado de los componentes de réplica desde SQL Server
SELECT
name,
is_broker_enabled,
log_reuse_wait_desc -- Si dice 'EXTERNAL_REPLICATION', el log crece porque Fabric no lo ha leído
FROM sys.databases
WHERE name = 'GestionVentas';
Si el valor de log_reuse_wait_desc es EXTERNAL_REPLICATION de forma persistente, significa que Fabric está retrasado. Esto puede llenar el disco de tu servidor de producción, provocando una caída del servicio. Es el trade-off de esta tecnología: ganamos velocidad, pero acoplamos la salud del disco local a la velocidad de la nube.
Gestión de cambios de esquema (DDL)
Uno de los mayores dolores de cabeza en cualquier réplica son los cambios en la estructura de las tablas. Si un desarrollador añade una columna a la tabla Fact_Ventas, ¿qué ocurre en Fabric?
El mirroring de Fabric es relativamente resiliente a los cambios DDL (Data Definition Language). Si añades una columna, el proceso intentará propagarla. Sin embargo, hay operaciones que romperán la réplica:
- Cambiar el tipo de dato: Pasar de un
INTa unVARCHARen una columna existente suele detener la sincronización de esa tabla. - Eliminar la Primary Key: Esto detiene el mirroring inmediatamente para esa tabla.
- Renombrar tablas o columnas: Fabric perderá el linaje y marcará la tabla con error.
En estos casos, la solución suele ser «Stop Mirroring» para esa tabla específica, eliminar los datos en OneLake y volver a iniciar la réplica (re-snapshot). Es un proceso costoso en tiempo y computación, por lo que la gobernanza sobre los cambios de esquema en el origen es fundamental.
Comparativa: Mirroring vs. Shortcuts vs. Dataflows Gen2
A menudo me preguntan por qué usar Mirroring en lugar de conectarse directamente por un Shortcut o usar un Dataflow. La respuesta está en el impacto en el origen y la latencia.
| Característica | Mirroring | Shortcuts (VPC) | Dataflows Gen2 |
|---|---|---|---|
| Impacto en origen | Mínimo (lee el log) | Alto (consultas directas) | Medio (selects programadas) |
| Latencia | Segundos / Minutos | Tiempo real (Direct Lake) | Programada (Batch) |
| Transformación | No (Réplica 1:1) | No | Sí (Power Query) |
| Requisito PK | Obligatorio | No | No |
El Mirroring es imbatible cuando queremos una copia exacta de los datos operacionales en OneLake sin castigar el rendimiento del ERP con consultas pesadas de Power Query. Una vez los datos están en el Lakehouse vía Mirroring, podemos usar procedimientos almacenados en el SQL Analytics Endpoint para transformarlos a un modelo en estrella, aplicando los principios de conceptos avanzados de DAX sobre las vistas resultantes.
Errores frecuentes en entornos reales
A lo largo de varios despliegues, he identificado patrones de error que se repiten. Conocerlos te ahorrará horas de depuración:
- El Gateway entra en suspensión: Si el servidor donde reside el Gateway tiene políticas de ahorro de energía, la réplica se cortará.
- Tablas sin Primary Key: Es el error más común. A veces el ERP tiene tablas de log o temporales sin PK; estas tablas simplemente no aparecerán en la lista de Fabric.
- Falta de espacio en el disco de Logs: Al habilitar el mirroring, el log de transacciones no se libera tan rápido. Debes monitorizar el crecimiento del archivo
.ldf. - Conflictos de intercalación (Collation): Si tu base de datos usa una intercalación muy exótica, podrías ver caracteres extraños en los strings una vez llegan a los archivos Parquet en OneLake.
Conclusión y checklist
El Mirroring de SQL Server en Microsoft Fabric es la pieza que faltaba para unificar el mundo On-Premises con la potencia analítica de la nube sin los costes de desarrollo de una ETL compleja. Permite que el equipo de BI trabaje sobre datos frescos, permitiendo incluso el uso de Direct Lake en Power BI, lo que elimina la necesidad de refrescar datasets.
Sin embargo, requiere una mentalidad de administrador de base de datos tanto como de analista. Antes de activar el interruptor, asegúrate de cumplir este checklist:
- Confirmar SQL Server 2022 CU6+ y Service Broker activo.
- Verificar que todas las tablas de negocio tienen Primary Key.
- Instalar el Gateway en un servidor dedicado con alta disponibilidad.
- Configurar alertas de crecimiento del Transaction Log en el origen.
- Establecer un protocolo de comunicación con los desarrolladores del ERP ante cambios de esquema.
Preguntas frecuentes
¿Puedo filtrar qué columnas se replican en el mirroring?
Actualmente, el mirroring de Fabric permite seleccionar qué tablas quieres replicar, pero no filtrar columnas individuales dentro de una tabla. Se replica la fila completa para mantener la integridad del log de transacciones.
¿El mirroring consume unidades de capacidad (CU) de Fabric?
Sí, el proceso de ingesta y la transformación de los datos del log a formato Delta Parquet consume recursos de tu capacidad de Fabric. Es recomendable monitorizarlo con la app de Capacity Metrics para evitar estrangulamientos.
¿Qué pasa si mi SQL Server local se queda sin conexión a internet?
El mirroring se detendrá. Los cambios se seguirán acumulando en el log de transacciones local. Una vez recuperada la conexión, el Gateway enviará todos los cambios pendientes de forma secuencial hasta ponerse al día.
