Compartir a través de

Migración de recursos de base de datos a Azure global

Importante

Desde agosto de 2018, no hemos aceptado nuevos clientes ni hemos implementado nuevas características y servicios en las ubicaciones originales de Microsoft Cloud Alemania.

En función de la evolución de las necesidades de los clientes, recientemente lanzado dos nuevas regiones del centro de datos en Alemania, ofreciendo residencia de datos de clientes, conectividad completa a la red en la nube global de Microsoft, así como precios competitivos del mercado.

Además, el 30 de septiembre de 2020 anunciamos que Microsoft Cloud Alemania cerraría el 29 de octubre de 2021. Puede encontrar más detalles aquí: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Aproveche la amplitud de la funcionalidad, la seguridad de nivel empresarial y las características completas disponibles en nuestras nuevas regiones de centros de datos en Alemania migrando hoy mismo.

En este artículo se incluye información que puede ayudarle a migrar recursos de base de datos de Azure de Azure Alemania a Azure global.

Base de datos SQL

Para migrar cargas de trabajo de Azure SQL Database más pequeñas, sin mantener la base de datos migrada en línea, use la función de exportación para crear un archivo BACPAC. Un archivo BACPAC es un archivo comprimido (zipped) que contiene metadatos y datos de la base de datos de SQL Server. Después de crear el archivo BACPAC, puede copiar el archivo en el entorno de destino (por ejemplo, mediante AzCopy) y usar la función de importación para recompilar la base de datos. Tenga presente las siguientes consideraciones:

  • Para que una exportación sea transaccionalmente coherente, asegúrese de que se cumple una de las condiciones siguientes:
    • No se produce ninguna actividad de escritura durante la exportación.
    • Exporte desde una copia que sea transaccionalmente coherente de su base de datos SQL.
  • Para exportar a Azure Blob Storage, el tamaño del archivo BACPAC está limitado a 200 GB. Para un archivo BACPAC mayor, exporte al almacenamiento local.
  • Si la operación de exportación de SQL Database tarda más de 20 horas, es posible que se cancele la operación. Consulte los artículos siguientes para obtener sugerencias sobre cómo aumentar el rendimiento.

Nota:

La cadena de conexión cambia después de la operación de exportación porque el nombre DNS del servidor cambia durante la exportación.

Para obtener más información:

Nota:

Se recomienda usar el módulo de PowerShell de Azure Az para interactuar con Azure. Consulte Instalación de Azure PowerShell para empezar. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Migración de SQL Database mediante la replicación geográfica activa

En el caso de las bases de datos demasiado grandes para los archivos BACPAC, o para migrar de una nube a otra y permanecer en línea con un tiempo de inactividad mínimo, puede configurar la replicación geográfica activa de Azure Alemania a Azure global.

Importante

La configuración de la replicación geográfica activa para migrar bases de datos a Azure global solo se admite mediante Transact-SQL (T-SQL) y antes de migrar debe solicitar la habilitación de la suscripción para admitir la migración a Azure global. Para enviar una solicitud, debe usar este vínculo de solicitud de soporte técnico.

Nota:

Las regiones de nube globales de Azure, Centro-oeste de Alemania y Norte de Alemania, son las regiones admitidas para la replicación geográfica activa con la nube de Azure Alemania. Si se desea una región de Azure global alternativa como destino final de las bases de datos, la recomendación después de completar la migración a Azure global es configurar un vínculo de replicación geográfica adicional desde Centro-oeste de Alemania o Norte de Alemania a la región de nube global de Azure necesaria.

Para más información sobre los costos de replicación geográfica activa, consulte la sección titulada Replicación geográfica activa en precios de Azure SQL Database.

La migración de bases de datos con replicación geográfica activa requiere un servidor lógico de Azure SQL en Azure global. Puede crear el servidor mediante el portal, Azure PowerShell, la CLI de Azure, etc., pero la configuración de la replicación geográfica activa para migrar de Azure Alemania a Azure global solo se admite mediante Transact-SQL (T-SQL).

Importante

Al migrar entre nubes, los prefijos de nombre de servidor principal (Azure Alemania) y secundario (global de Azure) deben ser diferentes. Si los nombres de servidor son los mismos, la ejecución de la instrucción ALTER DATABASE se realizará correctamente, pero se producirá un error en la migración. Por ejemplo, si el prefijo del nombre del servidor principal es myserver (myserver.database.cloudapi.de), el prefijo del nombre del servidor secundario en Azure global no puede ser myserver.

