Migrar recursos do banco de dados para o Azure global

  • Artigo

Importante

Desde agosto de 2018, não aceitamos mais novos clientes nem implantamos novos recursos e serviços nos locais originais da Microsoft Cloud da Alemanha.

Com base na evolução das necessidades dos clientes, lançamos recentemente duas novas regiões de datacenter na Alemanha e oferecemos aos clientes residência de dados, conectividade completa com a rede global em nuvem da Microsoft e preços competitivos no mercado.

Além disso, no dia 30 de setembro de 2020, anunciamos que a Microsoft Cloud Alemanha seria encerrada no dia 29 de outubro de 2021. Mais detalhes estão disponíveis aqui: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Aproveite a amplitude da funcionalidade, a segurança de nível empresarial e os recursos abrangentes disponíveis em nossas novas regiões alemãs de datacenter migrando hoje.

Este artigo contém informações que podem ajudar você a migrar recursos de banco de dados do Azure Alemanha para o Azure global.

Banco de Dados SQL

Para migrar cargas de trabalho menores do Banco de Dados SQL do Azure, sem manter o banco de dados migrado online, use a função exportar para criar um arquivo BACPAC. Um arquivo BACPAC é um arquivo compactado (zipado) que contém metadados e os dados do banco de dados do SQL Server. Depois de criar o arquivo BACPAC, você poderá copiar o arquivo para o ambiente de destino (por exemplo, usando o AzCopy) e usar a função de importação para recompilar o banco de dados. Lembre-se das seguintes considerações:

  • Para que uma exportação seja consistente em termos transacionais, confirme se uma das seguintes condições é verdadeira:
    • Nenhuma atividade de gravação ocorre durante a exportação.
    • Você exporta de uma cópia transacionalmente consistente do seu banco de dados SQL.
  • Para exportar para o armazenamento de Blob do Azure, o tamanho do arquivo BACPAC tem um limite de 200 GB. Para arquivar um arquivo BACPAC maior, exporte para o armazenamento local.
  • Se a operação de exportação a partir do Banco de Dados SQL levar mais de 20 horas, a operação poderá ser cancelada. Confira os artigos a seguir para ver dicas sobre como aumentar o desempenho.

Observação

A cadeia de conexão muda após a operação de exportação porque o nome DNS do servidor muda durante a exportação.

Para obter mais informações:

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Confira Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

Migrar Banco de Dados SQL usando replicação geográfica ativa

Para bancos de dados muito grandes para arquivos BACPAC ou para migrar de uma nuvem para outra e permanecer online com tempo de inatividade mínimo, você pode configurar a replicação geográfica ativa do Azure Alemanha para o Azure global.

Importante

A configuração da replicação geográfica ativa para migrar bancos de dados para o Azure global só é compatível com o uso do Transact-SQL (T-SQL) e, antes da migração, você precisa solicitar a habilitação da sua assinatura permitir a migração para o Azure global. Para enviar uma solicitação, você precisa usar este link de solicitação de suporte.

Observação

As regiões de nuvem global do Azure, Centro-Oeste da Alemanha e Norte da Alemanha, são compatíveis para replicação geográfica ativa com a nuvem do Azure Alemanha. Se quiser usar uma região global do Azure alternativa como o destino de bancos de dados finais, recomendamos configurar um link de replicação geográfica adicional do Centro-Oeste da Alemanha ou do Norte da Alemanha para a região de nuvem global do Azure após a conclusão da migração para o Azure global.

Para obter detalhes sobre os custos de replicação geográfica ativa, consulte a seção Replicação geográfica ativa em Preços do Banco de Dados SQL do Azure.

Migrar bancos de dados com replicação geográfica ativa requer um servidor lógico SQL do Azure no Azure global. Você pode criar o servidor usando o portal, o Azure PowerShell, a CLI do Azure, etc., mas configurar a replicação geográfica ativa para migrar do Azure Alemanha para o Azure global só é compatível com o uso do Transact-SQL (T-SQL).

Importante

Ao migrar entre nuvens, os prefixos de nome de servidor primário (Azure Alemanha) e do secundário (Azure global) precisam ser diferentes. Se os nomes de servidor forem iguais, a instrução ALTER DATABASE será executada corretamente, mas a migração falhará. Por exemplo, se o prefixo do nome do servidor primário for myserver (myserver.database.cloudapi.de), o prefixo do nome do servidor secundário no Azure global não poderá ser myserver.

