Partilhar via


Migrar recursos de banco de dados para o Azure global

Importante

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

Com base na evolução das necessidades dos clientes, lançamos recentemente duas novas regiões de datacenter na Alemanha, oferecendo residência de dados do cliente, conectividade total à rede global de nuvem da Microsoft, bem como preços competitivos de mercado.

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

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

Este artigo contém informações que podem ajudá-lo a migrar recursos de banco de dados do Azure da Alemanha do Azure 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 de exportação 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ê pode copiar o arquivo para o ambiente de destino (por exemplo, usando AzCopy) e usar a função de importação para reconstruir o banco de dados. Esteja ciente das seguintes considerações:

  • Para que uma exportação seja transacionalmente consistente, verifique se uma das seguintes condições é verdadeira:
    • Nenhuma atividade de gravação ocorre durante a exportação.
    • Você exporta uma cópia do seu banco de dados SQL que é transacionalmente consistente.
  • Para exportar para o armazenamento de Blob do Azure, o tamanho do arquivo BACPAC é limitado a 200 GB. Para um arquivo BACPAC maior, exporte para armazenamento local.
  • Se a operação de exportação do Banco de dados SQL demorar mais de 20 horas, a operação poderá ser cancelada. Consulte os seguintes artigos para obter 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 mais informações:

Observação

Recomendamos que utilize o módulo Azure Az PowerShell para interagir com o Azure. Consulte Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo Az PowerShell, consulte Migrar o Azure PowerShell do AzureRM para o Az.

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

Para bancos de dados que são muito grandes para arquivos BACPAC ou para migrar de uma nuvem para outra e permanecer online com o mínimo de tempo de inatividade, 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ó é suportada usando Transact-SQL (T-SQL) e, antes de migrar, você deve solicitar a habilitação de sua assinatura para dar suporte à migração para o Azure global. Para enviar uma solicitação, você deve usar este link de solicitação de suporte.

Observação

As regiões de nuvem global do Azure, Alemanha Centro-Oeste e Alemanha Norte, são as regiões suportadas para replicação geográfica ativa com a nuvem do Azure Alemanha. Se uma região global alternativa do Azure for desejada como destino do(s) banco(s) de dados final, a recomendação após a conclusão da migração para o Azure global é configurar um link de replicação geográfica adicional da Alemanha Centro-Oeste ou Alemanha Norte para a região de nuvem global do Azure necessária.

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

A migração de 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 a configuração da replicação geográfica ativa para migrar do Azure Alemanha para o Azure global só é suportada usando Transact-SQL (T-SQL).

Importante

Ao migrar entre nuvens, os prefixos de nome de servidor primário (Azure Alemanha) e secundário (Azure global) devem ser diferentes. Se os nomes dos servidores forem os mesmos, a execução da instrução ALTER DATABASE será bem-sucedida, 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 que você especifique um servidor de destino no Azure global usando o nome de servidor DNS totalmente qualificado no lado do destino.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedb representa 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 SQL do Azure que existe no Azure global, para onde o banco de dados deve ser migrado. O namespace "database.windows.net" é necessário, substitua o servidor público pelo nome do seu servidor SQL lógico no Azure global. O servidor no Azure global deve ter um nome diferente do servidor primário no Azure Alemanha.

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

  • A API de cópia inicial do T-SQL autentica o usuário conectado no servidor de nuvem pública localizando um usuário com o mesmo login/nome de usuário SQL no banco de dados mestre desse servidor. Esta abordagem é agnóstica em relação à nuvem; assim, a API T-SQL é usada para iniciar cópias entre nuvens. Para obter permissões e mais informações sobre este tópico, consulte Criando e usando replicação geográfica ativa e ALTER DATABASE (Transact-SQL).

  • Exceto para a extensão de comando T-SQL inicial que indica um servidor lógico SQL do Azure no Azure global, o restante do processo de replicação geográfica ativa é idêntico à execução existente na nuvem local. Para obter etapas detalhadas para criar replicação geográfica ativa, consulte Criando e usando replicação geográfica ativa com uma exceção de que 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 existir 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 usando o comando ALTER DATABASE T-SQL (consulte a tabela abaixo).

  • Após o failover, quando 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 incorrer em custos até ser excluído.

  • Usar o ALTER DATABASE comando é 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 esta 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. Seu 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 globalazureserver.database.windows.netpúblico. Isso é 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 transferir o trabalho de leitura e gravação para o servidor global do Azure, inicie um failover planeado para o Azure global executando este comando T-SQL no servidor global do Azure.

    ALTER DATABASE [azuregermanydb] FAILOVER;
    
  5. O link de replicação geográfica ativa pode ser encerrado antes ou depois do processo de failover. A execução do seguinte comando T-SQL 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 geoprimário atual (ou seja, no servidor global do Azure). Isso concluirá o processo de migração.

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

    O seguinte comando T-SQL, quando executado antes do failover programado, também interrompe o processo de migração, mas, nessa situação, o banco de dados no Azure Alemanha permanecerá a cópia editável e legível. Esse comando T-SQL também deve ser executado no servidor lógico do banco de dados geoprimário atual, neste caso no servidor do Azure Alemanha.

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

