Sobre as migrações de grupo de disponibilidade distribuído (DAG, na sigla em inglês)

Além do fluxo padrão de migração de backup e restauração do Cloud Storage, o Database Migration Service é compatível com a migração de bancos de dados autogerenciados do SQL Server para o Cloud SQL para SQL Server usando grupos de disponibilidade distribuída (DAG) do SQL Server.

Em vez de exportar e fazer upload de arquivos de backup e de registro de transações para um bucket do Cloud Storage, o Database Migration Service configura um grupo de disponibilidade distribuído entre o grupo de disponibilidade de origem e um grupo de disponibilidade secundário gerenciado na instância de destino do Cloud SQL para SQL Server. Essa configuração transmite o carregamento completo inicial e as mudanças contínuas do banco de dados diretamente por uma conexão de rede privada.

Nesta página, abordamos os seguintes tópicos:

Quando usar migrações de DAG

A tabela a seguir compara as migrações de backup e restauração padrão com as migrações de grupo de disponibilidade distribuído (DAG, na sigla em inglês) para ajudar você a escolher a melhor abordagem para sua carga de trabalho:

Recurso ou requisito Migrações padrão de backup e restauração (guia de migração padrão) Migrações de grupo de disponibilidade distribuído (DAG, na sigla em inglês) (guia de migração de DAG)
Fontes compatíveis SQL Server autogerenciado, Amazon RDS e Cloud SQL para SQL Server. SQL Server autogerenciado (Enterprise Edition) com grupos de disponibilidade Always On.
Mecanismo de movimentação de dados Arquivos de backup completo (.bak), backup diferencial opcional (.diff) e registro de transações (.trn) em etapas no Cloud Storage. Streaming de rede direto em um endpoint de espelhamento de banco de dados do SQL Server (DBM) (não são necessários arquivos de backup ou buckets do Cloud Storage).
Conectividade de rede Não é necessária conectividade entre a origem e o destino. Conectividade de IP particular bidirecional necessária na porta do banco de dados do SQL Server (padrão 1433) e na porta de espelhamento de banco de dados (padrão 5022).
Acesso ao banco de dados de destino durante a migração Os bancos de dados permanecem no modo RESTORING (inacessíveis para consultas) até a promoção. Os bancos de dados podem ser acessados no modo somente leitura durante a fase de replicação contínua (CDC).
Failback pós-promoção Não compatível (promoção unidirecional). Replicação reversa integrada (fase FAILBACK) do Cloud SQL para SQL Server de volta à instância de origem do SQL Server após a promoção, com suporte para failback sem perda de dados.

Como funcionam as migrações de DAGs

Durante uma migração de DAG, o Database Migration Service orquestra a replicação de dados entre o grupo de disponibilidade de origem e um grupo de disponibilidade secundário gerenciado na instância de destino do Cloud SQL para SQL Server.

Canais de comunicação de rede

O Database Migration Service usa dois canais de comunicação de rede privada entre a instância de origem do SQL Server e a instância de destino do Cloud SQL para SQL Server:

  1. Servidor vinculado do SQL Server (porta do banco de dados, padrão 1433): o Database Migration Service usa um servidor vinculado configurado na instância de destino do Cloud SQL para SQL Server para executar consultas administrativas e de orquestração na instância de origem do SQL Server.
  2. Endpoint de espelhamento de banco de dados (DBM) (padrão 5022): o grupo de disponibilidade de origem e o grupo de disponibilidade de destino do Cloud SQL para SQL Server trocam dados de carga completa inicial autenticados por certificado e alterações contínuas de banco de dados diretamente pela porta DBM.

Fases do ciclo de vida da migração