A instrução ALTER DATABASE permite especificar um servidor de destino no Azure global usando o nome de servidor DNS totalmente qualificado no lado de destino.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbrepresenta o nome do banco de dados em um servidor SQL do Azure no Azure Alemanha.
  • public-server.database.windows.net representa o nome do servidor de SQL do Azure que existe no Azure global, onde o banco de dados deve ser migrado. O namespace "database.windows.net" é obrigatório. Substitua public-server pelo nome do seu servidor de SQL lógico no Azure global. O servidor no Azure global precisa ter um nome diferente do servidor primário no Azure Alemanha.

O comando é executado no banco de dados mestre no servidor do Azure Alemanha que hospeda o banco de dados local a ser migrado.

  • Para autenticar o usuário conectado no servidor de nuvem pública, a API de início-cópia T-SQL encontra um usuário com o mesmo nome de logon/usuário de SQL no banco de dados mestre desse servidor. Essa abordagem é independente de nuvem. Portanto, a API T-SQL é usada para iniciar cópias entre nuvens. Para obter permissões e mais informações sobre este tópico, consulte Criar e usar a replicação geográfica ativa e ALTER DATABASE (Transact-SQL).

  • Exceto para a extensão inicial do comando T-SQL que indica um servidor lógico do SQL do Azure no Azure global, o resto do processo de replicação geográfica ativa é idêntico à execução existente na nuvem local. Para obter etapas detalhadas para criar a replicação geográfica ativa, consulte Criar e usar a replicação geográfica ativa. Com uma exceção, o banco de dados secundário é criado no servidor lógico secundário criado no Azure global.

  • Depois que o banco de dados secundário é criado no Azure global (como sua cópia online do banco de dados do Azure Alemanha), o cliente poderá iniciar um failover de banco de dados do Azure Alemanha para o Azure global para esse banco de dados com o comando ALTER DATABASE T-SQL (confira a tabela abaixo).

  • Após o failover, depois que o secundário se tornar um banco de dados primário no Azure global, você poderá interromper a replicação geográfica ativa e remover o banco de dados secundário no lado do Azure Alemanha a qualquer momento (consulte a tabela abaixo e as etapas presentes no diagrama).

  • Após o failover, o banco de dados secundário no Azure Alemanha continuará a ser cobrado até ser excluído.

  • Usar o comando ALTER DATABASE é a única maneira de configurar a replicação geográfica ativa para migrar um banco de dados do Azure Alemanha para o Azure global.

  • Nenhum portal do Azure, Azure Resource Manager, PowerShell ou CLI está disponível para configurar a replicação geográfica ativa para essa migração.

Para migrar um banco de dados do Azure Alemanha para o Azure global:

  1. Escolha o banco de dados de usuário no Azure Alemanha, por exemplo, azuregermanydb

  2. Crie um servidor lógico no Azure global (a nuvem pública), por exemplo, globalazureserver. O nome de domínio totalmente qualificado (FQDN) é globalazureserver.database.windows.net.

  3. Inicie a replicação geográfica ativa do Azure Alemanha para o Azure global executando este comando T-SQL no servidor no Azure Alemanha. Observe que o nome DNS totalmente qualificado é usado para o servidor público globalazureserver.database.windows.net. Isso serve para indicar que o servidor de destino está no Azure global e não no Azure Alemanha.

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

  4. Quando a replicação estiver pronta para mover a carga de trabalho de leitura/gravação para o servidor global do Azure, inicie um failover planejado para o Azure global com esse comando T-SQL no servidor do Azure global.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. O link de replicação geográfica ativa pode ser encerrado antes ou depois do processo de failover. Executar o comando T-SQL a seguir, após o failover planejado, remove o link de replicação geográfica com o banco de dados no Azure global sendo a cópia de leitura/gravação. Ele deve ser executado no servidor lógico do banco de dados primário geográfico atual (ou seja, no servidor global do Azure). Isso concluirá o processo de migração.

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

    O comando T-SQL a seguir, quando executado antes do failover planejado, também interrompe o processo de migração. Porém, nessa situação, o banco de dados no Azure Alemanha permanecerá como a cópia de leitura/gravação. Esse comando T-SQL também deve ser executado no servidor lógico do banco de dados primário geográfico atual, neste caso, no servidor do Azure Alemanha.

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