Estas etapas para migrar bancos de dados 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 comandos T-SQL para gerenciar failover. Os seguintes comandos são suportados para replicação geográfica ativa entre nuvens entre o Azure Alemanha e o Azure global:

Comando Descrição
ALTERAR BASE DE DADOS Use o argumento ADD SECONDARY ON SERVER para criar um banco de dados secundário para um banco de dados existente e iniciar a replicação de dados
ALTERAR BASE DE DADOS Use FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS para mudar um banco de dados secundário para primário iniciando o failover.
ALTERAR BASE DE DADOS 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 ativas do sistema de monitoramento de replicação geográfica

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 o último tempo de replicação, o último atraso de 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 aguarde até que todas as transações confirmadas sejam replicadas e reconhecidas pelo banco de dados secundário ativo.

Migrar 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 existentes para a região global do Azure de destino, você pode usar o procedimento de backup de retenção de longo prazo COPY.

Observação

Os métodos de cópia de backup LTR documentados aqui só podem copiar os backups LTR do Azure Alemanha para o Azure global. Não há suporte para copiar backups PITR usando esses métodos.

Pré-requisitos

  1. O banco de dados de destino onde você está copiando os backups LTR, no Azure global, deve existir antes de iniciar a cópia dos backups. É recomendável que você primeiro migre o banco de dados de origem usando a replicação geográfica ativa e, em seguida, inicie a cópia de backup LTR. Isso garantirá que os backups do banco de dados sejam copiados para o banco de dados de destino correto. Esta 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 este módulo Az do PowerShell
  3. Antes de começar, verifique se as funções RBAC do Azure necessárias são concedidas no escopo da assinatura ou do grupo de recursos . Nota: Para acessar backups LTR que pertencem a um servidor descartado, a permissão deve ser concedida no escopo de assinatura desse servidor. .

Limitações

  • Não existe suporte para Grupos de Failover. Isso significa que os clientes que migram o(s) banco(s) de dados do Azure Alemanha precisarão gerenciar as próprias cadeias de conexão durante o failover.
  • Não há suporte para o portal do Azure, APIs do Azure Resource Manager, PowerShell ou CLI. Isso significa que cada uma das migrações do Azure Germany precisará gerir a configuração de replicação geográfica ativa e o failover através do T-SQL.
  • Os clientes não podem criar vários geosecundários no Azure global para bancos de dados no Azure Alemanha.
  • A criação de um geosecundário deve ser iniciada na região da Azure Alemanha.
  • Os clientes podem migrar bancos de dados do Azure Alemanha apenas para o Azure global. Atualmente, nenhuma outra migração entre nuvens é suportada.
  • 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 onde o banco de dados migrado reside. Para habilitar esses usuários, eles devem ser descartados manualmente e recriados usando os usuários atuais do Azure AD disponíveis no novo locatário do Azure AD onde reside o banco de dados recém-migrado.

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

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

  1. Copie o backup LTR usando o nome do backup O exemplo a seguir mostra como você pode copiar um backup LTR do Azure Alemanha para a região global do Azure, usando o 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. Copie o backup LTR usando o backup resourceID O exemplo a seguir mostra como você pode copiar o backup LTR do Azure Alemanha para a região global do Azure, usando um resourceID de 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

  • Os backups de restauração em um momento específico (PITR) são feitos apenas no banco de dados primário, isto é intencional. Ao migrar bancos de dados do Azure Alemanha usando Geo-DR, os backups PITR começarão a acontecer no novo primário após o failover. No entanto, os backups PITR existentes (no primário anterior no Azure Alemanha) não serão migrados. Se você precisar de backups PITR para dar suporte a qualquer cenário de restauração point-in-time, precisará restaurar o banco de dados de backups PITR 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) em seu banco de dados no Azure Alemanha, precisará copiar e recriar manualmente a política 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 ser habilitada para configurar com êxito a migração entre nuvens.

