Migración con el vínculo: Azure SQL Managed Instance

Se aplica a:Azure SQL Managed Instance

En este artículo se explica cómo migrar la base de datos de SQL Server a Azure SQL Managed Instance mediante el vínculo Instancia administrada.

Para obtener una guía de migración detallada, revise Migrate a Azure SQL Managed Instance. Para comparar las herramientas de migración, revise el enlace de Compare LRS con Instancia administrada.

Nota:

Ahora puede migrar la instancia de SQL Server habilitada Azure Arc a Azure SQL Managed Instance directamente a través del portal de Azure. Para obtener más información, vea Migrate a Azure SQL Managed Instance.

Información general

El vínculo de Instancia administrada permite la migración desde SQL Server hospedado en cualquier lugar hasta Azure SQL Managed Instance. El vínculo usa la tecnología del grupo de disponibilidad AlwaysOn para replicar los cambios casi en tiempo real desde la instancia de SQL Server principal a la SQL Managed Instance secundaria. El vínculo proporciona la única opción de migración verdaderamente en línea entre SQL Server y Azure SQL Managed Instance, ya que el único tiempo de inactividad está transicionando a la SQL Managed Instance de destino.

La migración con el vínculo proporciona lo siguiente:

  • La capacidad de probar las cargas de trabajo de solo lectura en SQL Managed Instance antes de finalizar la migración a Azure.
  • La capacidad de mantener el vínculo y la migración en ejecución durante el tiempo que necesite, incluso durante semanas o meses de forma continua.
  • Replicación casi en tiempo real de datos que proporciona la replicación de datos más rápida disponible para Azure.
  • La migración con el tiempo de inactividad más mínimo en comparación con todas las demás soluciones disponibles en la actualidad.
  • Migración instantánea al SQL Managed Instance de destino.
  • La capacidad de migrar en cualquier momento en que esté preparado.
  • La capacidad de migrar una o varias bases de datos de una o varias instancias de SQL Server a las mismas o varias instancias administradas de SQL en Azure.
  • La única migración en línea verdadera al nivel de servicio Crítico para la empresa.

Nota:

Aunque solo puede migrar una base de datos por vínculo, puede establecer varios vínculos desde la misma instancia de SQL Server a la misma SQL Managed Instance.

Comportamiento de la conmutación

El comportamiento de transición depende de la versión de SQL Server desde la que va a migrar y de la directiva de actualización de la SQL Managed Instance de destino:

  • Para SQL Server 2016 a SQL Server 2019, la transición a SQL Managed Instance quita el vínculo.
  • Para SQL Server 2022 o versiones posteriores, el cambio a SQL Managed Instance puede eliminar o mantener el vínculo, según la opción que elija durante la conmutación por error. Si decide mantener el vínculo y la instancia administrada de SQL está configurada con una directiva de actualización coincidente, puede revertir la migración a SQL Server si es necesario.

Para la migración, quitar el vínculo es la opción recomendada. Si decide mantener el vínculo, pero más adelante decide quitarlo, espere a que Azure complete la primera copia de seguridad completa de la base de datos después de la conmutación por error antes de quitar el vínculo. Este paso garantiza que la base de datos sea correcta y totalmente funcional en SQL Managed Instance. También ayuda a evitar un problema conocido poco frecuente en el que la base de datos puede dejar de estar disponible temporalmente después de reiniciar un servidor si el vínculo se quita demasiado pronto. Para obtener más información, consulte La base de datos deja de estar disponible tras reiniciar el servidor después de la conmutación por error del enlace de MI.

Invertir una migración

Es posible que se admita la migración inversa a SQL Server desde Azure SQL Managed Instance en función de la política de actualización de la instancia administrada de SQL. Por ejemplo:

Si la versión de SQL Server de origen es anterior a SQL Server 2022, no es posible realizar la migración inversa. Al migrar la base de datos a SQL Managed Instance, se somete a una actualización interna a una versión de base de datos más reciente que no sea compatible con versiones anteriores de SQL Server. La compatibilidad con la base de datos de migración inversa solo está disponible cuando SQL Managed Instance está configurado con la directiva de actualización correspondiente.

Requisitos previos

Para usar el vínculo con Azure SQL Managed Instance para la migración, necesita los siguientes requisitos previos:

