Traslado de recursos a otra región: base de datos de Azure SQL

Se aplica a: Azure SQL Database

• Azure SQL Database
• Instancia administrada de Azure SQL
• SQL Server en máquinas virtuales de Azure

En este artículo se muestra un flujo de trabajo genérico sobre cómo mover la base de datos o el grupo elástico a otra región.

Nota:

• Para trasladar grupos elásticos y bases de datos a una región de Azure diferente, puede usar también Azure Resource Mover, recomendado.
• Este artículo se aplica a las migraciones dentro de la nube pública de Azure o dentro de la misma nube soberana.

Información general

Hay varios escenarios en los que puede desear mover la base de datos o el grupo existentes de una región a otra. Por ejemplo, va a ampliar su negocio a una nueva región y desear optimizarla para la nueva base de clientes. O bien, debe migrar las operaciones a una otra región por motivos de cumplimiento. O también que Azure ha lanzado una nueva región que proporciona una mejor proximidad y mejora la experiencia del cliente.

El flujo de trabajo general para mover recursos a otra región consta de los pasos siguientes:

1. Comprobar los requisitos previos para el traslado.
2. Preparar el traslado de los recursos en el ámbito.
3. Supervisar el proceso de preparación.
4. Probar el proceso de traslado.
5. Iniciar el traslado real.

Comprobación de los requisitos previos para mover la base de datos

1. Cree un servidor de destino para cada servidor de origen.
2. Configure el firewall con las excepciones correctas mediante PowerShell.
3. Configure ambos servidores con los inicios de sesión correctos. Si no es el administrador de la suscripción o el administrador del servidor de SQL, solicite al administrador que le asigne los permisos que necesita. Para obtener más información, consulte Administración de la seguridad de Azure SQL Database después de la recuperación ante desastres.
4. Si las bases de datos están cifradas con cifrado de datos transparente (TDE) y usan su propia clave de cifrado (BYOK o clave administrada por el cliente) en Azure Key Vault, asegúrese de que se aprovisiona el material de cifrado correcto en las regiones de destino.
   • La manera más sencilla de hacerlo es agregar la clave de cifrado del almacén de claves existente (que se usa como protector de TDE en el servidor de origen) al servidor de destino y, a continuación, establecer la clave como protector de TDE en el servidor de destino ya que ahora un servidor de una región puede conectarse a un almacén de claves de cualquier otra región..
   • Como procedimiento recomendado para asegurarse de que el servidor de destino tiene acceso a claves de cifrado anteriores (necesarias para restaurar copias de seguridad de base de datos), ejecute el cmdlet Get-AzSqlServerKeyVaultKey en el servidor de origen para devolver la lista de claves disponibles y agregar esas claves al servidor de destino.
   • Para más información y procedimientos recomendados sobre la configuración del TDE administrado por el cliente en el servidor de destino, vea Cifrado de datos transparente de Azure SQL con una clave administrada por el cliente en Azure Key Vault.
   • Para mover el almacén de claves a la nueva región, vea Movimiento de un almacén de claves de Azure entre regiones.
5. Si está habilitada la auditoría de nivel de base de datos, deshabilítela y habilite la auditoría de nivel de servidor en su lugar. Después de la conmutación por error, la auditoría de nivel de base de datos requiere el tráfico entre regiones, que no es lo que se desea ni es posible después del traslado.
6. En el caso de las auditorías de nivel de servidor, asegúrese de que:
   • El contenedor de almacenamiento, Log Analytics o el centro de eventos con los registros de auditoría existentes migran a la región de destino.
   • La auditoría se configura en el servidor de destino. Para obtener más información, consulte la Introducción a la auditoría de SQL Database.
7. Si el servidor tiene una directiva de retención a largo plazo (LTR), las copias de seguridad de LTR existentes permanecerán asociadas al servidor actual. Dado que el servidor de destino es diferente, podrá tener acceso a las copias de seguridad de LTR anteriores de la región de origen mediante el servidor de origen, aunque se elimine el servidor.