Para habilitar sua assinatura do Azure Alemanha, você deve usar o link a seguir para criar uma solicitação de suporte à migração:

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

  2. Na guia Noções básicas, insira Geo-DR migração como Resumo e selecione Avançar: Soluções

    novo formulário de pedido de apoio

  3. Reveja os Passos Recomendados e, em seguida, selecione Seguinte: Detalhes.

    Informações de solicitação de suporte necessário

  4. Na página de detalhes, forneça o seguinte:

    1. Na caixa Descrição, insira a ID de 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, e-mail ou número de telefone.
    3. Preencha o formulário e selecione Avançar: Revisar + criar.

    Detalhes do pedido de suporte

  5. Reveja o pedido de suporte e, em seguida, selecione Criar.

Será contactado assim que o pedido for processado.

Base de Dados Azure Cosmos

Você pode usar a Ferramenta de Migração de Dados do Azure Cosmos DB para migrar dados para o Azure Cosmos DB. A Ferramenta de Migração de Dados do Azure Cosmos DB é uma solução de código aberto que importa dados para o Azure Cosmos DB de diferentes fontes, incluindo: arquivos JSON, MongoDB, SQL Server, arquivos CSV, armazenamento de tabela do Azure, Amazon DynamoDB, HBase e contêineres do Azure Cosmos.

A Ferramenta de Migração de Dados do 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 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 recursos do Azure Cosmos DB, recomendamos que você conclua as seguintes etapas:

  1. Analise os requisitos de tempo de atividade do aplicativo e as configurações da conta para determinar o melhor plano de ação.
  2. Clone as configurações de 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 usar 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 de leitura e escrita em uma aplicação.
    2. Conclua uma primeira sincronização.
    3. Configure uma sincronização incremental e acompanhe o feed de alterações.
    4. Aponte para a nova conta e valide a aplicação.
    5. Interrompa as gravações na conta antiga, valide se o feed de alterações está atualizado e, em seguida, aponte as gravações para a nova conta.
    6. Pare a ferramenta e exclua a conta antiga.
  5. Execute a ferramenta para validar se os dados são consistentes entre contas antigas e novas.

Para mais informações:

Cache do Azure para Redis

Você tem algumas opções se quiser migrar uma instância do Azure Cache for Redis a partir da região do Azure Alemanha para o Azure global. A opção escolhida depende dos seus requisitos.

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

Essa abordagem faz mais sentido quando ambas as condições a seguir são verdadeiras:

  • Você está usando o Cache Redis do Azure como um cache de dados transitório.
  • Seu aplicativo preencherá novamente 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 seu aplicativo para usar a nova instância na nova região.
  3. Exclua a instância antiga 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 escreveu uma ferramenta de código aberto que copia dados de uma instância do Cache do Azure para Redis para outra sem exigir a funcionalidade de importação ou exportação. Consulte a etapa 4 nas etapas 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 o conjunto de dados no Cache Redis do Azure for grande, certifique-se de escolher um tamanho de VM com potência adequada 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. Limpe os dados da instância de destino. (Certifique-se de não esvaziar da instância de origem. O esvaziamento é necessário porque a ferramenta de cópia não substitui as chaves existentes no local de destino.)
  4. Use a seguinte ferramenta para copiar automaticamente os dados da instância de origem do Cache do Azure para Redis para a instância de destino do Cache do Azure para Redis: Origem da ferramenta e download da ferramenta.

Observação

Esse processo pode levar muito tempo, 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 que estão disponíveis apenas no nível Premium.

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

  1. Crie uma nova instância de Cache do Azure para Redis na camada Premium na região desejada. Use o mesmo tamanho que a instância de origem do Cache do Azure para Redis.

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

    Observação

    A conta de exportação do Armazenamento do Azure deve estar na mesma região que a instância de cache.

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

  4. Importe dados para o cache de destino ou use o cmdletImport-AzRedisCAche 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 Redis do Azure, lidas de uma instância

Para essa abordagem, você deve modificar seu aplicativo. O aplicativo precisa gravar dados em mais de uma instância de cache enquanto lê de uma das instâncias de cache. Essa abordagem fará sentido se os dados armazenados no Cache Redis do Azure atenderem aos seguintes critérios:

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

Para mais informações:

PostgreSQL e MySQL

Para obter mais informações, consulte os artigos na seção "Backup e migração de dados" do PostgreSQL e MySQL.

PostgreSQL e MySQL

Próximos passos

Saiba mais sobre ferramentas, técnicas e recomendações para migrar recursos nas seguintes categorias de serviço: