Información general del servicio de reproducción del registro con Azure SQL Managed Instance

Se aplica a: Azure SQL Managed Instance

En este artículo se proporciona información general sobre el servicio de reproducción del registro (LRS), que se puede usar para migrar bases de datos de SQL Server a Azure SQL Managed Instance. LRS es un servicio en la nube gratuito disponible para Azure SQL Managed Instance y basado en la tecnología de trasvase de registros de SQL Server.

Dado que LRS restaura los archivos de copia de seguridad estándar de SQL Server, puedes usarlo para migrar desde SQL Server hospedado en cualquier lugar (ya sea local o en cualquier nube) a Azure SQL Managed Instance.

Para iniciar la migración con LRS, consulta Migración de bases de datos mediante Servicio de reproducción de registros.

Importante

Antes de que migre bases de datos al nivel de servicio Crítico para la empresa, debe tener en cuenta estas limitaciones, que no se aplican al nivel de servicio De uso general.

Cuándo usar el servicio de reproducción de registros

Azure Database Migration Service, la extensión de migración de Azure SQL para Azure Data Studio y LRS usan la misma tecnología y las APIs de migración subyacentes. LRS posibilita aún más las migraciones personalizadas complejas y las arquitecturas híbridas entre instancias de SQL Server locales e implementaciones de SQL Managed Instance.

Si no puede usar Azure Database Migration Service o la extensión de Azure SQL para la migración, emplee LRS directamente con PowerShell, los cmdlets de la CLI de Azure o las APIs para compilar y organizar manualmente las migraciones de base de datos a las implementaciones de SQL Managed Instance.

Considere la posibilidad de usar LRS en los siguientes casos, cuando:

• Necesita más control sobre el proyecto de migración de base de datos.
• Hay poca tolerancia al tiempo de inactividad en la transición de la migración.
• En su entorno no se puede instalar el archivo ejecutable de Database Migration Service.
• El archivo ejecutable de Database Migration Service no tiene acceso a los archivos de copia de seguridad de la base de datos.
• La extensión de migración de Azure SQL no se puede instalar en tu entorno o no puede acceder a las copias de seguridad de la base de datos.
• No dispone de acceso al sistema operativo del host o no tiene privilegios de administrador.
• No puede abrir puertos de red entre su entorno y Azure.
• Existe un límite de red o problemas de bloqueo del proxy en el entorno.
• Las copias de seguridad se almacenan directamente en cuentas de Azure Blob Storage con la opción TO URL.
• Necesita usar copias de seguridad diferenciales.

Dado que LRS funciona restaurando los archivos de copia de seguridad estándar de SQL Server, debe admitir migraciones desde cualquier origen. Se han probado los siguientes recursos:

• SQL Server local/box
• SQL Server en Virtual Machines
• Amazon EC2 (Elastic Compute Cloud)
• Amazon RDS (Relational Database Service) para SQL Server
• Google Compute Engine
• Cloud SQL para SQL Server: GCP (Google Cloud Platform)
• Alibaba Cloud RDS para SQL Server

Si experimentas problemas inesperados al migrar desde un origen no enumerado, abre una incidencia de soporte técnico para obtener ayuda.

Nota:

• Se recomienda automatizar la migración de bases de datos de SQL Server a Azure SQL Managed Instance mediante la extensión de migración de Azure SQL para Azure Data Studio. Considera usar LRS para orquestar las migraciones cuando la extensión de migración de Azure SQL no sea totalmente compatible con tus escenarios.
• LRS es el único método para restaurar copias de seguridad diferenciales en las instancias administradas. No es posible restaurar manualmente las copias de seguridad diferenciales en las instancias administradas ni establecer el modo NORECOVERY manualmente mediante T-SQL.

Funcionamiento de LRS

Crear una solución personalizada para migrar bases de datos a la nube con LRS requiere varios pasos de orquestación, como se muestra en el diagrama y en la tabla más adelante en esta sección.

La migración consiste en hacer copias de seguridad de la base de datos en SQL Server y copiar después los archivos de copia de seguridad en una cuenta de Azure Blob Storage. Se admiten copias de seguridad completas, de registro y diferenciales. A continuación, se usa el servicio en la nube de LRS para restaurar los archivos de copia de seguridad de la cuenta de Azure Blob Storage en SQL Managed Instance. La cuenta de Blob Storage sirve como almacenamiento intermedio para los archivos de copia de seguridad entre SQL Server y SQL Managed Instance.