La ALTER DATABASE instrucción permite especificar un servidor de destino en global de Azure mediante su nombre de servidor DNS completamente calificado en el lado de destino.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedb representa el nombre de la base de datos en un servidor de Azure SQL server en Azure Alemania.
  • public-server.database.windows.net representa el nombre del servidor de Azure SQL que existe en Azure global, donde se debe migrar la base de datos. Se requiere el espacio de nombres "database.windows.net"; reemplace public-server por el nombre de su servidor SQL lógico en el entorno global de Azure. El servidor de Azure global debe tener un nombre diferente al servidor principal de Azure Alemania.

El comando se ejecuta en la base de datos maestra del servidor de Azure Alemania que hospeda la base de datos local que se va a migrar.

  • La API de inicio y copia de T-SQL autentica al usuario que ha iniciado sesión en el servidor de nube pública mediante la búsqueda de un usuario con el mismo nombre de usuario o inicio de sesión de SQL en la base de datos maestra de ese servidor. Este enfoque es independiente de la nube; por lo tanto, la API de T-SQL se usa para iniciar copias entre nubes. Para obtener permisos y más información sobre este tema, consulte Creación y uso de la replicación geográfica activa y ALTER DATABASE (Transact-SQL).

  • Excepto para la extensión de comando T-SQL inicial que indica un servidor lógico de Azure SQL en Azure global, el resto del proceso de replicación geográfica activa es idéntico a la ejecución existente en la nube local. Para obtener pasos detallados para crear la replicación geográfica activa, consulte Creación y uso de la replicación geográfica activa con una excepción que la base de datos secundaria se crea en el servidor lógico secundario creado en Azure global.

  • Una vez que la base de datos secundaria existe en Azure global (como su copia en línea de la base de datos de Azure Alemania), el cliente puede iniciar una conmutación por error de base de datos de Azure Alemania a Azure global para esta base de datos mediante el comando ALTER DATABASE T-SQL (consulte la tabla siguiente).

  • Después de la conmutación por error, una vez que la base de datos secundaria se convierte en la base de datos principal en Azure Global, puede detener la replicación geográfica activa y eliminar la base de datos secundaria en Azure Alemania en cualquier momento (consulte la tabla siguiente y los pasos del diagrama).

  • Después de la conmutación por error, la base de datos secundaria en Azure Alemania seguirá incurriendo en costos hasta que se elimine.

  • El uso del ALTER DATABASE comando es la única manera de configurar la replicación geográfica activa para migrar una base de datos de Azure Alemania a Azure global.

  • No hay Azure portal, Azure Resource Manager, PowerShell ni CLI disponibles para configurar la replicación geográfica activa para esta migración.

Para migrar una base de datos de Azure Alemania a Azure global:

  1. Elija la base de datos de usuario en Azure Alemania, por ejemplo, azuregermanydb

  2. Cree un servidor lógico en Azure global (la nube pública), por ejemplo, globalazureserver. Su nombre de dominio completo (FQDN) es globalazureserver.database.windows.net.

  3. Inicie la replicación geográfica activa desde Azure Alemania a Azure global mediante la ejecución de este comando de T-SQL en el servidor de Azure Alemania. Tenga en cuenta que el nombre de DNS totalmente calificado se usa para el servidor público globalazureserver.database.windows.net. Esto es para indicar que el servidor de destino está en Azure global y no en Azure Alemania.

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];

  4. Cuando la replicación esté lista para mover la carga de trabajo de lectura y escritura al servidor global de Azure, inicie una conmutación por error planificada a global Azure mediante la ejecución de este comando de T-SQL en el servidor global de Azure.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. El vínculo de replicación geográfica activa se puede finalizar antes o después del proceso de conmutación por error. Al ejecutar el siguiente comando de T-SQL después de la conmutación por error planificada, se elimina el vínculo de replicación geográfica. En este contexto, la base de datos de Azure global actúa como la copia de lectura y escritura. Debe ejecutarse en el servidor lógico de la base de datos geográfica principal actual (es decir, en el servidor global de Azure). Esto completará el proceso de migración.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];

    El siguiente comando de T-SQL, cuando se ejecuta antes de la conmutación por error planeada, también detiene el proceso de migración, pero en esta situación, la base de datos en Azure Alemania continuará siendo la copia de lectura y escritura. Este comando T-SQL también debe ejecutarse en el servidor lógico de la base de datos geográfica principal actual, en este caso en el servidor de Azure Alemania.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];

Estos pasos para migrar bases de datos de Azure SQL de Azure Alemania a Azure global también se pueden seguir mediante la replicación geográfica activa.

