Migrar recursos de base de dados para o Azure global

  • Artigo

Importante

Desde agosto de 2018, não aceitamos novos clientes nem implementamos novas funcionalidades e serviços nas localizações originais do Microsoft Cloud Germany.

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

Além disso, a 30 de setembro de 2020, anunciámos que o Microsoft Cloud Germany fecharia a 29 de outubro de 2021. Estão disponíveis mais detalhes aqui: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Tire partido da amplitude da funcionalidade, da segurança de nível empresarial e das funcionalidades abrangentes disponíveis nas nossas novas regiões do datacenter alemão ao migrar atualmente.

Este artigo tem informações que o podem ajudar a migrar recursos da base de dados do Azure do Azure Alemanha para o Azure global.

Base de Dados SQL

Para migrar cargas de trabalho de base de dados SQL do Azure mais pequenas, sem manter a base de dados migrada online, utilize a função de exportação para criar um ficheiro BACPAC. Um ficheiro BACPAC é um ficheiro comprimido (zipado) que contém metadados e os dados da base de dados SQL Server. Depois de criar o ficheiro BACPAC, pode copiar o ficheiro para o ambiente de destino (por exemplo, com o AzCopy) e utilizar a função de importação para reconstruir a base de dados. Tenha em atenção as seguintes considerações:

  • Para que uma exportação seja consistente de forma transacional, certifique-se de que uma das seguintes condições é verdadeira:
    • Não ocorre nenhuma atividade de escrita durante a exportação.
    • Exporta a partir de uma cópia consistente de forma transacional da base de dados SQL.
  • Para exportar para o armazenamento de Blobs do Azure, o tamanho do ficheiro BACPAC está limitado a 200 GB. Para um ficheiro BACPAC maior, exporte para o armazenamento local.
  • Se a operação de exportação de Base de Dados SQL demorar mais de 20 horas, a operação poderá ser cancelada. Consulte os seguintes artigos para obter sugestões sobre como aumentar o desempenho.

Nota

O cadeia de ligação é alterado após a operação de exportação porque o nome DNS do servidor é alterado durante a exportação.

Para obter mais informações:

Nota

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

Migrar Base de Dados SQL com a georreplicação ativa

Para bases de dados demasiado grandes para ficheiros BACPAC ou para migrar de uma nuvem para outra e permanecer online com o tempo de inatividade mínimo, pode configurar a georreplicação ativa do Azure Alemanha para o Azure global.

Importante

A configuração da georreplicação ativa para migrar bases de dados para o Azure global só é suportada através do Transact-SQL (T-SQL) e, antes de migrar, tem de pedir a ativação da sua subscrição para suportar a migração para o Azure global. Para submeter um pedido, tem de utilizar esta ligação de pedido de suporte.

Nota

As regiões da cloud global do Azure, Alemanha Central Oeste e Norte da Alemanha, são as regiões suportadas para georreplicação ativa com a cloud do Azure Germany. Se uma região global alternativa do Azure for pretendida como o destino final das bases de dados, a recomendação após a conclusão da migração para o Azure global é configurar uma ligação de georreplicação adicional do Germany West Central ou Germany North para a região de cloud global do Azure necessária.

Para obter detalhes sobre os custos de georreplicação ativos, veja a secção intitulada Georreplicação ativa nos preços da Base de Dados do SQL do Azure.

A migração de bases de dados com georreplicação ativa requer um servidor lógico SQL do Azure no Azure global. Pode criar o servidor com o portal, o Azure PowerShell, a CLI do Azure, etc., mas a configuração da georreplicação ativa para migrar do Azure Alemanha para o Azure global só é suportada com Transact-SQL (T-SQL).

Importante

Ao migrar entre clouds, os prefixos de nome de servidor primário (Azure Alemanha) e secundário (global do Azure) têm de 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 pode ser myserver.

A ALTER DATABASE instrução permite-lhe especificar um servidor de destino no Azure global com o respetivo nome de servidor dns completamente qualificado no lado de destino.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbrepresenta o nome da base de dados num servidor SQL do Azure no Azure Germany.
  • public-server.database.windows.netrepresenta o SQL do Azure nome do servidor que existe no Azure global, onde a base de dados deve ser migrada. O espaço de nomes "database.windows.net" é necessário, substitua public-server pelo nome do seu SQL Server lógico no Azure global. O servidor no Azure global tem de ter um nome diferente do servidor primário no Azure Alemanha.