Um job de migração de DAG passa por quatro fases do ciclo de vida:

  1. Carga completa inicial (FULL_DUMP): quando você inicia o job de migração, o Database Migration Service configura o grupo de disponibilidade distribuído para transmitir a cópia completa inicial de todos os bancos de dados no grupo de disponibilidade de origem pela rede para a instância de destino do Cloud SQL para SQL Server.
  2. Replicação contínua (CDC): quando cada banco de dados conclui o carregamento completo inicial, ele passa para a fase CDC. As alterações contínuas feitas nos bancos de dados de origem são replicadas continuamente pelo endpoint DBM, e é possível se conectar à instância de destino do Cloud SQL para SQL Server para executar consultas de verificação somente leitura nos bancos de dados replicados.
  3. Promoção e replicação reversa (FAILBACK): quando você promove o job de migração (promote sem a flag --failback), o Database Migration Service sincroniza os dois grupos de disponibilidade, inverte os papéis deles para que a instância de destino do Cloud SQL para SQL Server se torne o Principal de leitura/gravação e a instância de origem original do SQL Server se torne o Secundário, e faz a transição da fase do job de migração para FAILBACK (PHASE_FAILBACK na Google Cloud CLI e nas respostas da API). Durante a fase FAILBACK, o job de migração permanece no estado Running e replica novas gravações do Cloud SQL para SQL Server de volta para a instância de origem do SQL Server.
  4. Alternância, interrupção ou conclusão de failback (Stop e Delete):
    • Se você precisar reverter a transição durante a fase FAILBACK, execute o comando promote com a flag --failback (failback = true na API) para realizar uma troca de failback sem perda de dados que restaure a instância original do SQL Server de origem como primária, rebaixe o Cloud SQL para SQL Server de volta para secundário e retorne o job de migração para a fase CDC.
    • É possível executar stop para interromper a replicação de dados por um período curto e definido (as atualizações continuam se acumulando nos registros de transações enquanto a replicação está interrompida). Em um estado Stopped, é possível executar resume para retomar a replicação de dados ou executar delete para concluir a migração e realizar a limpeza necessária.
    • Depois de confirmar que a transição para o Cloud SQL para SQL Server é permanente, exclua (delete) o job de migração (diretamente ou do estado Stopped). A exclusão do job de migração conclui a migração, descarta o grupo de disponibilidade distribuído e os certificados em ambas as instâncias e permite ativar os recursos do Cloud SQL para SQL Server que estão bloqueados durante a migração, como a recuperação pontual (PITR) e as réplicas de leitura.

Bancos de dados compatíveis de origem e de destino

As migrações de DAG são compatíveis com as seguintes edições e versões de banco de dados de origem e destino:

  • Bancos de dados de origem: SQL Server Enterprise Edition autogerenciado (versões 2017, 2019, 2022 e 2025) com o recurso Grupos de disponibilidade Always On ativado (no Windows ou no Linux).
  • Bancos de dados de destino: Cloud SQL para SQL Server Enterprise Edition (versões 2017, 2019, 2022 e 2025).

Limitações conhecidas para migrações de DAG