Para obtener más información, las tablas siguientes muestran comandos T-SQL para administrar la conmutación por error. Los siguientes comandos son compatibles con la replicación geográfica activa entre nubes entre Azure Alemania y Azure global:

Comando Descripción
ALTER DATABASE Usar el argumento ADD SECONDARY ON SERVER para crear una base de datos secundaria para una base de datos existente e iniciar la replicación de datos
ALTER DATABASE Use FAILOVER o FORCE_FAILOVER_ALLOW_DATA_LOSS para cambiar una base de datos secundaria para que sea principal para iniciar la conmutación por error
ALTER DATABASE Use REMOVE SECONDARY ON SERVER para finalizar la replicación de datos entre una SQL Database y una base de datos secundaria especificada.

Vistas del sistema de supervisión de replicación geográfica activa

Comando Descripción
sys.geo_replication_links Devuelve información sobre todos los vínculos de replicación existentes para cada base de datos en el servidor de Azure SQL Database.
sys.dm_geo_replication_link_status Obtiene la hora de la última replicación, el último retraso de replicación y otra información sobre el vínculo de replicación de una base de datos SQL determinada.
sys.dm_operation_status Muestra el estado de todas las operaciones de base de datos, incluido el estado de los vínculos de replicación.
sp_wait_for_database_copy_sync Hace que la aplicación espere hasta que la base de datos secundaria activa replique y confirme todas las transacciones confirmadas.

Migrar las copias de seguridad de retención a largo plazo de SQL Database

La migración de una base de datos con replicación geográfica o archivo BACPAC no copia las copias de seguridad de retención a largo plazo que la base de datos podría tener en Azure Alemania. Para migrar las copias de seguridad de retención a largo plazo existentes a la región global de Azure de destino, puede usar el procedimiento de copia de seguridad de retención a largo plazo COPY.

Nota:

Los métodos de copia de seguridad de LTR documentados aquí solo pueden copiar las copias de seguridad de LTR de Azure Alemania a Azure global. No se admite la copia de seguridad de PITR mediante estos métodos.

Requisitos previos

  1. La base de datos de destino en la que va a copiar las copias de seguridad LTR, en Azure global, debe existir antes de empezar a copiar las copias de seguridad. Se recomienda migrar primero la base de datos de origen mediante la replicación geográfica activa y, a continuación, iniciar la copia de seguridad de LTR. Esto garantizará que las copias de seguridad de la base de datos se copien en la base de datos de destino correcta. Este paso no es necesario si va a copiar copias de seguridad LTR de una base de datos eliminada. Al copiar copias de seguridad de LTR de una base de datos eliminada, se creará un databaseID ficticio en la región de destino.
  2. Instalación de este módulo Az de PowerShell
  3. Antes de comenzar, asegúrese de que se hayan concedido los roles RBAC de Azure necesarios en el ámbito de la suscripción o del grupo de recursos. Nota: Para acceder a las copias de seguridad de LTR que pertenecen a un servidor descartado, se debe conceder el permiso en el ámbito de suscripción de ese servidor. .

Limitaciones

  • Los grupos de conmutación por error no están admitidos. Esto significa que los clientes que migren bases de datos de Azure en la región de Alemania deberán gestionar las cadenas de conexión ellos mismos durante la conmutación por error.
  • No se admite Azure Portal, las API de Azure Resource Manager, PowerShell ni la CLI. Esto significa que cada migración de Azure en Alemania tendrá que administrar la configuración de replicación geográfica activa y la conmutación en caso de error a través de T-SQL.
  • Los clientes no pueden crear varias geosecundarias en Azure global para bases de datos en Azure Alemania.
  • La creación de una base de datos secundaria geográfica debe iniciarse desde la región de Azure Alemania.
  • Los clientes solo pueden migrar bases de datos de Azure Alemania a Azure global. Actualmente no se admite ninguna otra migración entre nubes.
  • Los usuarios de Azure AD en las bases de datos de usuario de Azure Alemania se migran, pero no están disponibles en el nuevo inquilino de Azure AD donde reside la base de datos migrada. Para habilitar estos usuarios, deben quitarse y volver a crearse manualmente con los usuarios actuales de Azure AD disponibles en el nuevo inquilino de Azure AD donde reside la base de datos recién migrada.

Copiar las copias de seguridad de retención a largo plazo mediante PowerShell

