Compartilhar via

Mover recursos para uma nova região – Base de Dados SQL do Azure e Azure SQL Managed Instance

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure Instância Gerenciada SQLdo Azure

Este artigo ensina um fluxo de trabalho genérico sobre como mover seu banco de dados ou instância gerenciada para uma nova região.

Descrição geral

Há vários cenários nos quais você gostaria de mover seu banco de dados existente ou instância gerenciada de uma região para outra. Por exemplo, você está expandindo seu negócio para uma nova região e deseja otimizá-lo 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 oferece uma melhor proximidade e melhora a experiência do cliente.

Este artigo fornece um fluxo de trabalho geral para mover recursos para uma região diferente. O fluxo de trabalho consiste nos seguintes passos:

  1. Verifique os pré-requisitos para a mudança.
  2. Prepare-se para mover os recursos no escopo.
  3. Acompanhar o processo de preparação.
  4. Teste o processo de movimentação.
  5. Inicie o movimento real.
  6. Remova os recursos da região de origem.

Nota

Este artigo aplica-se a migrações dentro da nuvem pública do Azure ou dentro da mesma nuvem soberana.

Nota

Para mover bancos de dados SQL do Azure e pools elásticos para uma região diferente do Azure, você também pode usar o Azure Resource Mover (Recomendado). Consulte este tutorial para obter etapas detalhadas para fazer o mesmo.

Nota

Este artigo usa o módulo Azure Az PowerShell, que é o módulo PowerShell recomendado para interagir com o Azure. Para começar a utilizar o módulo Azure PowerShell, veja Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.

Mover um banco de dados

Verificar os pré-requisitos

  1. Crie um servidor de destino para cada servidor de origem.

  2. Configure o firewall com as exceções corretas usando o PowerShell.

  3. Configure os servidores com os logins corretos. Se você não for o administrador de assinatura ou o administrador do SQL Server, trabalhe com o administrador para atribuir as permissões necessárias. Para obter mais informações, consulte Como gerenciar a segurança do Banco de Dados SQL do Azure após a recuperação de desastres.

  4. Se seus bancos de dados forem criptografados com TDE (criptografia de dados transparente) e trouxerem sua própria chave de criptografia (BYOK ou Chave Gerenciada pelo Cliente) no Cofre de Chaves do Azure, verifique se o material de criptografia correto está provisionado nas regiões de destino.

  5. Se a auditoria no nível do banco de dados estiver habilitada, desative-a e habilite a auditoria no nível do 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 mudança.

  6. Para auditorias no nível do servidor, certifique-se de que:

    • O contêiner de armazenamento, o Log Analytics ou o hub de eventos com os logs de auditoria existentes são movidos para a região de destino.
    • A auditoria é configurada no servidor de destino. Para obter mais informações, consulte 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 LTR existentes permanecerão associados ao servidor atual. Como o servidor de destino é diferente, você poderá acessar os backups LTR mais antigos na região de origem usando o servidor de origem, mesmo que o servidor seja excluído.

    Nota

    Isso será insuficiente para se deslocar entre a nuvem soberana e uma região pública. Essa migração exigirá mover os backups LTR para o servidor de destino, que não é suportado atualmente.

Preparar 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 será iniciada automaticamente. Para obter mais informações, consulte Usando grupos de failover com o Banco de dados SQL.

Monitorizar o processo de preparação

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

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

Sincronização de teste

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

Iniciar a mudança

  1. Conecte-se ao servidor de destino usando o ponto de extremidade <fog-name>.secondary.database.windows.netsecundário .
  2. Use Switch-AzSqlDatabaseFailoverGroup para alternar a instância gerenciada secundária para ser a principal com sincronização completa. Esta operação será bem-sucedida ou reverterá.
  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 mudança for concluída, remova os recursos na região de origem para evitar cobranças desnecessárias.

  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 encerrará automaticamente os links de replicação geográfica.
  3. Exclua o servidor de origem usando Remove-AzSqlServer.
  4. Remova o cofre de chaves, contêineres de armazenamento de auditoria, hub de eventos, instância do Microsoft Entra e outros recursos dependentes para parar de ser cobrado por eles.

Mover pools elásticos

Verificar os pré-requisitos

  1. Crie um servidor de destino para cada servidor de origem.

  2. Configure o firewall com as exceções corretas usando o PowerShell.

  3. Configure os servidores com os logins 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, consulte Como gerenciar a segurança do Banco de Dados SQL do Azure após a recuperação de desastres.

  4. Se seus bancos de dados forem criptografados com criptografia de dados transparente e usarem sua própria chave de criptografia no Cofre de Chaves do Azure, 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, certificando-se de que o pool seja criado na mesma camada de serviço, com o mesmo nome e o mesmo tamanho.

  6. Se uma auditoria no nível de banco de dados estiver habilitada, desative-a e habilite a auditoria no nível do servidor. Após o failover, a auditoria no nível do banco de dados exigirá tráfego entre regiões, o que não é desejado ou possível após a mudança.

  7. Para auditorias no nível do servidor, certifique-se de que:

    • O contêiner de armazenamento, o Log Analytics ou o hub de eventos com os logs de auditoria existentes são movidos para a região de destino.
    • A configuração de auditoria é configurada no servidor de destino. Para obter mais informações, consulte Auditoria do Banco de dados SQL.

  8. Se sua instância tiver uma política de retenção de longo prazo (LTR), os backups LTR existentes permanecerão associados ao servidor atual. Como o servidor de destino é diferente, você poderá acessar os backups LTR mais antigos na região de origem usando o servidor de origem, mesmo que o servidor seja excluído.

    Nota

    Isso será insuficiente para se deslocar entre a nuvem soberana e uma região pública. Essa migração exigirá mover os backups LTR para o servidor de destino, que não é suportado atualmente.