Considere as seguintes limitações antes de configurar uma migração de DAG:

  • A criação de perfis de conexão de DAG e a criação, verificação, inicialização, promoção ou exclusão de jobs de migração de DAG são compatíveis apenas com a Google Cloud CLI ou a API Database Migration Service. É possível monitorar o progresso do job de migração do DAG, o status por banco de dados e as métricas no console do Google Cloud .
  • As instâncias de origem do SQL Server e de destino do Cloud SQL para SQL Server precisam executar a Enterprise Edition. As origens do Amazon RDS e do Cloud SQL para SQL Server não são compatíveis com migrações de DAG.
  • Cada job de migração de DAG migra todos os bancos de dados contidos em um único grupo de disponibilidade de origem (até o limite de 100 bancos de dados por grupo de disponibilidade distribuído). Os bancos de dados do sistema (master, model, msdb, tempdb) e o banco de dados auxiliar do Database Migration Service (gcp_dms_db) não são migrados.
  • Todos os bancos de dados no grupo de disponibilidade de origem precisam armazenar os arquivos de dados (.mdf e .ndf) no diretório de dados padrão do SQL Server.
  • Requisitos de propriedade do banco de dados:
    • Os bancos de dados de origem não podem ser de propriedade do login sa. Antes de iniciar o job de migração, mude o proprietário do banco de dados de sa para outro login do SQL ou usuário do Windows.
    • Se um banco de dados de origem for de propriedade de um usuário do Active Directory do Windows, você precisará alterar o proprietário do banco de dados de origem para um login do SQL antes de migrar ou integrar a instância de destino do Cloud SQL para SQL Server ao Active Directory para que o Database Migration Service possa criar automaticamente o login correspondente do Windows na instância de destino quando o job de migração for iniciado.
    • Para proprietários de bancos de dados autenticados por SQL, o Database Migration Service cria automaticamente um login correspondente na instância de destino do Cloud SQL para SQL Server com o prefixo gcp_dms_, um identificador de seis caracteres e o nome do proprietário de origem (por exemplo, gcp_dms_a1b2c3_myowner) para ser o proprietário do banco de dados migrado.
  • A conectividade de IP público não é compatível. É necessário configurar a conectividade de IP privado entre a instância de origem do SQL Server e a instância de destino do Cloud SQL para SQL Server usando o acesso a serviços privados ou o Private Service Connect.
  • Restrições do Cloud SQL para SQL Server de destino enquanto o job de migração do DAG existe: desde o momento em que você inicia um job de migração do DAG até excluir o job de migração (incluindo enquanto o job está na fase FAILBACK pós-promoção):
    • A recuperação pontual (PITR, na sigla em inglês) precisa estar desativada na instância de destino do Cloud SQL para SQL Server.
    • As réplicas e os pools de leitura não são compatíveis com a instância de destino do Cloud SQL para SQL Server.
    • A manutenção planejada com inatividade quase zero não é compatível com a instância de destino do Cloud SQL para SQL Server.
    • Não modifique manualmente a flag de banco de dados cloud sql enable dag support na instância de destino do Cloud SQL para SQL Server. O Database Migration Service ativa essa flag automaticamente quando o job de migração é iniciado, e você pode removê-la depois de excluir o job de migração.
  • Como adicionar ou remover bancos de dados durante a migração:
    • É possível adicionar ou remover dinamicamente bancos de dados no grupo de disponibilidade de origem enquanto o job de migração está na fase CDC. O Database Migration Service detecta automaticamente os bancos de dados recém-adicionados, os valida e realiza o carregamento completo inicial deles na instância de destino do Cloud SQL para SQL Server.
    • A remoção de um banco de dados do grupo de disponibilidade de origem interrompe a replicação desse banco de dados, o remove dos objetos rastreados do job de migração e o deixa no estado RESTORING na instância de destino do Cloud SQL para SQL Server (ele não é recuperado quando o job é promovido).
    • Não é possível adicionar novos bancos de dados diretamente na instância de destino do Cloud SQL para SQL Server durante a fase FAILBACK pós-promoção. O grupo de disponibilidade de destino não é atualizado com novos bancos de dados criados no Cloud SQL.
  • Observações sobre como interromper, retomar e reiniciar jobs de migração de DAG:
    • Interromper (stop) um job de migração de DAG pausa a replicação de dados, fazendo com que as atualizações se acumulem nos registros de transações enquanto a replicação está pausada. Interrompa um job de migração de DAG apenas por um período curto e definido para que os discos de registro de transações não fiquem cheios. No estado Stopped, é possível executar resume para retomar a replicação de dados ou executar delete para concluir a migração e realizar a limpeza necessária.
    • Reiniciar (restart) um job de migração de DAG com falha ou interrompido exclui os bancos de dados migrados na instância de destino do Cloud SQL para SQL Server e executa novamente o carregamento completo inicial (FULL_DUMP) pela rede.

A seguir