Se ha introducido un nuevo comando de PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup , que se puede usar para copiar las copias de seguridad de retención a largo plazo de Azure Alemania en regiones globales de Azure.

  1. Copie la copia de seguridad de LTR utilizando el nombre de la copia de seguridad El siguiente ejemplo muestra cómo puede copiar una copia de seguridad de LTR desde Azure Alemania a una región global de Azure, utilizando el nombre de la copia de seguridad.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN
  1. Copia de seguridad de LTR mediante resourceID de copia de seguridad En el ejemplo siguiente se muestra cómo puede copiar la copia de seguridad de LTR desde Azure Alemania a la región global de Azure mediante un resourceID de copia de seguridad. Este ejemplo también se puede usar para copiar copias de seguridad de una base de datos eliminada.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Limitaciones

  • Las copias de seguridad de restauración a un momento dado (PITR) solo se realizan en la base de datos principal, esto es por diseño. Al migrar bases de datos desde Azure Alemania utilizando recuperación ante desastres (Geo-DR), las copias de seguridad PITR comenzarán a realizarse en el nuevo servidor principal después de la conmutación por error. Sin embargo, no se migrarán las copias de seguridad PITR existentes (en el principal anterior en Azure Alemania). Si necesita copias de seguridad pitR para admitir cualquier escenario de restauración a un momento dado, debe restaurar la base de datos a partir de copias de seguridad pitR en Azure Alemania y, a continuación, migrar la base de datos recuperada a Azure global.
  • Las directivas de retención a largo plazo no se migran con la base de datos. Si tiene una directiva de retención a largo plazo (LTR) en la base de datos de Azure Alemania, debe copiar y volver a crear manualmente la directiva LTR en la nueva base de datos después de migrar.

Solicitud del acceso

Para migrar una base de datos de Azure Alemania a Azure global mediante la replicación geográfica, la suscripción en Azure Alemania debe habilitarse para configurar correctamente la migración entre nubes.

Para habilitar la suscripción de Azure Alemania, debe usar el vínculo siguiente para crear una solicitud de soporte técnico de migración:

  1. Vaya a la siguiente solicitud de soporte técnico de migración.

  2. En la pestaña Aspectos básicos, escriba Geo-DR migración como Resumen y, a continuación, seleccione Siguiente: Soluciones.

    formulario de solicitud de soporte técnico nuevo

  3. Revise los pasos recomendados y, a continuación, seleccione Siguiente: Detalles.

    información necesaria de la solicitud de soporte técnico

  4. En la página de detalles, proporcione lo siguiente:

    1. En el cuadro Descripción, escriba el identificador de suscripción global de Azure al que migrar. Para migrar bases de datos a más de una suscripción, agregue una lista de los identificadores globales de Azure a los que desea migrar las bases de datos.
    2. Proporcione información de contacto: nombre, nombre de la empresa, correo electrónico o número de teléfono.
    3. Complete el formulario y, a continuación, seleccione Siguiente: Revisar y crear.

    detalles de la solicitud de soporte técnico

  5. Revise la solicitud de soporte técnico y seleccione Crear.

Se le contactará una vez procesada la solicitud.

Azure Cosmos DB (la base de datos de Azure Cosmos)

Puede usar la herramienta de migración de datos de Azure Cosmos DB para migrar datos a Azure Cosmos DB. La herramienta de migración de datos de Azure Cosmos DB es una solución de código abierto que importa datos a Azure Cosmos DB desde orígenes diferentes, incluidos: archivos JSON, MongoDB, SQL Server, archivos CSV, Azure Table Storage, Amazon DynamoDB, HBase y contenedores de Azure Cosmos.

La herramienta de migración de datos de Azure Cosmos DB está disponible como una herramienta de interfaz gráfica o como herramienta de línea de comandos. El código fuente está disponible en el repositorio de GitHub de la herramienta de migración de datos de Azure Cosmos DB . Hay disponible una versión compilada de la herramienta en el Centro de descarga de Microsoft.

Para migrar recursos de Azure Cosmos DB, se recomienda completar los pasos siguientes:

  1. Revise los requisitos de tiempo de actividad de la aplicación y las configuraciones de cuenta para determinar el mejor plan de acción.
  2. Clonar las configuraciones de cuenta de Azure Alemania a la nueva región ejecutando la herramienta de migración de datos.
  3. Si es posible usar una ventana de mantenimiento, copie datos del origen al destino mediante la ejecución de la herramienta de migración de datos.
  4. Si el uso de una ventana de mantenimiento no es una opción, copie los datos del origen al destino mediante la ejecución de la herramienta y, a continuación, complete estos pasos:
    1. Use un enfoque controlado por la configuración para realizar cambios en la lectura y escritura en una aplicación.
    2. Realice una sincronización por primera vez.
    3. Configure una sincronización incremental y actualícese con las últimas modificaciones.
    4. Redirige a la nueva cuenta y valida la aplicación.
    5. Detenga las escrituras en la cuenta anterior, compruebe que la fuente de cambios está actualizada y, a continuación, redirija las escrituras a la nueva cuenta.
    6. Detenga la herramienta y elimine la cuenta antigua.
  5. Ejecute la herramienta para validar que los datos son coherentes en las cuentas antiguas y nuevas.