Estas etapas para migrar os bancos de dados do Azure SQL do Azure Alemanha para o Azure global também podem ser seguidas usando a replicação geográfica ativa.

Para obter mais informações, as tabelas a seguir indicam os comandos T-SQL para o gerenciamento de failover. Os comandos a seguir são compatíveis para replicação geográfica ativa entre as nuvem do Azure Alemanha e do Azure global:

Comando Descrição
ALTER DATABASE Use o argumento ADD SECONDARY ON SERVER para criar um banco de dados secundário para um banco de dados existente e inicie a replicação de dados
ALTER DATABASE Usar o FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS para alternar um banco de dados secundário para primário a fim de iniciar o failover
ALTER DATABASE Use REMOVE SECONDARY ON SERVER para encerrar uma replicação de dados entre um Banco de Dados SQL e o banco de dados secundário especificado.

Exibições do sistema de monitoramento de replicação geográfica ativa

Comando Descrição
sys.geo_replication_links Retorna informações sobre todos os links de replicação existentes para cada banco de dados no servidor do Banco de Dados SQL do Azure.
sys.dm_geo_replication_link_status Obtém a hora da última replicação, latência da última replicação e outras informações sobre o link de replicação para um determinado Banco de Dados SQL.
sys.dm_operation_status Mostra o status de todas as operações de banco de dados, incluindo o status dos links de replicação.
sp_wait_for_database_copy_sync Faz com que o aplicativo espere até que todas as transações confirmadas sejam replicadas e reconhecidas pelo banco de dados secundário ativo.

Migrar os backups de retenção de longo prazo do Banco de Dados SQL

A migração de um banco de dados com replicação geográfica ou arquivo BACPAC não copia os backups de retenção de longo prazo, que o banco de dados pode ter no Azure Alemanha. Para migrar backups de retenção de longo prazo para a região global do Azure de destino, você pode usar o procedimento COPY de backup de retenção de longo prazo.

Observação

Os métodos de cópia de backup LTR documentados aqui podem copiar apenas os backups LTR do Azure Alemanha para o Azure global. Não é permitido copiar backups de recuperação pontual usando esses métodos.

Pré-requisitos

  1. O banco de dados de destino em que você está copiando os backups LTR precisam existir no Azure global antes de iniciar as cópias. Recomendamos migrar primeiro o banco de dados de origem usando a replicação geográfica ativa e, em seguida, iniciar a cópia de backup LTR. Isso garantirá que os backups de banco de dados sejam copiados para o banco de dados de destino correto. Essa etapa não é necessária se você estiver copiando backups LTR de um banco de dados descartado. Ao copiar backups LTR de um banco de dados descartado, um DatabaseID fictício será criado na região de destino.
  2. Instalar esse Módulo Az do PowerShell
  3. Antes de começar, verifique se as funções RBAC do Azure necessárias foram concedidas no escopo da assinatura ou do grupo de recursos. Observação: para acessar backups de LTR que pertencem a um servidor descartado, a permissão precisa ser concedida no escopo de assinatura desse servidor. .

Limitações

  • Não são permitidos grupos de failover. Isso significa que os clientes que migram bancos de dados do Azure Alemanha precisarão gerenciar cadeias de conexão durante o failover.
  • Não há compatibilidade com o portal do Azure, as APIs do Azure Resource Manager, o PowerShell ou a CLI. Isso significa que cada migração do Azure Alemanha precisará gerenciar a configuração da replicação geográfica ativa e o failover por meio do T-SQL.
  • Os clientes não podem criar vários secundários geográficos no Azure global para bancos de dados no Azure Alemanha.
  • A criação de um secundário geográfico precisa ser iniciada na região do Azure Alemanha.
  • Os clientes podem migrar bancos de dados do Azure Alemanha somente para o Azure global. Atualmente, não é permitida a migração entre nuvens.
  • Os usuários do Azure AD nos bancos de dados de usuário do Azure Alemanha são migrados, mas não estão disponíveis no novo locatário do Azure AD em que o banco de dados migrado está hospedado. Para serem habilitados, esses usuários precisam ser removidos e recriados manualmente usando os usuários atuais do Azure AD disponíveis no novo locatário do Azure AD em que o banco de dados migrado recentemente está hospedado.