Prepare-se para se mudar

  1. Crie um grupo de failover separado entre cada pool elástico no servidor de origem e seu pool elástico equivalente no servidor de destino.

  2. Adicione todos os bancos de dados do 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.

    Nota

    Embora seja possível criar um grupo de failover que inclua vários pools elásticos, é altamente recomendável criar 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 precisa mover, poderá executar as etapas de preparação em paralelo e, em seguida, iniciar a etapa de movimentação em paralelo. Esse processo será melhor dimensionado e levará menos tempo em comparação com vários pools elásticos no mesmo grupo de failover.

Monitorizar o processo de preparação

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

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

Sincronização de teste

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

Iniciar a mudança

  1. Conecte-se ao servidor de destino usando o ponto de extremidade <fog-name>.secondary.database.windows.netsecundário .
  2. Use Switch-AzSqlDatabaseFailoverGroup para alternar a instância gerenciada secundária para ser a principal com sincronização completa. Esta operação será bem-sucedida ou reverterá.
  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.

Remova os pools elásticos de origem

Quando a mudança for concluída, remova os recursos na região de origem para evitar cobranças desnecessárias.

  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, contêineres de armazenamento de auditoria, hub de eventos, locatário do Microsoft Entra e outros recursos dependentes para parar de ser cobrado por eles.

Mover uma instância gerenciada

Verificar os pré-requisitos

  1. Para cada instância gerenciada de origem, crie uma instância de destino da Instância Gerenciada SQL do mesmo tamanho na região de destino.
  2. Configure a rede para uma instância gerenciada. Para obter mais informações, consulte Configuração de rede.
  3. Configure o banco de dados de destino master com os logins corretos. Se você não for o administrador da assinatura ou da Instância Gerenciada SQL, trabalhe com o administrador para atribuir as permissões necessárias.
  4. Se seus bancos de dados forem criptografados com criptografia de dados transparente e usarem sua própria chave de criptografia no Cofre de Chaves do Azure, verifique se o Cofre de Chaves do Azure com chaves de criptografia idênticas existe nas regiões de origem e de destino. Para obter mais informações, consulte Criptografia de dados transparente com chaves gerenciadas pelo cliente no Cofre de Chaves do Azure.
  5. Se a auditoria estiver habilitada para a instância gerenciada, certifique-se de que:
    • O contêiner de armazenamento ou hub de eventos com os logs existentes é movido para a região de destino.
    • A auditoria é configurada na instância de destino. Para obter mais informações, consulte Auditoria com instância gerenciada SQL.
  6. Se sua instância tiver uma política de retenção de longo prazo (LTR), os backups LTR existentes permanecerão associados à instância atual. Como a instância de destino é diferente, você poderá acessar os backups LTR mais antigos na região de origem usando a instância de origem, mesmo que a instância seja excluída.

Nota

Isso será insuficiente para se deslocar entre a nuvem soberana e uma região pública. Essa migração exigirá mover os backups LTR para a instância de destino, que não é suportada no momento.

Preparar recursos

Crie um grupo de failover entre cada instância gerenciada de origem e a instância de destino correspondente da Instância Gerenciada do SQL.

A replicação de todos os bancos de dados em cada instância será iniciada automaticamente. Para obter mais informações, consulte Grupos de failover.

Monitorizar o processo de preparação

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

  • ReplicationState = CATCH_UP indica que o banco de dados está sincronizado e pode ser submetido a failover com segurança.
  • ReplicationState = SEEDING indica que o banco de dados ainda não foi semeado e uma tentativa de failover falhará.

Sincronização de teste

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

Iniciar a mudança

  1. Conecte-se à instância gerenciada de destino usando o ponto de extremidade <fog-name>.secondary.<zone_id>.database.windows.netsecundário .
  2. Use Switch-AzSqlDatabaseInstanceFailoverGroup para alternar a instância gerenciada secundária para ser a principal com sincronização completa. Esta operação será bem-sucedida ou reverterá.
  3. Verifique se o comando foi concluído com êxito usando nslook up <fog-name>.secondary.<zone_id>.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 as instâncias gerenciadas de origem

Quando a mudança terminar, remova os recursos na região de origem para evitar cobranças desnecessárias.

  1. Exclua o grupo de failover usando Remove-AzSqlDatabaseInstanceFailoverGroup. Esta ação removerá a configuração do grupo de ativação pós-falha e terminará as ligações de georreplicação entre as duas instâncias.
  2. Exclua a instância gerenciada de origem usando Remove-AzSqlInstance.
  3. Remova quaisquer recursos adicionais no grupo de recursos, como a rede virtual e o grupo de segurança.

Próximos passos

Gerencie seu banco de dados depois que ele for migrado.