O comando é executado na base de dados mestra no servidor do Azure Germany que aloja a base de dados local a ser migrada.

  • A API de cópia inicial do T-SQL autentica o utilizador com sessão iniciada no servidor de cloud pública ao localizar um utilizador com o mesmo nome de utilizador/início de sessão do SQL na base de dados mestra desse servidor. Esta abordagem é agnóstica à cloud; Assim, a API T-SQL é utilizada para iniciar cópias entre clouds. Para obter permissões e mais informações sobre este tópico, veja Criar e utilizar a georreplicação 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 resto do processo de georreplicação ativo é idêntico à execução existente na cloud local. Para obter passos detalhados para criar a georreplicação ativa, veja Criar e utilizar a georreplicação ativa com uma exceção , a base de dados secundária é criada no servidor lógico secundário criado no Azure global.

  • Assim que a base de dados secundária existir no Azure global (como cópia online da base de dados do Azure Germany), o cliente pode iniciar uma ativação pós-falha de base de dados do Azure Alemanha para o Azure global para esta base de dados com o comando ALTER DATABASE T-SQL (veja a tabela abaixo).

  • Após a ativação pós-falha, assim que a secundária se tornar uma base de dados primária no Azure global, pode parar a georreplicação ativa e remover a base de dados secundária do lado do Azure Germany em qualquer altura (veja a tabela abaixo e os passos presentes no diagrama).

  • Após a ativação pós-falha, a base de dados secundária no Azure Alemanha continuará a incorrer em custos até ser eliminada.

  • A utilização do ALTER DATABASE comando é a única forma de configurar a georreplicação ativa para migrar uma base de dados do Azure Germany para o Azure global.

  • Não existem portal do Azure, Resource Manager do Azure, PowerShell ou CLI disponíveis para configurar a georreplicação ativa para esta migração.

Para migrar uma base de dados do Azure Alemanha para o Azure global:

  1. Escolha a base de dados de utilizador no Azure Germany, por exemplo, azuregermanydb

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

  3. Inicie a georreplicação ativa do Azure Alemanha para o Azure global ao executar este comando T-SQL no servidor no Azure Germany. Tenha em atenção que o nome dns completamente qualificado é utilizado para o servidor globalazureserver.database.windows.netpúblico . Isto indica 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-escrita para o servidor global do Azure, inicie uma failover planeado para o Azure global ao executar este comando T-SQL no servidor global do Azure.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. A ligação de georreplicação ativa pode ser terminada antes ou depois do processo de ativação pós-falha. Executar o seguinte comando T-SQL após o failover planeado remove a ligação de georreplicação com a base de dados no Azure global, sendo a cópia de leitura/escrita. Deve ser executado no servidor lógico da base de dados georreplicação primária atual (ou seja, no servidor global do Azure). Isto irá concluir o processo de migração.

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

    O seguinte comando T-SQL, quando executado antes do failover planeado também para o processo de migração, mas, nesta situação, a base de dados no Azure Alemanha continuará a ser a cópia de leitura/escrita. Este comando T-SQL também deve ser executado no servidor lógico da base de dados georreplicação primária atual, neste caso no servidor do Azure Germany.

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

Estes passos para migrar bases de dados SQL do Azure do Azure Alemanha para o Azure global também podem ser seguidos com a georreplicação ativa.

Para obter mais informações, as seguintes tabelas abaixo indicam comandos T-SQL para gerir a ativação pós-falha. Os seguintes comandos são suportados para georreplicação ativa entre clouds entre o Azure Germany e o Azure global:

Comando Descrição
ALTER DATABASE Utilizar o argumento ADICIONAR SECUNDÁRIO NO SERVIDOR para criar uma base de dados secundária para uma base de dados existente e iniciar a replicação de dados
ALTER DATABASE Utilizar a ATIVAÇÃO PÓS-FALHA ou FORCE_FAILOVER_ALLOW_DATA_LOSS para mudar uma base de dados secundária para ser primária para iniciar a ativação pós-falha
ALTER DATABASE Utilize REMOVER SECUNDÁRIO NO SERVIDOR para terminar uma replicação de dados entre um Base de Dados SQL e a base de dados secundária especificada.

Vistas do sistema de monitorização de georreplicação ativa

Comando Descrição
sys.geo_replication_links Devolve informações sobre todas as ligações de replicação existentes para cada base de dados no servidor da Base de Dados do SQL do Azure.
sys.dm_geo_replication_link_status Obtém a hora da última replicação, o último atraso da replicação e outras informações sobre a ligação de replicação para uma determinada base de dados SQL.
sys.dm_operation_status Mostra o estado de todas as operações da base de dados, incluindo o estado das ligações de replicação.
sp_wait_for_database_copy_sync Faz com que a aplicação aguarde até que todas as transações consolidadas sejam replicadas e reconhecidas pela base de dados secundária ativa.

Migrar Base de Dados SQL cópias de segurança de retenção de longo prazo

Migrar uma base de dados com georreplicação ou ficheiro BACPAC não copia as cópias de segurança de retenção de longo prazo, que a base de dados pode ter no Azure Alemanha. Para migrar cópias de segurança de retenção de longo prazo existentes para a região global do Azure de destino, pode utilizar o procedimento de cópia de segurança de retenção de longo prazo COPY.