Nota:

No se admite la migración de bases de datos con copias de seguridad de LTR existentes entre regiones soberanas y públicas, ya que esto requiere mover copias de seguridad de LTR al servidor de destino, lo que no es posible actualmente.

Preparación de recursos

1. Cree un grupo de conmutación por error entre el servidor del origen y el servidor del destino.
2. Agregue las bases de datos que desea migrar al grupo de conmutación por error. La replicación de todas las bases de datos agregadas se iniciará automáticamente. Para obtener más información, consulte Uso de grupos de conmutación por error con SQL Database.

Supervisión del proceso de preparación

Puede llamar periódicamente a Get-AzSqlDatabaseFailoverGroup para supervisar la replicación de las bases de datos desde el origen al servidor de destino. El objeto de salida de Get-AzSqlDatabaseFailoverGroup incluye una propiedad para Get-AzSqlDatabaseFailoverGroup:

• ReplicationState = 2 (CATCH_UP) indica que la base de datos está sincronizada y se puede conmutar por error de forma segura.
• ReplicationState = 0 (SEEDING) indica que la base de datos aún no se ha inicializado y se producirá un error en un intento de conmutación por error.

Prueba de la sincronización

Una vez que ReplicationState es 2, conéctese a cada base de datos o a un subconjunto de bases de datos que usen el punto de conexión secundario <fog-name>.secondary.database.windows.net y realice cualquier consulta en las bases de datos para asegurarse de la conectividad, la configuración de seguridad adecuada y la replicación de datos.

Inicio de la migración

1. Conéctese al servidor de destino mediante el punto de conexión secundario <fog-name>.secondary.database.windows.net.
2. Use Switch-AzSqlDatabaseFailoverGroup para cambiar el servidor secundario para que sea la principal con sincronización completa. Esta operación se realizará correctamente o se revertirá.
3. Compruebe que el comando se ha completado correctamente mediante nslook up <fog-name>.secondary.database.windows.net para determinar que la entrada CNAME de DNS apunta a la dirección IP de la región de destino. Si se produce un error en el comando switch, no se actualizará CNAME.

Supresión de las bases de datos de origen

Una vez completada la migración, quite los recursos de la región de origen para evitar cargos innecesarios.

1. Elimine el grupo de conmutación por error mediante Remove-AzSqlDatabaseFailoverGroup.
2. Elimine cada base de datos de origen mediante Remove-AzSqlDatabase para cada una de las bases de datos del servidor de origen. Esto finalizará automáticamente los vínculos de replicación geográfica.
3. Elimine el servidor de origen mediante Remove-AzSqlServer.
4. Quite el almacén de claves, los contenedores de almacenamiento de auditoría, el centro de eventos, el inquilino de Microsoft Entra y otros recursos dependientes para que no se les facture por ellos.

Comprobación de los requisitos previos para mover el grupo

1. Cree un servidor de destino para cada servidor de origen.
2. Configure el firewall con las excepciones correctas mediante PowerShell.
3. Configure los servidores con los inicios de sesión correctos. Si no es el administrador de la suscripción ni el administrador del servidor, solicite al administrador que le asigne los permisos que necesita. Para obtener más información, consulte Administración de la seguridad de Azure SQL Database después de la recuperación ante desastres.
4. Si las bases de datos están cifradas con cifrado de datos transparente y usan su propia clave de cifrado en Azure Key Vault, asegúrese de que se aprovisiona el material de cifrado correcto en la región de destino.
5. Cree un grupo elástico de destino para cada grupo elástico de origen y asegúrese de que el grupo se crea en el mismo nivel de servicio, con el mismo nombre y el mismo tamaño.
6. Si está habilitada una auditoría de nivel de base de datos, deshabilítela y habilite la auditoría de nivel de servidor en su lugar. Después de la conmutación por error, la auditoría de nivel de base de datos requerirá el tráfico entre regiones, que no es lo que se desea ni es posible después del traslado.
7. En el caso de las auditorías de nivel de servidor, asegúrese de que:
   • El contenedor de almacenamiento, Log Analytics o el centro de eventos con los registros de auditoría existentes migran a la región de destino.
   • La configuración de la auditoría se prepara en el servidor de destino. Para más información, consulte Auditoría de SQL Database.
