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

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.

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.

   • A maneira mais simples de fazer isso é adicionar a chave de criptografia do cofre de chaves existente (que está sendo usado como Protetor TDE no servidor de origem) ao servidor de destino e, em seguida, definir a chave como o Protetor TDE no servidor de destino

     Nota

     Um servidor ou instância gerenciada em uma região agora pode ser conectado a um cofre de chaves em qualquer outra região.

   • Como prática recomendada para garantir que o servidor de destino tenha acesso a chaves de criptografia mais antigas (necessárias para restaurar backups de banco de dados), execute o cmdlet Get-AzSqlServerKeyVaultKey no servidor de origem ou o cmdlet Get-AzSqlInstanceKeyVaultKey na instância gerenciada 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 como configurar o TDE gerenciado pelo cliente no servidor de destino, consulte Criptografia de dados transparente do SQL do Azure com chaves gerenciadas pelo cliente no Cofre de Chaves do Azure.
   • 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 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.

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.