Uso de Log Replay Service (LRS) para migrar
Log Replay Service (LRS) es una herramienta que permite migraciones personalizadas de bases de datos de servidores SQL Server locales a SQL Managed Instance en la nube. Usa la tecnología de trasvase de registros y es útil en los casos en los que se necesita más control, cuando hay poca tolerancia al tiempo de inactividad o cuando Azure Data Migration Service no se puede usar.
LRS se puede usar directamente con PowerShell, cmdlets de la CLI o API para compilar y organizar manualmente migraciones de bases de datos a SQL Managed Instance. Algunas de las razones para considerar el uso de LRS son:
- Más control sobre el proyecto de migración de bases de datos
- Poca tolerancia al tiempo de inactividad en la transición de la migración
- Incapacidad de instalar el ejecutable DMS en el entorno
- Falta de acceso de archivos a las copias de seguridad de bases de datos
- Incapacidad de abrir puertos de red desde el entorno a Azure
Descripción de los tipos de migración
Hay dos modos de migración disponibles para LRS.
Modo | Descripción | Recomendado para | Disponibilidad de la cadena de copia de seguridad |
---|---|---|---|
autocompletar | Finaliza automáticamente la migración cuando se restaura el último archivo de copia de seguridad | Cargas de trabajo pasivas | Toda la cadena de copia de seguridad debe estar disponible con antelación. |
Continuo | Examina continuamente los nuevos archivos de copia de seguridad y los restaura, lo que permite ponerse al día de los datos. | Cargas de trabajo activas | La cadena de copia de seguridad se puede agregar durante la migración. |
Independientemente del modo, planee completar la migración en un plazo de 30 días, ya que el trabajo de LRS se cancelará automáticamente después de este tiempo.
Protección del proceso de migración
Para ejecutar LRS, debe tener uno de los siguientes roles de control de acceso basado en rol (RBAC) de Azure: Propietario de la suscripción, Colaborador de instancia administrada de SQL o un rol personalizado con el permiso Microsoft.Sql/managedInstances/databases/*
.
Se requiere una cuenta de Azure Blob Storage y funciona como almacenamiento intermedio para los archivos de copia de seguridad entre la instancia de SQL Server y la instancia administrada de SQL. Para usar Azure Blob Storage con un firewall, se requiere otra configuración. Debe agregar la subred de INSTANCIA administrada de SQL a las reglas de firewall de red virtual de la cuenta de almacenamiento mediante la delegación de subred de MI y el punto de conexión de servicio de almacenamiento. Además, puede usar un token de SAS o una identidad administrada para acceder a la cuenta de Azure Blob Storage, pero no a ambas.
Mejora del rendimiento de copia de seguridad y restauración
Puede dividir copias de seguridad completas y diferenciales en varios archivos, en lugar de usar un único archivo, para mejorar el rendimiento de la copia de seguridad y restauración. Esto se debe a que varios archivos se pueden leer o escribir en paralelo, lo que reduce el tiempo necesario para completar la operación de copia de seguridad o restauración.
Además, habilitar la compresión de copia de seguridad puede ayudar a mejorar las velocidades de transferencia de red. Las copias de seguridad comprimidas tienen un tamaño menor, lo que significa que tardan menos tiempo en transferirse a través de la red. Esto puede ser especialmente útil al transferir copias de seguridad de gran tamaño a Azure o desde este.
Se recomienda encarecidamente habilitar CHECKSUM
para las copias de seguridad, aunque no sea necesario. Instancia administrada de SQL realiza una comprobación de integridad en las copias de seguridad sin CHECKSUM
, lo que puede aumentar el tiempo necesario para restaurar la base de datos. Al habilitar CHECKSUM
, puede acelerar las operaciones de restauración.