Nota

Os métodos de cópia de segurança LTR documentados aqui só podem copiar as cópias de segurança LTR do Azure Germany para o Azure global. A cópia de segurança pitr com estes métodos não é suportada.

Pré-requisitos

  1. A base de dados de destino onde está a copiar as cópias de segurança LTR tem de existir no Azure global antes de começar a copiar as cópias de segurança. Recomenda-se que migre primeiro a base de dados de origem com a georreplicação ativa e, em seguida, inicie a cópia de segurança LTR. Isto irá garantir que as cópias de segurança da base de dados são copiadas para a base de dados de destino correta. Este passo não é necessário se estiver a copiar cópias de segurança LTR de uma base de dados removida. Ao copiar cópias de segurança LTR de uma base de dados removida, será criado um DatabaseID fictício na região de destino.
  2. Instalar este Módulo Az do PowerShell
  3. Antes de começar, certifique-se de que as funções RBAC do Azure necessárias são concedidas no âmbito da subscrição ou do grupo de recursos . Nota: para aceder a cópias de segurança LTR que pertencem a um servidor removido, a permissão tem de ser concedida no âmbito da subscrição desse servidor. .

Limitações

  • Os Grupos de Ativação Pós-falha não são suportados. Isto significa que os clientes que migram bases de dados do Azure Germany terão de gerir as próprias cadeias de ligação durante a ativação pós-falha.
  • Não existe suporte para portal do Azure, APIs do Azure Resource Manager, PowerShell ou CLI. Isto significa que cada migração do Azure Alemanha terá de gerir a configuração ativa da georreplicação e a ativação pós-falha através do T-SQL.
  • Os clientes não podem criar várias georreplicações secundárias no Azure global para bases de dados no Azure Alemanha.
  • A criação de uma georreplicação secundária tem de ser iniciada a partir da região do Azure Alemanha.
  • Os clientes podem migrar bases de dados para fora do Azure Germany apenas para o Azure global. Atualmente, não é suportada qualquer outra migração entre clouds.
  • Azure AD utilizadores nas bases de dados de utilizador do Azure Alemanha são migrados, mas não estão disponíveis no novo inquilino Azure AD onde reside a base de dados migrada. Para ativar estes utilizadores, estes têm de ser removidos e recriados manualmente com os utilizadores atuais Azure AD disponíveis no novo inquilino Azure AD onde reside a base de dados recentemente migrada.

Copiar cópias de segurança de retenção de longo prazo com o PowerShell

Foi introduzido um novo comando do PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup , que pode ser utilizado para copiar as cópias de segurança de retenção de longo prazo do Azure Germany para as regiões globais do Azure.

  1. Copiar cópia de segurança LTR com o nome da cópia de segurança O exemplo seguinte mostra como pode copiar uma cópia de segurança LTR do Azure Germany para a região global do Azure com o nome da cópia de segurança.
# 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 cópia de segurança LTR com o resourceID da cópia de segurança O exemplo seguinte mostra como pode copiar a cópia de segurança LTR do Azure Germany para a região global do Azure com um resourceID de cópia de segurança. Este exemplo também pode ser utilizado para copiar cópias de segurança de uma base de dados 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

Limitações

  • As cópias de segurança de restauro para um ponto anterior no tempo (PITR) só são efetuadas na base de dados primária, isto é, por predefinição. Ao migrar bases de dados do Azure Germany com Geo-DR, as cópias de segurança PITR começarão a ocorrer na nova primária após a ativação pós-falha. No entanto, as cópias de segurança PITR existentes (nas primárias anteriores no Azure Alemanha) não serão migradas. Se precisar de cópias de segurança PITR para suportar cenários de restauro para um ponto anterior no tempo, terá de restaurar a base de dados a partir de cópias de segurança PITR no Azure Alemanha e, em seguida, migrar a base de dados recuperada para o Azure global.
  • As políticas de retenção de longo prazo não são migradas com a base de dados. Se tiver uma política de retenção de longo prazo (LTR) na sua base de dados no Azure Alemanha, terá de copiar e recriar manualmente a política LTR na nova base de dados após a migração.

Pedir acesso

Para migrar uma base de dados do Azure Alemanha para o Azure global com a georreplicação, a sua subscrição no Azure Alemanha tem de estar ativada para configurar com êxito a migração entre clouds.

Para ativar a sua subscrição do Azure Germany, tem de utilizar a seguinte ligação para criar um pedido de suporte de migração:

  1. Navegue para o seguinte pedido de suporte de migração.

  2. No separador Noções básicas, introduza Migração georreplicação de DR como Resumo e, em seguida, selecione Seguinte: Soluções

    novo formulário de pedido de suporte

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

    informações necessárias do pedido de suporte

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

    1. Na caixa Descrição, introduza o ID de subscrição global do Azure para o qual migrar. Para migrar bases de dados para mais do que uma subscrição, adicione uma lista dos IDs globais do Azure para os quais pretende migrar bases de dados.
    2. Forneça informações de contacto: nome, nome da empresa, e-mail ou número de telefone.
    3. Preencha o formulário e, em seguida, selecione Seguinte: Rever + 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.

