Mover recursos para uma nova região – Banco de Dados SQL do Azure

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Este artigo apresenta um fluxo de trabalho genérico sobre como mover seu banco de dados ou pool elástico para uma nova região.

Observação

  • Para mover bancos de dados e pools elásticos para uma região do Azure diferente, você também pode usar o Azure Resource Mover (recomendado).
  • Este artigo se aplica a migrações na nuvem pública do Azure ou na mesma nuvem soberana.

Visão geral

Há vários cenários em que é possível mover o banco de dados ou pool existente de uma região para outra. Por exemplo, você está expandindo sua empresa para uma nova região e deseja otimizá-la para a nova base de clientes. Ou você precisa mover as operações para uma região diferente por motivos de conformidade. Ou o Azure lançou uma nova região que fornece uma proximidade melhor e aprimora a experiência do cliente.

O fluxo de trabalho geral para mover recursos para uma região diferente consiste nas seguintes etapas:

  1. Verifique os pré-requisitos para a movimentação.
  2. Prepare-se para mover os recursos no escopo.
  3. Monitore o processo de preparação.
  4. Teste o processo de movimentação.
  5. Inicie a movimentação propriamente dita.

Verifique os pré-requisitos para mover o banco de dados

  1. Crie um servidor de destino para cada servidor de origem.
  2. Configure o firewall com as exceções certas usando o PowerShell.
  3. Configure ambos os servidores com os logons corretos. Se você não for o administrador da assinatura ou do SQL Server, trabalhe com o administrador para atribuir as permissões necessárias. Para obter mais informações, confira Como gerenciar a segurança do Banco de Dados SQL do Azure após a recuperação de desastre.
  4. Se os bancos de dados forem criptografados com Transparent Data Encryption (TDE) e chave de criptografia Bring Your Own Key (BYOK ou chave gerenciada pelo cliente) Azure Key Vault, verifique se o material de criptografia correto está provisionado nas regiões de destino.
    • A maneira mais simples de fazer isso é adicionar a chave de criptografia do cofre de chaves existente (em uso como um protetor de TDE no servidor de origem) ao servidor de destino e, em seguida, definir a chave como o protetor de TDE no servidor de destino, já que um servidor em uma região agora pode ser conectado em um cofre de chaves em qualquer outra região.
    • Como prática recomendada para garantir que o servidor de destino tenha acesso às chaves de criptografia mais antigas (necessárias para restaurar backups de banco de dados), execute o cmdlet Get-AzSqlServerKeyVaultKey no servidor de origem para retornar a lista de chaves disponíveis e adicionar essas chaves ao servidor de destino.
    • Para obter mais informações e práticas recomendadas sobre a configuração de TDE gerenciadas pelo cliente no servidor de destino, consulte Transparent Data Encryption do SQL do Azure com chaves gerenciadas pelo cliente no Azure Key Vault.
    • Para mover o cofre de chaves para a nova região, consulte Mover um cofre de chaves do Azure entre regiões.
  5. Se a auditoria em nível de banco de dados estiver habilitada, desabilite-a e, em lugar dela, habilite a auditoria no nível de servidor. Após o failover, a auditoria no nível do banco de dados exigirá o tráfego entre regiões, o que não é desejado ou possível após a movimentação.
  6. Para auditorias em nível de servidor, verifique se:
    • O contêiner de armazenamento, o Log Analytics ou o Hub de Eventos com os logs de auditoria existentes é movido para a região de destino.
    • A auditoria está configurada no servidor de destino. Para saber mais, confira Introdução à auditoria do Banco de Dados SQL.
  7. Se sua instância tiver uma política de retenção de longo prazo (LTR), os backups de LTR existentes permanecerão associados ao servidor atual. Como o servidor de destino é diferente, você poderá acessar os backups de LTR mais antigos na região de origem usando o servidor de origem, mesmo se o servidor for excluído.

Observação

