Grupo de disponibilidade distribuído com propagação manual

TL;DR:

Parece pela descrição e comentários atuais que você pode ter adicionado bancos de dados ao AG no encaminhamento antes de ingressar no DAG . Em vez disso, associe-se primeiro ao DAG e , em seguida, adicione os bancos de dados na seguinte ordem:

1. Criar AG1
   • Adicionar bancos de dados ao AG1
2. Criar AG2 (sem bancos de dados)
3. Crie o DAG
   • Junte os AGs 1 e 2 ao DAG do AG1
   • Junte os AGs 1 e 2 ao DAG do AG2
4. Adicionar bancos de dados ao AG2
5. Lucro?

Resposta de formulário longo (er)

Supondo muitas coisas como ...

1. Listeners/Cluster/Instances já estão configurados
2. Já existe um AG...
   • tanto no PRIMARYcomo noFORWARDER
   • isso não é o mesmo AG
   • e nenhum deles já é membro de outro DAG
   • e o FORWARDERAG está vazio e pronto para semear
3. Você tem armazenamento compartilhado que pode ser acessado de ambas as réplicas

... você pode... ^{Os scripts a seguir estão em sqlcmdformato.}

Etapa 0. Desative os backups de log |OLD_AG|(opcional)

Você pode ignorar esta etapa se:

1. Se você não se importa com um LSN potencialmente " alvo em movimento " no final do processo ou
2. Você pode concluir todo o processo dentro da janela de backup de log de todos os bancos de dados no AG

Etapa 1. Crie o DAG

CREATEuma vez no primário atual e ALTER ... JOINno remetente potencial. Execute como uma conta de serviço apropriada para que você não acabe com partes da arquitetura pertencentes à sua conta de usuário.

Na corrente PRIMARY...

:connect |OLD_AG|.|DOMAIN|
execute as login = 'sa'

-- double check local replica is manual seeding first
alter availability group [|OLD_AG|]
    modify replica on '|THIS_REPLICA|'
    with (seeding_mode = manual);

create availability group [|DAG_X|]
    with (distributed)
    availability group on 
        '|OLD_AG|' with ( 
            listener_url      = 'TCP://|OLD_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        ),
        '|NEW_AG|' with ( 
            listener_url      = 'TCP://|NEW_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        );
go

Na perspectiva FORWARDER...

:connect |NEW_AG|.|DOMAIN|
execute as login = 'sa'

alter availability group [|DAG_X|]
    join availability group on 
        '|OLD_AG|' with ( 
            listener_url      = 'TCP://|OLD_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        ),
        '|NEW_AG|' with ( 
            listener_url      = 'TCP://|NEW_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        );
go

Etapa 2. Backups completos

Você sabia que pode anexar backups de log a copy_onlyfulls ? Nem eu até muito recentemente! Mas usando copy_onlyaqui você pode

1. proteja sua cadeia de backup de qualquer tolice de migração e
2. reduzir o comprimento da cadeia de restauração no final do processo.

exec as... não é estritamente necessário para esta etapa.

:connect |OLD_AG|.|DOMAIN|

backup database DB1 to disk = N'\\my.shared.storage\backups\DB1.bak' 
    with copy_only, compression;
backup database DB2 to disk = N'\\my.shared.storage\backups\DB2.bak' 
    with copy_only, compression;
go

Etapa 3. Restaurar

Mais uma vez, executando como uma conta de serviço apropriada.

:connect |NEW_AG|.|DOMAIN|
execute as login = 'sa'

restore database DB1 from disk = N'\\my.shared.storage\backups\DB1.bak' 
    with norecovery;
restore database DB2 from disk = N'\\my.shared.storage\backups\DB2.bak' 
    with norecovery;
go

Etapa 3(b). Você deixou os backups de log ativados?

Nbd, mas anexe-os agora ¯\_(ツ)_/¯

1. Executando como uma conta de serviço apropriada
2. with norecovery

Etapa 4. No encaminhador, junte os DBs ao novo AG

:connect |NEW_AG|.|DOMAIN|
execute as login = 'sa'

alter database DB1 set hadr availability group = [|NEW_AG|];
alter database DB2 set hadr availability group = [|NEW_AG|];
go

De grupos de disponibilidade distribuídos

Os grupos de disponibilidade distribuídos foram projetados com propagação automática para ser o método principal usado para inicializar a réplica primária no segundo grupo de disponibilidade.

Uma restauração completa do banco de dados na réplica primária do segundo grupo de disponibilidade é possível se você fizer o seguinte:

• Restaure o backup do banco de dados WITH NORECOVERY.
• Se necessário, restaure os backups de log de transações apropriados COM NORECOVERY.
• Crie o segundo grupo de disponibilidade sem especificar um nome de banco de dados e com SEEDING_MODE set to AUTOMATIC.
• Crie o grupo de disponibilidade distribuído usando a propagação automática.