Compartir a través de

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 se basa en la tecnología de trasvase de registros de SQL Server.

Nota:

Ahora puede migrar la instancia de SQL Server habilitada por Azure Arc a Azure SQL Managed Instance directamente a través de Azure Portal. Para más información, consulte Migración a Azure SQL Managed Instance.

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

Para iniciar la migración con LRS, revise Migración de bases de datos desde SQL Server mediante log Replay Service.

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 casos siguientes:

  • 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.
  • No puede instalar el archivo ejecutable de Database Migration Service en su entorno.
  • El archivo ejecutable de Database Migration Service no tiene acceso a los archivos de copia de seguridad de la base de datos.
  • No puede instalar la extensión de migración de Azure SQL en su entorno o no puede acceder a las copias de seguridad de la base de datos.
  • No tiene acceso al sistema operativo host ni a los privilegios de administrador.
  • No puede abrir puertos de red entre su entorno y Azure.
  • Existen problemas de bloqueo de proxy o limitación de red en su 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 archivos de copia de seguridad estándar de SQL Server, admite migraciones desde cualquier origen. Se han probado las siguientes fuentes.

  • SQL Server local/caja
  • 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:

  • LRS es el único método para restaurar copias de seguridad diferenciales en instancias administradas de SQL. No es posible restaurar manualmente copias de seguridad diferenciales en instancias administradas ni establecer manualmente el NORECOVERY modo 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. LRS admite 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 las nuevas copias de seguridad diferenciales o de registro que agregue después de restaurar la copia de seguridad completa. LRS luego restaura automáticamente estos 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 en proceso de restauración durante el proceso de migración. LRS restaura las bases de datos en modo NORECOVERY , por lo que no se pueden usar para cargas de trabajo de lectura o 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 diferentes rutas URI para separar los directorios de bases de datos en la cuenta de almacenamiento de blobs.

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 obtener más información, consulte Migración de bases de datos de SQL Server mediante log Replay Service.

Precaución

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

Migración con el modo autocompletar frente al modo continuo

Puede iniciar LRS en modo autocompletar o continuo.

Use el modo autocompletar cuando tenga la cadena de copia de seguridad completa generada de antemano y, cuando ya no planee agregar archivos una vez iniciada 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 finaliza automáticamente cuando se restaura el último archivo de copia de seguridad especificado. La base de datos migrada está 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 examina periódicamente la carpeta Azure Blob Storage y restaura los archivos de copia de seguridad diferenciales o de registro nuevos 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. Asegúrese de que se restaure el último archivo de copia de seguridad comprobando que la copia de seguridad del tail-log se muestra 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.

Después de detener LRS, ya sea automáticamente a través de autocompletar o manualmente a través del cambio, no se puede reanudar el proceso de restauración de una base de datos que ha sido puesta 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

La imagen de esta sección muestra un flujo de trabajo de migración típico mientras la tabla describe los pasos.

Use el modo autocompletar solo cuando todos los archivos de cadena de copia de seguridad estén disponibles de antemano. Se recomienda este modo para cargas de trabajo pasivas que no requieran puesta al día 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. Se recomienda este modo para las cargas de trabajo activas que requieran la actualización de los datos.

Diagrama que muestra los pasos de orquestación de Log Replay Service para SQL Managed Instance.

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. Inicie el servicio con PowerShell (start-azsqlinstancedatabaselogreplay) o la CLI de Azure (az_sql_midb_log_replay_start cmdlets). 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.

Al iniciar LRS en modo de autocompletar, restaura todas las copias de seguridad a través del último archivo de copia de seguridad especificado. Debe cargar todos los archivos de copia de seguridad con antelación y no puede agregar ningún nuevo archivo de copia de seguridad mientras la migración está en curso. Este modo se recomienda para cargas de trabajo pasivas que no requieran puesta al día de los datos.

Al iniciar LRS en modo continuo, restaura todas las copias de seguridad que cargó inicialmente y, a continuación, busca los nuevos archivos que cargue 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. Se recomienda este modo para las cargas de trabajo activas que requieran la actualización de los datos.
2.1. Supervisión del progreso de la operación. Supervise el progreso de la operación de restauración en curso con PowerShell (get-azsqlinstancedatabaselogreplay) o la CLI de Azure (az_sql_midb_log_replay_show cmdlets). 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 necesita detener el proceso de migración, use PowerShell (stop-azsqlinstancedatabaselogreplay) o la interfaz de línea de comandos 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. Si inicia LRS en modo de autocompletar, la migración finaliza automáticamente después de restaurar el último archivo de copia de seguridad especificado.

Si inicia LRS 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 la última copia de seguridad de la cola de log se restaure en la instancia administrada de SQL. Complete la transició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 grandes de varios terabytes de tamaño, tenga en cuenta los siguientes puntos:

  • 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.
  • En el caso de los trabajos de larga duración, las actualizaciones del sistema pueden interrumpir y prolongar 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 que son interrumpidos por las actualizaciones del sistema se suspenden y reanudan automáticamente en las instancias administradas de SQL de uso general, y se reinician en las instancias administradas de SQL críticas 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

Inicie la migración al iniciar LRS. Puede iniciar el servicio en modo autocompletar o continuo. Para obtener detalles específicos, revise Migrar bases de datos desde SQL Server usando el Servicio de Reproducción de Registros.

  • Modo autocompletar. Cuando se usa el modo de autocompletar, la migración finaliza automáticamente cuando se restaura la última 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 finaliza solo después de solicitar la migración manual.

    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.

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

Contenido relacionado

  • Last updated on