Não há suporte à migração de bancos de dados com backups LTR existentes entre regiões soberanas e públicas, pois isso requer a movimentação de backups LTR para o servidor de destino, o que não é possível no momento.

Preparar os recursos

  1. Crie um grupo de failover entre o servidor da origem e o servidor do destino.
  2. Adicione os bancos de dados que você deseja mover para o grupo de failover. A replicação de todos os bancos de dados adicionados é iniciada automaticamente. Para obter mais informações, consulte Usando grupos de failover com o Banco de Dados SQL.

Monitorar o processo de preparação

Você pode chamar Get-AzSqlDatabaseFailoverGroup periodicamente para monitorar a replicação dos bancos de dados da origem para o servidor de destino. O objeto de saída de Get-AzSqlDatabaseFailoverGroup inclui uma propriedade para o Get-AzSqlDatabaseFailoverGroup:

  • ReplicationState = 2 (CATCH_UP) indica que o banco de dados está sincronizado e o failover dele pode ser realizado com segurança.
  • ReplicationState = 0 (PROPAGANDO) indica que o banco de dados ainda não foi propagado e uma eventual tentativa de failover falhará.

Testar sincronização

Depois que ReplicationState for 2, conecte-se a cada banco de dados ou subconjunto de bancos de dados usando o ponto de extremidade secundário <fog-name>.secondary.database.windows.net e execute qualquer consulta nos bancos de dados para garantir a conectividade, a configuração de segurança adequada e a replicação de dados.

Inicie a movimentação

  1. Conecte-se ao servidor de destino usando o ponto de extremidade secundário <fog-name>.secondary.database.windows.net.
  2. Use Switch-AzSqlDatabaseFailoverGroup para mudar o servidor secundário para ser o primário com sincronização completa. Essa operação terá êxito ou será revertida.
  3. Verifique se o comando foi concluído com êxito usando nslook up <fog-name>.secondary.database.windows.net para verificar se a entrada DNS CNAME aponta para o endereço IP da região de destino. Se o comando switch falhar, o CNAME não será atualizado.

Remover os bancos de dados de origem

Quando a movimentação for concluída, remova os recursos na região de origem para evitar encargos desnecessários.

  1. Exclua o grupo de failover usando Remove-AzSqlDatabaseFailoverGroup.
  2. Exclua cada banco de dados de origem usando Remove-AzSqlDatabase para cada um dos bancos de dados no servidor de origem. Isso encerra automaticamente os links de replicação geográfica.
  3. Exclua o servidor de origem usando Remove-AzSqlServer.
  4. Remova o cofre de chaves, os contêineres de armazenamento de auditoria, o hub de eventos, o locatário do Microsoft Entra e outros recursos dependentes para deixar de receber cobranças por eles.

Verifique os pré-requisitos para mover o pool

  1. Crie um servidor de destino para cada servidor de origem.
  2. Configure o firewall com as exceções certas usando o PowerShell.
  3. Configure os servidores com os logons corretos. Se você não for o administrador da assinatura ou do servidor, trabalhe com o administrador para atribuir as permissões necessárias. Para obter mais informações, confira Como gerenciar a segurança do Banco de Dados SQL do Azure após a recuperação de desastre.
  4. Se os bancos de dados forem criptografados com Transparent Data Encryption e usarem a sua chave de criptografia no Azure Key Vault, verifique se o material de criptografia correto está provisionado na região de destino.
  5. Crie um pool elástico de destino para cada pool elástico de origem, verificando se o pool é criado na mesma camada de serviço, com o mesmo nome e o mesmo tamanho.
  6. Se uma auditoria em nível de banco de dados estiver habilitada, desabilite-a e, em lugar dela, habilite a auditoria no nível de servidor. Após o failover, a auditoria no nível do banco de dados exigirá o tráfego entre regiões, que não é desejado ou possível após a movimentação.
  7. Para auditorias em nível de servidor, verifique se:
    • O contêiner de armazenamento, o Log Analytics ou o Hub de Eventos com os logs de auditoria existentes é movido para a região de destino.
    • A configuração de auditoria está configurada no servidor de destino. Para obter mais informações, confira Auditoria de Banco de Dados SQL.
  8. Se sua instância tiver uma política de retenção de longo prazo (LTR), os backups de LTR existentes permanecerão associados ao servidor atual. Como o servidor de destino é diferente, você poderá acessar os backups de LTR mais antigos na região de origem usando o servidor de origem, mesmo se o servidor for excluído.