Copiar backups de retenção de longo prazo usando o PowerShell

Um novo comando do PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup foi introduzido e pode ser usado para copiar os backups de retenção de longo prazo do Azure Alemanha para regiões do Azure global.

  1. Copiar backup LTR usando o nome do backup O exemplo a seguir mostra como copiar um backup LTR do Azure Alemanha para a região do Azure global usando backupname.
# 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. Copiar backup LTR usando o resourceID do backup O exemplo a seguir mostra como copiar um backup LTR do Azure Alemanha para a região do Azure global usando o resourceID de um backup. Este exemplo também pode ser usado para copiar backups de um banco de dados excluído.
$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

Limitações

  • O design permite apenas que os backups de recuperação pontual (PITR) sejam obtidos no banco de dados primário. Ao migrar bancos de dados do Azure Alemanha usando a DR geográfica, os backups da recuperação pontual começarão a ocorrer no novo primário após o failover. No entanto, os backups de recuperação pontual existentes (no primário anterior no Azure Alemanha) não serão migrados. Se precisar de backups de recuperação pontual para apoiar qualquer cenário de restauração pontual, você precisará restaurar o banco de dados de backups de recuperação pontual no Azure Alemanha e, em seguida, migrar o banco de dados recuperado para o Azure global.
  • As políticas de retenção de longo prazo não são migradas com o banco de dados. Se você tiver uma política de retenção de longo prazo (LTR) no banco de dados no Azure Alemanha, será necessário copiar e recriar manualmente a política de LTR no novo banco de dados após a migração.

Solicitar acesso

Para migrar um banco de dados do Azure Alemanha para o Azure global usando a replicação geográfica, sua assinatura no Azure Alemanha precisa estar habilitada para configurar com êxito a migração entre nuvem.

Para habilitar sua assinatura do Azure Alemanha, você precisa usar o seguinte link para criar uma solicitação de suporte de migração:

  1. Navegue até a solicitação de suporte de migração a seguir.

  2. Na guia Básico, insira Migração de DR geográfica como o Resumoe, em seguida, escolha Avançar: Soluções

    novo formulário de solicitação de suporte

  3. Revise as etapas recomendadas e depois escolha Avançar: Detalhes.

    informações de solicitação de suporte necessárias

  4. Na página de detalhes, informe o seguinte:

    1. Na caixa Descrição, insira a ID da assinatura global do Azure para a qual migrar. Para migrar bancos de dados para mais de uma assinatura, adicione uma lista das IDs globais do Azure para as quais você deseja migrar bancos de dados.
    2. Forneça informações de contato: nome, nome da empresa, email ou número de telefone.
    3. Preencha o formulário e depois escolha Avançar: Revisar + criar.

    detalhes da solicitação de suporte

  5. Revise a solicitação de suporte e depois escolha Criar.

Entraremos em contato quando a solicitação for processada.

Azure Cosmos DB

Com a ferramenta de migração de dados Azure Cosmos DB, você pode facilmente migrar dados para Azure Cosmos DB. A ferramenta de migração de dados Azure Cosmos DB é uma solução de software de código aberto que importa dados para o Azure Cosmos DB de fontes diferentes, inclusive: arquivos JSON, MongoDB, SQL Server, arquivos CSV, armazenamento de tabelas do Azure, Amazon DynamoDB, HBase e contêineres do Azure Cosmos.

A ferramenta de migração de dados Azure Cosmos DB está disponível como uma ferramenta de interface gráfica ou como ferramenta de linha de comando. O código-fonte está disponível no repositório de GitHub da ferramenta de migração de dados do Azure Cosmos DB. Uma versão compilada da ferramenta está disponível no Centro de Download da Microsoft.

Para migrar os recursos do Azure Cosmos DB, recomendamos que você conclua as seguintes etapas:

  1. Examine os requisitos de tempo de atividade do aplicativo e as configurações de conta para determinar o melhor plano de ação.
  2. Clone as configurações da conta do Azure Alemanha para a nova região executando a ferramenta de migração de dados.
  3. Se for possível usar uma janela de manutenção, copie os dados da origem para o destino executando a ferramenta de migração de dados.
  4. Se o uso de uma janela de manutenção não for uma opção, copie os dados da origem para o destino executando a ferramenta e conclua estas etapas:
    1. Use uma abordagem orientada por configuração para fazer alterações na leitura/gravação em um aplicativo.
    2. Conclua uma sincronização pela primeira vez.
    3. Configure uma sincronização incremental e acompanhe o feed de alterações.
    4. O ponto lê para a nova conta e valida o aplicativo.
    5. Parar grava na conta antiga, valida se o feed de alterações foi atualizado e, em seguida, o ponto grava na nova conta.
    6. Interrompa a ferramenta e exclua a conta antiga.
  5. Execute a ferramenta para validar que os dados são consistentes em contas novas e antigas.