Evaluación y detección

Después de comprobar que se admite el entorno de origen, comience con la fase previa a la migración. Detecte todos los orígenes de datos existentes, evalúe la viabilidad de la migración e identifique los problemas de bloqueos que podrían impedir la migración. En la fase Detección, examine la red para identificar todas las instancias y características de SQL Server que usa la organización.

Puede usar las siguientes herramientas para descrbrir orígenes SQL en su entorno:

  • SQL Server habilitado por Azure Arc: SQL Server habilitado por Azure Arc genera automáticamente una evaluación para la migración a Azure, lo que simplifica el proceso de detección y la evaluación de preparación para la migración.
  • Azure Migrate para evaluar la idoneidad de la migración de los servidores locales, realizar el ajuste de tamaño basado en el rendimiento y proporcionar estimaciones de costos para ejecutarlas en Azure.
  • Microsoft Assessment and Planning Toolkit ("MAP Toolkit") para evaluar la infraestructura de TI actual. El kit de herramientas proporciona una herramienta de inventario, evaluación y generación de informes eficaz para simplificar el proceso de planeamiento de la migración.

Una vez detectados orígenes de datos, evalúe las instancias de SQL Server locales que se pueden migrar a Azure SQL Managed Instance para identificar problemas de compatibilidad o bloqueadores de migración.

Puede usar la evaluación de preparación para la migración para evaluar la instancia de SQL Server de origen.

Para obtener instrucciones detalladas, revise los pasos previos a la migración.

Creación de una instancia de destino

Después de evaluar el entorno existente y determinar la configuración de hardware y el nivel de servicio adecuados para la instancia administrada de SQL de destino, implemente la instancia de destino mediante el portal Azure portal, PowerShell o el CLI de Azure.

Una vez creada la instancia administrada de SQL de destino, configure un vínculo entre la base de datos de la instancia de SQL Server y Azure SQL Managed Instance. En primer lugar, prepare el entorno y, después, configure un vínculo mediante SQL Server Management Studio (SSMS) o scripts.

Comprobación del retraso de replicación

Es importante que la réplica secundaria se ponga al día con la réplica principal antes de realizar una conmutación por error de migración planificada. La conmutación por error planificada puede agotar el tiempo de espera y generar un error si la réplica secundaria va muy por detrás de la réplica principal.

Use la siguiente consulta de T-SQL en SQL Server y SQL Managed Instance para supervisar el retraso de replicación entre las réplicas:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Si el retraso de replicación es alto, espere a que la réplica secundaria alcance a la réplica principal. Es posible que tenga que realizar pasos adicionales para solucionar problemas si el retraso persiste, como pausar cargas de trabajo en la réplica principal, mejorar el rendimiento de la red de vínculos entre las dos instancias o aumentar la capacidad de recursos en la réplica secundaria. La manera más fácil de detener las cargas de trabajo en una réplica principal de SQL Server consiste en cortar las conexiones de aplicación a la instancia.

Migración de varias bases de datos

Si tiene previsto migrar varias bases de datos de instancias en el mismo servidor, para obtener un rendimiento y una previsibilidad óptimos, migre 8 bases de datos por instancia a la vez. Por ejemplo, si tiene 10 instancias con 32 bases de datos vinculadas cada una, migre 8 bases de datos a la vez desde cada instancia mediante conmutaciones por error planeadas y repita el proceso hasta que se migren todas las bases de datos.

Sincronización y transición de datos

Una vez establecido el vínculo y cuando esté a punto para realizar la migración, siga estos pasos (normalmente durante una ventana de mantenimiento):

  1. Detenga la carga de trabajo en la base de datos principal SQL Server para que la base de datos secundaria en SQL Managed Instance se ponga al día. La manera más fácil de detener las cargas de trabajo en una réplica principal de SQL Server consiste en cortar las conexiones de aplicación a la instancia.
  2. Valide que todos los datos hayan sido transferidos a la base de datos secundaria en SQL Managed Instance. Compruebe el retraso de replicación para asegurarse de que la réplica secundaria esté sincronizada con la réplica principal.
  3. Realice una conmutación por error del vínculo a la instancia administrada de SQL secundaria; para ello, elija Conmutación por error planeada.
  4. (Opcional) Marque la casilla Eliminar el enlace tras una conmutación por error satisfactoria para garantizar que la conmutación por error sea unidireccional y que se elimine el enlace.
  5. (Opcional) Si utiliza una versión compatible de SQL Server con una directiva de actualización de SQL Managed Instance que coincida, puede mantener el enlace tras la conmutación por error para revertir una migración si fuera necesario. Consulte la sección revertir una migración para obtener detalles específicos de la versión.
  6. Transicione la aplicación para conectarse al punto de conexión de SQL Managed Instance.
  7. (Opcional) Si no has optado por eliminar el enlace durante la conmutación por error, puedes hacerlo tras la conmutación definitiva, una vez que ya no lo necesites.