LRS supervisa la cuenta de Blob Storage para comprobar si se han agregado nuevas copias de seguridad diferenciales o de registros después de haber restaurado la copia de seguridad completa. Si las hay, restaura automáticamente esos nuevos archivos. Puede usar el servicio para supervisar el progreso de los archivos de copia de seguridad que se están restaurando en SQL Managed Instance y detener el proceso si es necesario.

LRS no requiere que los archivos de copia de seguridad sigan una convención de nomenclatura determinada. Examina todos los archivos colocados en la cuenta de Azure Blob Storage y genera la cadena de copia de seguridad a partir de la lectura de los encabezados de archivo únicamente. Las bases de datos se encuentran en estado Restauración en curso durante el proceso de migración. Las bases de datos se restauran en modo NORECOVERY, por lo que no se pueden usar para cargas de trabajo de lectura ni de escritura hasta que finalice el proceso de migración.

Si va a migrar varias bases de datos, necesitará hacer lo siguiente:

• Coloque los archivos de copia de seguridad de cada base de datos en una carpeta independiente en la cuenta de Blob Storage en una estructura de archivos planos. Por ejemplo, use carpetas de base de datos independientes: blobcontainer/database1/files, blobcontainer/database2/files, etc.
• No use carpetas anidadas dentro de las carpetas de base de datos, ya que la estructura de carpetas anidadas no se admite. Por ejemplo, no use subcarpetas como blobcontainer/database1/subfolder/files.
• Iniciar LRS por separado para cada base de datos.
• Especifique rutas de acceso de identificador URI diferentes para separar las carpetas de base de datos en la cuenta de Blob Storage.

Aunque no es necesario tener CHECKSUM habilitado para copias de seguridad, se recomienda encarecidamente. La restauración de bases de datos sin CHECKSUM tarda más tiempo porque SQL Managed Instance realiza una comprobación de integridad en las copias de seguridad que se restauran sin tener CHECKSUM habilitado.

Para más información, consulte Migración de bases de datos de SQL Server a SQL Managed Instance mediante el servicio de reproducción de registros (versión preliminar).

Precaución

Se recomienda encarecidamente realizar copias de seguridad en SQL Server con CHECKSUM habilitado, ya que de otro modo existe el riesgo de restaurar una base de datos dañada en Azure.

Migración con el modo autocompletar frente al modo continuo

Puede iniciar LRS en modo autocompletar o continuo.

Use el modo autocompletar en los casos en los que la cadena de copia de seguridad entera esté generada de antemano y cuando no planee agregar más archivos después de haber iniciado la migración. Este modo de migración se recomienda para cargas de trabajo pasivas que no requieren puesta al día de los datos. Cargue todos los archivos de copia de seguridad en la cuenta de Blob Storage e inicie la migración en modo autocompletar. La migración finalizará de forma automática cuando se restaure el último archivo de copia de seguridad especificado. La base de datos migrada estará disponible para el acceso de lectura y escritura en SQL Managed Instance.

Si planea seguir agregando nuevos archivos de copia de seguridad mientras la migración está en curso, use el modo continuo. Se recomienda este modo para las cargas de trabajo activas que requieran la actualización de los datos. Cargue la cadena de copia de seguridad disponible actualmente en la cuenta de Blob Storage, inicie la migración en modo continuo y siga agregando nuevos archivos de copia de seguridad de la carga de trabajo según sea necesario. El sistema examinará periódicamente la carpeta de Azure Blob Storage y restaurará los nuevos archivos de copia de seguridad diferenciales o de registro que encuentre.

Cuando esté listo para la transición, detenga la carga de trabajo en la instancia de SQL Server, genere el último archivo de copia de seguridad y, a continuación, cárguelo. Para asegurarse de que el último archivo de copia de seguridad se ha restaurado, compruebe que la última copia de seguridad de la cola de registros se muestre como restaurada en SQL Managed Instance. A continuación, inicie la transición manual. En el paso final de la transición, la base de datos pasa a estar en línea y disponible para el acceso de lectura y escritura en SQL Managed Instance.

Una vez detenido LRS, ya sea automáticamente con autocompletar o manualmente con la migración total, no se puede reanudar el proceso de restauración de una base de datos que pasó a estar en línea en SQL Managed Instance. Por ejemplo, después de finalizar la migración, ya no podrá restaurar copias de seguridad diferenciales adicionales para una base de datos en línea. Para restaurar más archivos de copia de seguridad después de finalizar la migración, debe eliminar la base de datos de la instancia administrada y reiniciar la migración desde el principio.