Azure Cosmos DB

Pode utilizar 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 open source que importa dados para o Azure Cosmos DB a partir de diferentes origens, incluindo: ficheiros JSON, MongoDB, SQL Server, ficheiros CSV, armazenamento de Tabelas do Azure, Amazon DynamoDB, HBase e contentores 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 comandos. O código fonte está disponível no repositório do GitHub da Ferramenta de Migração de Dados do Azure Cosmos DB . Está disponível uma versão compilada da ferramenta no Centro de Transferências da Microsoft.

Para migrar recursos do Azure Cosmos DB, recomendamos que conclua os seguintes passos:

  1. Reveja os requisitos de tempo de atividade da aplicação e as configurações da conta para determinar o melhor plano de ação.
  2. Clone as configurações da conta do Azure Germany para a nova região ao executar a ferramenta de migração de dados.
  3. Se for possível utilizar uma janela de manutenção, copie os dados da origem para o destino ao executar a ferramenta de migração de dados.
  4. Se a utilização de uma janela de manutenção não for uma opção, copie os dados da origem para o destino ao executar a ferramenta e, em seguida, conclua estes passos:
    1. Utilize uma abordagem condicionada por configuração para fazer alterações à leitura/escrita numa aplicação.
    2. Conclua uma primeira sincronização.
    3. Configure uma sincronização incremental e acompanhe o feed de alterações.
    4. Aponte as leituras para a nova conta e valide a aplicação.
    5. Pare as escritas na conta antiga, confirme que o feed de alterações é apanhado e, em seguida, aponte escritas para a nova conta.
    6. Pare a ferramenta e elimine a conta antiga.
  5. Execute a ferramenta para validar que os dados são consistentes em contas antigas e novas.

Para obter mais informações:

Cache do Azure para Redis

Tem algumas opções se quiser migrar uma instância Cache do Azure para Redis do Azure Germany para o Azure global. A opção que escolher depende dos seus requisitos.

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

Esta abordagem faz mais sentido quando ambas as condições seguintes são verdadeiras:

  • Está a utilizar Cache do Azure para Redis como uma cache de dados transitória.
  • A sua aplicação irá repovoar automaticamente os dados da cache na nova região.

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

  1. Crie uma nova instância Cache do Azure para Redis na nova região de destino.
  2. Atualize a aplicação para utilizar a nova instância na nova região.
  3. Elimine a instância de Cache do Azure para Redis antiga na região de origem.

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

Um membro da equipa de Cache do Azure para Redis escreveu uma ferramenta open source que copia dados de uma instância Cache do Azure para Redis para outra sem que seja necessária a funcionalidade de importação ou exportação. Veja o passo 4 nos passos seguintes 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 do Azure para Redis for grande, certifique-se de que seleciona um tamanho de VM relativamente poderoso para minimizar o tempo de cópia.
  2. Crie uma nova instância Cache do Azure para Redis na região de destino.
  3. Remova os dados da instância de destino . (Certifique-se de que não remove a cache da instância de origem . A descarga é necessária porque a ferramenta de cópia não substitui as chaves existentes na localização de destino.)
  4. Utilize a seguinte ferramenta para copiar automaticamente dados da instância de Cache do Azure para Redis de origem para a instância de Cache do Azure para Redis de destino: origem da ferramenta e transferência de ferramentas.

Nota

Este processo pode demorar muito tempo, dependendo do tamanho do conjunto de dados.

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

Esta abordagem tira partido das funcionalidades que estão disponíveis apenas no escalão Premium.

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

  1. Crie um novo escalão Premium Cache do Azure para Redis instância na região de destino. Utilize o mesmo tamanho que a origem Cache do Azure para Redis instância.

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

    Nota

    A conta de Armazenamento do Azure de exportação tem de 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, com o AzCopy).

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

  5. Reconfigure a aplicação para utilizar a instância de destino Cache do Azure para Redis.

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

Para esta abordagem, tem de modificar a sua aplicação. A aplicação precisa de escrever dados em mais do que uma instância de cache enquanto lê a partir de uma das instâncias de cache. Esta abordagem faz sentido se os dados armazenados no Cache do Azure para Redis cumprirem os seguintes critérios:

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

Para obter mais informações:

PostgreSQL e MySQL

Para obter mais informações, veja os artigos na secção "Fazer cópia de segurança e migrar dados" de PostgreSQL e MySQL.

PostgreSQL e MySQL

Passos seguintes

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