Para obtener más información:

Caché de Azure para Redis

Tiene algunas opciones si quiere migrar una instancia de Azure Cache for Redis de Azure Alemania a Azure global. La opción que elija depende de sus requisitos.

Opción 1: Aceptar pérdida de datos, crear una nueva instancia

Este enfoque tiene más sentido cuando se cumplen las dos condiciones siguientes:

  • Usa Azure Cache for Redis como una caché de datos transitoria.
  • La aplicación volverá a rellenar los datos de caché automáticamente en la nueva región.

Para migrar con pérdida de datos y crear una nueva instancia:

  1. Cree una nueva instancia de Azure Cache for Redis en la nueva región de destino.
  2. Actualice la aplicación para usar la nueva instancia en la nueva región.
  3. Elimine la instancia antigua de Azure Cache for Redis en la región de origen.

Opción 2: Copiar datos de la instancia de origen a la instancia de destino

Un miembro del equipo de Azure Cache for Redis escribió una herramienta de código abierto que copia datos de una instancia de Azure Cache for Redis a otra sin necesidad de funcionalidad de importación o exportación. Consulte el paso 4 en los pasos siguientes para obtener información sobre la herramienta.

Para copiar datos de la instancia de origen a la instancia de destino:

  1. Cree una máquina virtual en la región de origen. Si el conjunto de datos de Azure Cache for Redis es grande, asegúrese de seleccionar un tamaño de máquina virtual relativamente eficaz para minimizar el tiempo de copia.
  2. Cree una nueva instancia de Azure Cache for Redis en la región de destino.
  3. Vacía los datos de la instancia destino. (Asegúrese de no hacer flush desde la instancia de origen. El flush es necesario porque la herramienta de copia no sobrescribe las claves existentes en la ubicación de destino).
  4. Utiliza la siguiente herramienta para copiar automáticamente los datos desde la instancia de origen de Azure Cache for Redis a la instancia de destino de Azure Cache for Redis: Fuente de la herramienta y descarga de la herramienta.

Nota:

Este proceso puede tardar mucho tiempo en función del tamaño del conjunto de datos.

Opción 3: Exportar desde la instancia de origen, importar a la instancia de destino

Este enfoque aprovecha las características que solo están disponibles en el nivel Premium.

Para exportar desde la instancia de origen e importar a la instancia de destino:

  1. Cree una nueva instancia de Azure Cache for Redis de nivel Premium en la región de destino. Use el mismo tamaño que la instancia de Azure Cache for Redis de origen.

  2. Exporte datos desde la memoria caché de origen o use el cmdlet de PowerShellExport-AzRedisCache.

    Nota:

    La cuenta de Azure Storage de exportación debe estar en la misma región que la instancia de caché.

  3. Copie los blobs exportados en una cuenta de almacenamiento en la región de destino (por ejemplo, mediante AzCopy).

  4. Importe datos en la memoria caché de destino o use el cmdlet de PowerShellImport-AzRedisCAche.

  5. Reconfigure su aplicación para usar la instancia de destino de Azure Cache for Redis.

Opción 4: Escritura de datos en dos instancias de Azure Cache for Redis, lectura de una instancia

Para este enfoque, debe modificar su aplicación. La aplicación debe escribir datos en más de una instancia de caché mientras lee de una de las instancias de caché. Este enfoque tiene sentido si los datos almacenados en Azure Cache for Redis cumplen los siguientes criterios:

  • Los datos se actualizan periódicamente.
  • Todos los datos se escriben en la instancia de Azure Cache for Redis de destino.
  • Tiene tiempo suficiente para que se actualicen todos los datos.

Para obtener más información:

PostgreSQL y MySQL

Para obtener más información, consulte los artículos de la sección "Copia de seguridad y migración de datos" de PostgreSQL y MySQL.

PostgreSQL y MySQL

Pasos siguientes

Obtenga información sobre herramientas, técnicas y recomendaciones para migrar recursos en las siguientes categorías de servicio:

  • Last updated on