Para obter mais informações:

Cache Redis do Azure

Você terá algumas opções se quiser migrar uma instância do Cache do Azure para Redis do Azure Alemanha para o Azure global. A opção escolhida depende dos seus requisitos.

Opção 1: aceitar a perda de dados, criar uma nova instância

Essa abordagem é mais adequada quando as duas condições a seguir são verdadeiras:

  • Você está usando o Cache do Azure para Redis como um cache de dados transitório.
  • Seu aplicativo populará de novo os dados de cache automaticamente na nova região.

Para migrar com perda de dados e criar uma nova instância:

  1. Crie uma nova instância do Cache do Azure para Redis na nova região de destino.
  2. Atualize o aplicativo para usar a nova instância na nova região.
  3. Exclua a instância do Cache do Azure para Redis na região de origem.

Opção 2: copiar dados da instância de origem para a instância de destino

Um membro da equipe do Cache do Azure para Redis programou uma ferramenta de código aberto que copia dados de uma instância do Cache do Azure para Redis a outra sem exigir a funcionalidade de importação ou exportação. Consulte a etapa 4 a seguir para obter informações sobre a ferramenta.

Para copiar dados da instância de origem para a instância de destino:

  1. Crie uma VM na região de origem. Se seu conjunto de armazenamento no Cache do Azure para Redis for grande, escolha um tamanho de VM relativamente potente para minimizar o tempo de cópia.
  2. Crie uma nova instância do Cache do Azure para Redis na região de destino.
  3. Libere os dados da instância de destino. (Certifique-se de não liberar da instância de origem . A liberação é necessária porque a ferramenta de cópia não substitui as chaves existentes no local de destino.)
  4. Use a ferramenta a seguir para copiar automaticamente os dados da instância de origem do Cache do Azure para Redis para a instância de destino: Origem da ferramenta e Download da ferramenta.

Observação

Esse processo pode ser demorado, dependendo do tamanho do seu conjunto de dados.

Opção 3: exportar da instância de origem, importar para a instância de destino

Essa abordagem aproveita os recursos disponíveis apenas na camada Premium.

Para exportar da instância de origem e importar para a instância de destino:

  1. Crie uma nova instância do Cache do Azure para Redis da camada Premium na região de destino. Use o mesmo tamanho da instância do Cache do Azure para Redis.

  2. Exporte dados do cache de origem ou use o cmdlet Export-AzRedisCache do PowerShell.

    Observação

    A exportação da conta do Armazenamento do Microsoft Azure precisa estar na mesma região da instância de cache.

  3. Copie os blobs exportados para uma conta de armazenamento na região de destino (por exemplo, com o AzCopy).

  4. Importe dados para o cache de destino ou use o cmdlet Import-AzRedisCAche do PowerShell.

  5. Reconfigure seu aplicativo para usar a instância de destino do Cache do Azure para Redis.

Opção 4: gravar dados em duas instâncias do Cache do Azure para Redis, ler de uma instância

Para essa abordagem, você precisa mudar seu aplicativo. O aplicativo precisa gravar dados em mais de uma instância de cache durante a leitura de uma dessas instâncias. Essa abordagem é adequada se os dados armazenados no Cache do Azure para Redis atendem aos seguintes critérios:

  • Os dados são atualizados regularmente.
  • Todos os dados são gravados na instância de destino do Cache do Azure para Redis.
  • Você tem tempo suficiente para atualizar todos os dados.

Para obter mais informações:

PostgreSQL e MySQL

Para obter mais informações, consulte os artigos na seção "Fazer o back-up e migrar dados" de PostgreSQL e MySQL.

PostgreSQL e MySQL

Próximas etapas

Conheça as ferramentas, as técnicas e as recomendações para migrar recursos nas seguintes categorias de serviço: