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

  • Artículo

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.

Para empezar, consulte Migración de bases de datos de SQL Server a Azure SQL Managed Instance mediante el servicio de reproducción del registro.

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.

Se admiten los siguientes orígenes:

  • 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)

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.

Diagrama que muestra los pasos de orquestación del servicio de reproducción del registro 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. 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 con PowerShell (get-azsqlinstancedatabaselogreplay) o la CLI de Azure (cmdlets az_sql_midb_log_replay_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).

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

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, LRS se debe iniciar por separado para cada base de datos que apunte a la ruta de acceso de identificador URI completa del contenedor de Azure Blob Storage y la carpeta de base de datos individual.

Limitaciones de LRS

Tenga en cuenta las siguientes limitaciones de LRS:

  • LRS solo admite archivos de base de datos .bak, .logy .diff . No se admiten archivos Dacpac y bacpac.
  • Durante el proceso de migración, las bases de datos que se están migrando no se pueden usar para el acceso de solo lectura en SQL Managed Instance.
  • Tiene que configurar una ventana de mantenimiento para permitir la programación de actualizaciones del sistema en un día y hora específicos. Planee la ejecución y finalización de migraciones fuera de la ventana de mantenimiento programado.
  • Las copias de seguridad de base de datos que se realizan sin CHECKSUM tardan más tiempo en restaurarse que las copias de seguridad de base de datos con CHECKSUM habilitado.
  • El token de firma de acceso compartido (SAS) que LRS utiliza se debe generar para todo el contenedor de Azure Blob Storage y solo debe tener permisos de lectura y enumeración. Por ejemplo, si concede permisos de lectura, enumeración y escritura, LRS no se podrá iniciar debido al permiso de escritura adicional.
  • No se admite el uso de tokens de SAS creados con permisos que se hayan establecido con la definición de una directiva de acceso almacenada. Siga las instrucciones de este artículo para especificar manualmente permisos de lectura y enumeración para el token de SAS.
  • Los archivos de copia de seguridad de bases de datos distintas deben colocarse en carpetas independientes en la cuenta de Blob Storage en una estructura de archivos planos. No se admite el anidamiento de carpetas en las carpetas de base de datos.
  • Si usa el modo autocompletar, toda la cadena de copia de seguridad debe estar disponible con antelación en la cuenta de Blob Storage. No es posible agregar nuevos archivos de copia de seguridad en modo de autocompletar. Use el modo continuo si necesita agregar nuevos archivos de copia de seguridad mientras la migración está en curso.
  • LRS debe iniciarse por separado para cada base de datos que apunte a la ruta de URI completa que contiene una carpeta de base de datos individual.
  • La ruta de acceso del URI de copia de seguridad, el nombre del contenedor o los nombres de carpeta no deben contener backup ni backups ya que son palabras clave reservadas.
  • Al iniciar varias restauraciones de Reproducción de registros en paralelo en las que el destino es el mismo contenedor de almacenamiento, asegúrese de que se proporciona el mismo token de SAS válido para cada operación de restauración.
  • LRS puede admitir hasta 100 procesos de restauración simultáneos por cada instancia administrada.
  • Un trabajo LRS único se puede ejecutar durante un máximo de 30 días, después de los cuales se cancelará automáticamente.
  • Aunque es posible usar una cuenta de Azure Storage detrás de un firewall, se necesita una configuración adicional, y la cuenta de almacenamiento y la instancia administrada deben estar en la misma región o en dos regiones emparejadas. Consulte Configuración del firewall para obtener más información.
  • El número máximo de bases de datos que puede restaurar en paralelo es de 200 por cada suscripción. En algunos casos, es posible aumentar este límite abriendo una incidencia de soporte técnico.

Sugerencia

Si necesita que una base de datos tenga acceso de solo lectura durante la migración, con un período de tiempo mucho más largo para realizar la migración y un tiempo de inactividad mínimo, considere la posibilidad de usar la característica de vínculo de Azure SQL Managed Instance como solución de migración recomendada.

Pasos siguientes