Observação

Não há suporte à migração de bancos de dados com backups LTR existentes entre regiões soberanas e públicas, pois isso requer a movimentação de backups LTR para o servidor de destino, o que não é possível no momento.

Preparar para mover

  1. Crie um grupo de failover separado entre cada pool elástico no servidor de origem e o pool elástico que é a contraparte dele no servidor de destino.

  2. Adicione todos os bancos de dados no pool ao grupo de failover. A replicação dos bancos de dados adicionados será iniciada automaticamente. Para obter mais informações, consulte Usando grupos de failover com o Banco de Dados SQL.

    Observação

    Embora seja possível criar um grupo de failover que inclua vários pools elásticos, é altamente recomendável que você crie um grupo de failover separado para cada pool. Se você tiver um grande número de bancos de dados em vários pools elásticos que você precise mover, poderá executar as etapas de preparação em paralelo e, em seguida, iniciar a etapa de movimentação em paralelo. Esse processo escalará melhor e levará menos tempo se comparado a um cenário com vários pools elásticos no mesmo grupo de failover.

Monitorar o processo de preparação

Você pode chamar Get-AzSqlDatabaseFailoverGroup periodicamente para monitorar a replicação dos bancos de dados da origem para o destino. O objeto de saída de Get-AzSqlDatabaseFailoverGroup inclui uma propriedade para o Get-AzSqlDatabaseFailoverGroup:

  • ReplicationState = 2 (CATCH_UP) indica que o banco de dados está sincronizado e o failover dele pode ser realizado com segurança.
  • ReplicationState = 0 (PROPAGANDO) indica que o banco de dados ainda não foi propagado e uma eventual tentativa de failover falhará.

Testar sincronização

Quando ReplicationState for 2, conecte-se a cada banco de dados ou subconjunto de bancos de dados usando o ponto de extremidade secundário <fog-name>.secondary.database.windows.net e execute qualquer consulta nos bancos de dados para garantir a conectividade, a configuração de segurança adequada e a replicação de dados.

Inicie a movimentação

  1. Conecte-se ao servidor de destino usando o ponto de extremidade secundário <fog-name>.secondary.database.windows.net.
  2. Use Switch-AzSqlDatabaseFailoverGroup para mudar o servidor secundário para ser o primário com sincronização completa. Essa operação terá êxito ou será revertida.
  3. Verifique se o comando foi concluído com êxito usando nslook up <fog-name>.secondary.database.windows.net para verificar se a entrada DNS CNAME aponta para o endereço IP da região de destino. Se o comando switch falhar, o CNAME não será atualizado.

Remover os pools elásticos de origem

Quando a movimentação for concluída, remova os recursos na região de origem para evitar encargos desnecessários.

  1. Exclua o grupo de failover usando Remove-AzSqlDatabaseFailoverGroup.
  2. Exclua cada pool elástico de origem no servidor de origem usando Remove-AzSqlElasticPool.
  3. Exclua o servidor de origem usando Remove-AzSqlServer.
  4. Remova o cofre de chaves, os contêineres de armazenamento de auditoria, o hub de eventos, o locatário do Microsoft Entra e outros recursos dependentes para deixar de receber cobranças por eles.

Próximas etapas

Gerencie o seu banco de dados depois que ele tiver sido migrado.