Validación de la migración

Después de transicionar al destino de la instancia administrada de SQL, supervise la aplicación, pruebe el rendimiento y corrija los problemas.

Para obtener más información, revise los pasos posteriores a la migración.

Problemas conocidos con la migración

Revise los siguientes problemas conocidos relacionados con la migración con el vínculo.

En raras circunstancias, su base de datos podría dejar de estar disponible temporalmente en SQL Managed Instance tras reiniciarse el servidor después de la conmutación por error del vínculo. Este problema conocido se produce cuando se elimina un vínculo antes de que Azure complete una copia de seguridad completa de la base de datos después de la conmutación por error inicial a una Instancia administrada de SQL.

La base de datos se recupera automáticamente después de la intervención de Microsoft, pero esta recuperación puede tardar algún tiempo.

Para evitar este problema, no quite el vínculo hasta que finalice la primera copia de seguridad completa después de la conmutación por error de SQL Server a SQL Managed Instance. Para obtener más información, consulte Base de datos no disponible después del reinicio del servidor.

Errores de operación de restauración después de migrar a SQL Managed Instance

Si migra una base de datos a Azure SQL Managed Instance desde SQL Server 2019 y versiones posteriores con recuperación de base de datos acelerada habilitada, pero configurada con el almacén de versiones persistente (PVS) establecido en algo distinto del grupo de archivos PRIMARY, puede experimentar errores en la operación de restauración en la instancia administrada de SQL de destino.

Para solucionar este problema, asegúrese de establecer el almacén de versiones persistente (PVS) en PRIMARY en la base de datos de SQL Server de origen antes de migrarlo a SQL Managed Instance. Si ya ha migrado la base de datos sin haber establecido el PVS en PRIMARY, puede configurarlo en la base de datos de SQL Server de origen y, a continuación, migrar nuevamente la base de datos a SQL Managed Instance.

No se puede usar la recuperación acelerada de la base de datos después de migrar a SQL Managed Instance

A partir de SQL Server 2019, si migra una base de datos a Azure SQL Managed Instance y la recuperación acelerada de la base de datos está deshabilitada en la base de datos de origen, no se puede usar la recuperación acelerada de la base de datos en la instancia administrada de SQL de destino.

Para solucionar este problema, asegúrese de habilitar la recuperación acelerada de bases de datos en la base de datos de SQL Server de origen antes de migrarla a SQL Managed Instance. Si ya ha migrado la base de datos sin habilitar la recuperación acelerada de la base de datos, puede habilitarla en la base de datos de SQL Server de origen y, a continuación, volver a migrar la base de datos a la instancia administrada de SQL.

SQL Server 2017 y versiones anteriores no admiten la recuperación acelerada de bases de datos, por lo que este problema no se aplica a las bases de datos migradas desde esas versiones de SQL Server.

No se puede usar Service Broker después de migrar a SQL Managed Instance

Si migra una base de datos a Azure SQL Managed Instance y Service Broker está deshabilitado en la base de datos de origen, no puede usar Service Broker en la instancia administrada de SQL de destino.

Para solucionar este problema, asegúrese de habilitar Service Broker en la base de datos de SQL Server de origen antes de migrarla a SQL Managed Instance. Si ya ha migrado la base de datos sin habilitar Service Broker, puede habilitarla en la base de datos de SQL Server de origen y, a continuación, volver a migrar la base de datos a SQL Managed Instance.

Contenido relacionado

Para usar el vínculo:

Para más información sobre el vínculo:

Para otros escenarios de replicación y migración, considere lo siguiente:

  • Last updated on