8. Si el servidor tiene una directiva de retención a largo plazo (LTR), las copias de seguridad de LTR existentes permanecerán asociadas al servidor actual. Dado que el servidor de destino es diferente, puede tener acceso a las copias de seguridad de LTR anteriores de la región de origen mediante el servidor de origen, aunque se elimine el servidor.

Nota:

No se admite la migración de bases de datos con copias de seguridad de LTR existentes entre regiones soberanas y públicas, ya que esto requiere mover copias de seguridad de LTR al servidor de destino, lo que no es posible actualmente.

Preparación para la migración

1. Cree un grupo de conmutación por error independiente entre cada grupo elástico del servidor de origen y su grupo elástico equivalente en el servidor de destino.

2. Agregue todas las bases de datos del grupo al grupo de conmutación por error. La replicación de las bases de datos agregadas se iniciará automáticamente. Para obtener más información, consulte Uso de grupos de conmutación por error con SQL Database.

   Nota:

   Aunque es posible crear un grupo de conmutación por error que incluya varios grupos elásticos, se recomienda especialmente que cree un grupo de conmutación por error independiente para cada grupo. Si tiene un gran número de bases de datos en varios grupos elásticos que debe migrar, puede ejecutar los pasos de preparación en paralelo y, a continuación, iniciar el paso de la migración en paralelo. Este proceso se escalará mejor y tendrá menos tiempo en comparación con la existencia de varios grupos elásticos en el mismo grupo de conmutación por error.

Supervisión del proceso de preparación

Puede llamar periódicamente a Get-AzSqlDatabaseFailoverGroup para supervisar la replicación de las bases de datos desde el origen al destino. El objeto de salida de Get-AzSqlDatabaseFailoverGroup incluye una propiedad para Get-AzSqlDatabaseFailoverGroup:

• ReplicationState = 2 (CATCH_UP) indica que la base de datos está sincronizada y se puede conmutar por error de forma segura.
• ReplicationState = 0 (SEEDING) indica que la base de datos aún no se ha inicializado y se producirá un error en un intento de conmutación por error.

Prueba de la sincronización

Una vez que ReplicationState es 2, conéctese a cada base de datos o a un subconjunto de bases de datos que usen el punto de conexión secundario <fog-name>.secondary.database.windows.net y realice cualquier consulta en las bases de datos para asegurarse de la conectividad, la configuración de seguridad adecuada y la replicación de datos.

Inicio de la migración

1. Conéctese al servidor de destino mediante el punto de conexión secundario <fog-name>.secondary.database.windows.net.
2. Use Switch-AzSqlDatabaseFailoverGroup para cambiar el servidor secundario para que sea la principal con sincronización completa. Esta operación se realizará correctamente, o se revertirá.
3. Compruebe que el comando se ha completado correctamente mediante nslook up <fog-name>.secondary.database.windows.net para determinar que la entrada CNAME de DNS apunta a la dirección IP de la región de destino. Si se produce un error en el comando switch, no se actualiza CNAME.

Eliminación de los grupos elásticos de origen

Una vez completada la migración, quite los recursos de la región de origen para evitar cargos innecesarios.

1. Elimine el grupo de conmutación por error mediante Remove-AzSqlDatabaseFailoverGroup.
2. Elimine cada grupo elástico de origen en el servidor de origen mediante Remove-AzSqlElasticPool.
3. Elimine el servidor de origen mediante Remove-AzSqlServer.
4. Quite el almacén de claves, los contenedores de almacenamiento de auditoría, el centro de eventos, el inquilino de Microsoft Entra y otros recursos dependientes para que no se les facture por ellos.

Pasos siguientes

Administrar la base de datos después de que se haya migrado.