Flujo de trabajo de migración

En la imagen siguiente se muestra un flujo de trabajo de migración típico y en la tabla se describen los pasos.

Solo debe usar el modo autocompletar cuando todos los archivos de la cadena de copia de seguridad estén disponibles de antemano. Este modo se recomienda para cargas de trabajo pasivas para las que no se requiere ninguna actualización de los datos.

Use la migración en modo continuo cuando no tenga la cadena de copia de seguridad entera de antemano y cuando planee agregar nuevos archivos de copia de seguridad una vez que la migración esté en curso. Este modo se recomienda para cargas de trabajo activas para las que se requiere la actualización de los datos.

Operación	Detalles
1. Copie las copias de seguridad de la base de datos de la instancia de SQL Server en la cuenta de Blob Storage.	Realice copias de seguridad completas, diferenciales y de registros de la instancia de SQL Server en el contenedor de Blob Storage mediante AzCopy o el Explorador de Azure Storage. Use cualquier nombre de archivo. En LRS no hace falta seguir una convención de nomenclatura de archivos específica. Si está migrando varias bases de datos, utilice una carpeta independiente para cada una de ellas.
2. Inicie LRS en la nube.	Puede iniciar el servicio con PowerShell (start-azsqlinstancedatabaselogreplay) o la CLI de Azure (cmdlets az_sql_midb_log_replay_start). Elija entre los modos de migración continua o de autocompletar. Inicie LRS por separado para cada base de datos que apunte a una carpeta de copia de seguridad en la cuenta de Blob Storage. Una vez iniciado el servicio, este realiza copias de seguridad del contenedor de Blob Storage y comienza a restaurarlas en SQL Managed Instance. Cuando LRS se inicia en modo autocompletar, restaura todas las copias de seguridad hasta el último archivo de copia de seguridad especificado. Todos los archivos de copia de seguridad deben cargarse de antemano y no es posible agregar archivos de copia de seguridad nuevos mientras la migración está en curso. Este modo se recomienda para cargas de trabajo pasivas para las que no se requiere ninguna puesta al día de datos. Cuando LRS se inicia en modo continuo, restaura todas las copias de seguridad cargadas inicialmente y, a continuación, supervisa los nuevos archivos que se han cargado en la carpeta. El servicio aplica registros continuamente en función de la cadena de número de secuencia de registro (LSN) hasta que se detenga de forma manual. Este modo se recomienda para cargas de trabajo activas para las que se requiere la actualización de los datos.
2.1. Supervisión del progreso de la operación.	Puede supervisar el progreso de la operación de restauración en curso con PowerShell (get-azsqlinstancedatabaselogreplay) o la CLI de Azure (cmdlets az_sql_midb_log_replay_show). Para rastrear detalles adicionales sobre una solicitud fallida, utilice el comando de PowerShell Get-AzSqlInstanceOperation o utilice el comando de la CLI de Azure az sql mi op show.
2.2. Detención de la operación si fuera necesario (opcional).	Si tiene que detener el proceso de migración, use PowerShell (stop-azsqlinstancedatabaselogreplay) o la CLI de Azure (az_sql_midb_log_replay_stop). La detención de la operación elimina la base de datos que se está restaurando en SQL Managed Instance. Después de detener una operación, no se puede reanudar el servicio LRS para una base de datos. Debe reiniciar el proceso de migración desde el principio.
3. Realice la migración total a la nube cuando esté listo.	Cuando se inicia LRS en modo autocompletar, la migración finaliza automáticamente después de que el último archivo de copia de seguridad especificado se haya restaurado. Si LRS se ha iniciado en modo continuo, detenga la aplicación y la carga de trabajo. Realice la última copia de seguridad de la cola de registros y cárguela en la implementación de Azure Blob Storage. Asegúrese de que se haya restaurado la última copia de seguridad de la cola de registros en la instancia administrada. Complete la transición de la migración iniciando una operación complete de LRS con PowerShell (complete-azsqlinstancedatabaselogreplay) o la CLI de Azure (az_sql_midb_log_replay_complete). Esta operación detiene LRS y hace que la base de datos pase a estar en línea para cargas de trabajo de lectura y escritura en SQL Managed Instance. Vuelva a apuntar la cadena de conexión de la aplicación de la instancia de SQL Server a SQL Managed Instance. Debe organizar este paso por sí mismo, ya sea mediante un cambio manual en la cadena de conexión de la aplicación o automáticamente (por ejemplo, si la aplicación puede leer la cadena de conexión de una propiedad o una base de datos).

Importante

Una vez realizada la migración, la instancia administrada de SQL con el nivel de servicio Business Critical puede tardar mucho más tiempo en estar disponible que la instancia De uso general, ya que deben generarse tres réplicas secundarias para el grupo de disponibilidad. La duración de esta operación depende del tamaño de los datos. Para más información, consulte Duración de las operaciones de administración.

Migración de bases de datos grandes

Si va a migrar bases de datos de gran tamaño de varios terabytes, tenga en cuenta lo siguiente:

• Un trabajo LRS único se puede ejecutar durante un máximo de 30 días. Cuando este período expira, el trabajo se cancela automáticamente.
• Para los trabajos de larga duración, las actualizaciones del sistema interrumpirán y prolongarán los trabajos de migración. Se recomienda encarecidamente usar una ventana de mantenimiento para programar las actualizaciones planeadas del sistema. Planee la migración en torno a la ventana de mantenimiento programado.
• Los trabajos de migración interrumpidos por las actualizaciones del sistema se suspenden y reanudan automáticamente para instancias administradas De uso general y se reinician para instancias administradas Crítico para la empresa. Estas actualizaciones afectan al período de tiempo de la migración.
• Para aumentar la velocidad de carga de los archivos de copia de seguridad de SQL Server a la cuenta de Blob Storage, si la infraestructura tiene suficiente ancho de banda de red, considere la posibilidad de usar la paralelización con varios subprocesos.

Inicio de la migración

La migración se inicia al iniciar LRS. Puede iniciar el servicio en modo autocompletar o continuo. Para obtener detalles específicos, consulte Migración con LRS.

• Modo autocompletar. Cuando se utiliza el modo autocompletar, la migración finaliza automáticamente cuando se haya restaurado el último de los archivos de copia de seguridad especificados. Esta opción:

  • Requiere que toda la cadena de copia de seguridad esté disponible de antemano y se cargue en la cuenta de Azure Blob Storage.
  • No permite agregar nuevos archivos de copia de seguridad mientras la migración está en curso.
  • Requiere el comando de inicio para especificar el nombre de archivo del último archivo de copia de seguridad.

  Se recomienda usar el modo autocompletar para cargas de trabajo pasivas para las que no se requiere la actualización de los datos.

• Modo continuo. Cuando se usa el modo continuo, el servicio examina continuamente la carpeta de Azure Blob Storage y restaura los nuevos archivos de copia de seguridad que se agreguen mientras la migración está en curso.

  La migración solo finaliza después de que se haya solicitado la transición manual.

  La migración en modo continuo se debe usar cuando no se tenga la cadena de copia de seguridad entera de antemano y cuando planee agregar nuevos archivos de copia de seguridad una vez que la migración esté en curso.

  Se recomienda usar el modo continuo para cargas de trabajo activas para las que se requiere la actualización de los datos.

Planee finalizar un único trabajo de migración de LRS en un máximo de 30 días. Cuando este período expira, el trabajo LRS se cancela automáticamente.

Nota:

Al migrar varias bases de datos, cada base de datos debe estar en su propia carpeta. LRS debe iniciarse por separado para cada base de datos, apuntando a la ruta de acceso URI completa del contenedor de Azure Blob Storage y a la carpeta de base de datos individual. No se admiten carpetas anidadas dentro de las carpetas de base de datos.

Limitaciones de LRS

Para obtener información, revise limitaciones al usar LRS.

Pasos siguientes

• Para más información, consulte Migración de bases de datos de SQL Server a SQL Managed Instance mediante el servicio de reproducción de registros (versión preliminar).

• Consulte más información sobre la migración de bases de datos a SQL Managed Instance con la característica de vínculo.

• Obtenga más información sobre la migración de bases de datos de SQL Server a SQL Managed Instance.

• Obtenga más información sobre las diferencias entre SQL Server y SQL Managed Instance.

• Obtenga más información sobre los procedimientos recomendados para administrar los costos y el tamaño de las cargas de trabajo migradas a Azure.