Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL Server
Um grupo de disponibilidade distribuída (AG) é um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade separados. Os grupos de disponibilidade distribuídos estão disponíveis a partir do SQL Server 2016.
Este artigo descreve o recurso de grupo de disponibilidade distribuída. Para configurar um grupo de disponibilidade distribuída, consulte Configurar grupos de disponibilidade distribuída.
Visão geral
Um grupo de disponibilidade distribuída é um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade separados. Os grupos de disponibilidade que participam de um grupo de disponibilidade distribuída não precisam estar no mesmo local. Eles podem ser físicos, virtuais, locais, na nuvem pública ou em qualquer lugar que ofereça suporte a uma implantação de grupo de disponibilidade. Isso inclui entre diferentes domínios e até mesmo entre diferentes plataformas - como entre um grupo de disponibilidade hospedado no Linux e um hospedado no Windows. Contanto que dois grupos de disponibilidade possam se comunicar, você pode configurar um grupo de disponibilidade distribuído com eles.
Um grupo de disponibilidade tradicional tem recursos configurados em um WSFC (Cluster de Failover do Windows Server) ou, se estiver no Linux, no Pacemaker. Um grupo de disponibilidade distribuída não configura nada no cluster subjacente (WSFC ou Pacemaker). Tudo sobre ele é mantido dentro do SQL Server. Para saber como exibir informações de um grupo de disponibilidade distribuído, consulte Exibindo informações de grupo de disponibilidade distribuída.
Um grupo de disponibilidade distribuída requer que os grupos de disponibilidade subjacentes tenham um ouvinte. Em vez de fornecer o nome do servidor subjacente para uma instância isolada (ou, no caso de uma instância de cluster de failover do SQL Server [FCI], o valor associado ao recurso de nome de rede), como faria com um grupo de disponibilidade tradicional, você deve especificar o "listener" configurado para o grupo de disponibilidade distribuído com o parâmetro ENDPOINT_URL ao criá-lo. Embora cada grupo de disponibilidade subjacente do grupo de disponibilidade distribuída tenha um ouvinte, um grupo de disponibilidade distribuída não tem ouvinte.
A figura a seguir mostra uma exibição de alto nível de um grupo de disponibilidade distribuída que abrange dois grupos de disponibilidade (AG 1 e AG 2), cada um configurado em seu próprio WSFC. O grupo de disponibilidade distribuída tem um total de quatro réplicas, com duas em cada grupo de disponibilidade. Cada grupo de disponibilidade pode suportar até o número máximo de réplicas, portanto, um grupo de disponibilidade distribuído pode ter até 18 réplicas no total.
Você pode configurar a movimentação de dados em grupos de disponibilidade distribuídos como síncrona ou assíncrona. No entanto, a movimentação de dados é ligeiramente diferente dentro de grupos de disponibilidade distribuídos em comparação com um grupo de disponibilidade tradicional. Embora cada grupo de disponibilidade tenha uma réplica primária, há apenas uma cópia dos bancos de dados que participam de um grupo de disponibilidade distribuído que pode aceitar inserções, atualizações e exclusões. Como mostrado na figura a seguir, AG 1 é o grupo de disponibilidade principal. Sua réplica primária envia transações para as réplicas secundárias do AG 1 e para a réplica primária do AG 2. A réplica primária do AG 2 também é conhecida como forwarder. Um replicador é uma réplica primária num grupo de disponibilidade secundário num grupo de disponibilidade distribuído. O encaminhador recebe transações da réplica primária no grupo de disponibilidade primária e as encaminha para as réplicas secundárias em seu próprio grupo de disponibilidade. Em seguida, o encaminhador mantém atualizadas as réplicas secundárias do AG 2.
A única maneira de fazer com que a réplica principal do AG 2 aceite inserções, atualizações e exclusões é executar um failover manual do grupo de disponibilidade distribuído do AG 1. Na figura anterior, como o AG 1 contém a cópia gravável do banco de dados, ao emitir um failover, o AG 2 passa a ser o grupo de disponibilidade que pode executar inserções, atualizações e eliminação de dados. Para obter informações sobre como fazer failover de um grupo de disponibilidade distribuído para outro, consulte Failover para um grupo de disponibilidade secundário.
Observação
- Os grupos de disponibilidade distribuídos no SQL Server 2016 oferecem suporte a failover somente de um grupo de disponibilidade para outro usando a opção
FORCE_FAILOVER_ALLOW_DATA_LOSS. - Ao usar a replicação transacional com grupos de disponibilidade distribuídos, a réplica de encaminhamento não pode ser configurada como um publicador.
Alterações do SQL Server 2025
O SQL Server 2025 (17.x) Preview introduz as seguintes alterações:
Melhoria na sincronização distribuída do AG
O SQL Server 2025 (17.x) Preview introduz uma alteração no mecanismo de sincronização interno para grupos de disponibilidade distribuídos para melhorar o desempenho da sincronização reduzindo a saturação da rede quando a réplica do encaminhador está no modo de confirmação assíncrona. Essa alteração é habilitada por padrão e não requer nenhuma configuração.
Observação
Configurar seu grupo de disponibilidade distribuído com uma incompatibilidade entre os modos de disponibilidade dos dois grupos de disponibilidade subjacentes não é recomendado e pode introduzir latência de sincronização. Ambos os grupos de disponibilidade devem ser configurados com o mesmo modo de disponibilidade (síncrono ou assíncrono) para garantir o desempenho e a sincronização ideais.
Suporte de grupo de disponibilidade contida
O SQL Server 2025 (17.x) Preview apresenta suporte para um grupo de disponibilidade distribuído contido. Se pretender usar um AG contido como encaminhador num grupo de disponibilidade distribuído, deve criar o AG contido utilizando a cláusula AUTOSEEDING_SYSTEM_DATABASES para a opção WITH | CONTAINED do comando CREATE AVAILABILITY GROUP.
Requisitos de versão e edição
Os grupos de disponibilidade distribuída no SQL Server 2017 ou posterior podem misturar versões principais do SQL Server no mesmo grupo de disponibilidade distribuída. O AG que contém leitura/escrita primária pode ser a mesma versão ou inferior aos outros AG que participam no AG distribuído. Os outros AGs podem ser da mesma versão ou superior. Este cenário destina-se a cenários de atualização e migração. Por exemplo, se o AG que contém a réplica primária de leitura/gravação for o SQL Server 2016, mas você quiser atualizar/migrar para o SQL Server 2017 ou posterior, o outro AG participante do AG distribuído poderá ser configurado com o SQL Server 2017.
Como o recurso de grupos de disponibilidade distribuídos não existia no SQL Server 2012 ou 2014, os grupos de disponibilidade criados com essas versões não podem participar de grupos de disponibilidade distribuídos.
Observação
Dependendo da versão do SQL Server, ao se conectar aos serviços do Azure (como o link Instância Gerenciada), é possível configurar um grupo de disponibilidade distribuída com a edição Standard ou uma combinação de edições Standard e Enterprise. Reveja KB5016729 para saber mais.
Como há dois grupos de disponibilidade separados, o processo de instalação de um service pack ou atualização cumulativa em uma réplica que participa de um grupo de disponibilidade distribuído é ligeiramente diferente do de um grupo de disponibilidade tradicional:
Comece atualizando as réplicas do segundo grupo de disponibilidade no grupo de disponibilidade distribuído.
Corrija as réplicas do grupo de disponibilidade principal no grupo de disponibilidade distribuída.
Assim como num grupo de disponibilidade padrão, faça a transferência do grupo de disponibilidade principal para uma de suas próprias réplicas (não para a principal do segundo grupo de disponibilidade) e atualize-o. Se não houver nenhuma réplica além da principal, será necessário um failover manual para o segundo grupo de disponibilidade.
Versões do Windows Server e grupos de disponibilidade distribuídos
Um grupo de disponibilidade distribuída abrange vários grupos de disponibilidade, cada um em seu próprio WSFC subjacente, e um grupo de disponibilidade distribuída é uma construção somente do SQL Server. Isso significa que os WSFCs que abrigam os grupos de disponibilidade individuais podem ter diferentes versões principais do Windows Server. As versões principais do SQL Server devem ser as mesmas, conforme discutido na seção anterior. Assim como a figura inicial, a figura a seguir mostra AG 1 e AG 2 participando de um grupo de disponibilidade distribuída, mas cada um dos WSFCs é uma versão diferente do Windows Server.
Os WSFCs individuais e seus grupos de disponibilidade correspondentes seguem regras tradicionais. Ou seja, eles podem ser associados a um domínio ou não a um domínio (Windows Server 2016 ou posterior). Quando dois grupos de disponibilidade diferentes são combinados em um único grupo de disponibilidade distribuída, há quatro cenários:
- Ambos os WSFCs estão ligados ao mesmo domínio.
- Cada WSFC é associado a um domínio diferente.
- Um WSFC está associado a um domínio e um WSFC não está associado a um domínio.
- Nem o WSFC está associado a um domínio.
Quando ambos os WSFCs são associados ao mesmo domínio (domínios não confiáveis), você não precisa fazer nada de especial ao criar o grupo de disponibilidade distribuída. Para grupos de disponibilidade e WSFCs que não estão associados ao mesmo domínio, use certificados para fazer o grupo de disponibilidade distribuído funcionar, da mesma forma que você pode criar um grupo de disponibilidade para um grupo de disponibilidade independente de domínio. Para ver como configurar certificados para um grupo de disponibilidade distribuído, siga as etapas 3 a 13 em Criar um grupo de disponibilidade independente de domínio.
Com um grupo de disponibilidade distribuída, as réplicas primárias em cada grupo de disponibilidade subjacente devem possuir os certificados umas das outras. Se você já tiver pontos de extremidade que não estão usando certificados, reconfigure esses pontos de extremidade usando ALTER ENDPOINT para refletir o uso de certificados.
Cenários de utilização
Aqui estão os três principais cenários de uso para um grupo de disponibilidade distribuída:
- Recuperação de desastres e configurações mais fáceis em vários locais
- Migração para novo hardware ou configurações, o que pode incluir o uso de novo hardware ou a alteração dos sistemas operacionais subjacentes
- Aumentar o número de réplicas legíveis além de oito em um único grupo de disponibilidade abrangendo vários grupos de disponibilidade
Recuperação de desastres e cenários em vários locais
Um grupo de disponibilidade tradicional exige que todos os servidores façam parte do mesmo WSFC, o que pode dificultar a abrangência de vários data centers. A figura a seguir mostra como é uma arquitetura tradicional de grupo de disponibilidade multissite, bem como o fluxo de dados. Há uma réplica primária que envia transações para todas as réplicas secundárias. Essa configuração é, em alguns aspetos, menor do que um grupo de disponibilidade distribuído. Por exemplo, deve implementar elementos como o Active Directory (se aplicável) e a testemunha para o quórum num ambiente WSFC. Também pode ser necessário levar em conta outros aspetos de um WSFC, como alterar os votos dos nós.
Os grupos de disponibilidade distribuídos oferecem um cenário de implantação mais flexível para grupos de disponibilidade que abrangem vários data centers. Você pode até mesmo usar grupos de disponibilidade distribuídos em que recursos como envio de logs foram usados no passado para cenários como recuperação de desastres. No entanto, ao contrário do envio de logs, os grupos de disponibilidade distribuídos não podem ter a aplicação atrasada das transações. Isso significa que os grupos de disponibilidade ou os grupos de disponibilidade distribuídos não podem ajudar em caso de erro humano no qual os dados são atualizados ou excluídos incorretamente.
Os grupos de disponibilidade distribuída são acoplados de forma flexível, o que neste caso significa que eles não exigem um único WSFC e são mantidos pelo SQL Server. Como os WSFCs são mantidos individualmente e a sincronização é principalmente assíncrona entre os dois grupos de disponibilidade, é mais fácil configurar a recuperação de desastres em outro site. As réplicas primárias em cada grupo de disponibilidade sincronizam suas próprias réplicas secundárias.
- Somente failover manual é suportado para um grupo de disponibilidade distribuído. Em uma situação de recuperação de desastres em que você está trocando de data center, não deve configurar o failover automático (com raras exceções).
- Provavelmente não precisará definir alguns dos itens ou parâmetros tradicionais para clusters WSFC de múltiplos sites ou sub-redes, como o CrossSubnetThreshold. No entanto, ainda será necessário considerar a latência da rede em uma camada diferente para o transporte de dados. A diferença é que cada WSFC mantém sua própria disponibilidade; O cluster não é uma grande entidade de quatro nós. Você tem dois WSFCs separados de dois nós, conforme mostrado na figura anterior.
- Recomendamos a movimentação assíncrona de dados, pois essa abordagem seria para fins de recuperação de desastres.
- Se você configurar a movimentação de dados síncrona entre a réplica primária e pelo menos uma réplica secundária do segundo grupo de disponibilidade e configurar a movimentação síncrona no grupo de disponibilidade distribuída, um grupo de disponibilidade distribuída aguardará até que todas as cópias síncronas reconheçam que possuem os dados. Se vários grupos de disponibilidade distribuída estiverem encadeados em margarida (AG1 -> AG2 -> AG3) e definidos como síncronos, um grupo de disponibilidade distribuída aguardará até que a última réplica do último grupo de disponibilidade tenha sido atualizada.
Migrar
Como os grupos de disponibilidade distribuídos oferecem suporte a duas configurações de grupo de disponibilidade completamente diferentes, eles permitem não apenas cenários mais fáceis de recuperação de desastres e em vários locais, mas também cenários de migração. Quer esteja a migrar para novo hardware ou máquinas virtuais (no local ou IaaS na nuvem pública), a configuração de um grupo de disponibilidade distribuído permite que ocorra uma migração onde, no passado, poderá ter utilizado cópia de segurança, cópia e restauração, ou envio de registos.
A capacidade de migrar é especialmente útil em cenários em que você está alterando ou atualizando o sistema operacional subjacente enquanto mantém a mesma versão do SQL Server. Embora o Windows Server 2016 permita uma atualização contínua do Windows Server 2012 R2 no mesmo hardware, a maioria dos usuários opta por implantar novo hardware ou máquinas virtuais.
Para concluir a migração para a nova configuração, no final do processo, pare todo o tráfego de dados para o grupo de disponibilidade original e altere o grupo de disponibilidade distribuído para movimentação de dados síncrona. Essa ação garante que a réplica primária do segundo grupo de disponibilidade esteja totalmente sincronizada, para que não haja perda de dados. Depois de verificar a sincronização, faça failover do grupo de disponibilidade distribuída para o grupo de disponibilidade secundário. Para obter mais informações, consulte Comutação automática para um grupo de disponibilidade secundário.
Após a migração, em que o segundo grupo de disponibilidade agora é o novo grupo de disponibilidade principal, talvez seja necessário executar uma das seguintes etapas:
- Renomeie o ouvinte no grupo de disponibilidade secundário (e, possivelmente, exclua ou renomeie o antigo no grupo de disponibilidade primário original) ou recrie-o com o ouvinte do grupo de disponibilidade primário original, para que aplicativos e usuários possam acessar a nova configuração.
- Se uma renomeação ou recriação não for possível, aponte aplicativos e usuários para o ouvinte no segundo grupo de disponibilidade.
Migrar para versões superiores do SQL Server
Durante um cenário de migração, embora seja possível configurar um AG distribuído para migrar seus bancos de dados para um destino do SQL Server que seja uma versão superior à origem, há algumas limitações.
Quando você configura o AG distribuído com um destino de migração do SQL Server que é uma versão superior à origem, a propagação automática não é suportada, portanto, o modo de propagação deve ser definido como MANUAL. Se você não desativar o AUTO-SEEDING, sua migração falhará e você verá o erro 946 "Não é possível abrir o banco de dados 'DistributionAG' versão xxx. Atualize o banco de dados para a versão mais recente" no log de erros. Você deve definir o modo de propagação como MANUAL e executar manualmente um backup completo e de log de transações do banco de dados de origem a partir do AG primário. Em seguida, restaure-o manualmente, juntamente com o log de transações, para o AG secundário. Para saber mais, revise as etapas de semeadura manual para configurar seu AG distribuído e scripts para fazer backup e restaurar seu banco de dados do AG primário para o AG secundário.
Supondo que o AG secundário (AG2) seja o destino de migração e seja uma versão superior ao AG primário (AG1), considere as seguintes limitações:
- Você não terá acesso para leitura a nenhuma das bases de dados de réplica no AG secundário, desde que o AG primário esteja numa versão inferior.
- Durante este período, as atualizações continuarão a fluir do AG primário (AG1) para o AG secundário (AG2), mas o estado do AG secundário será exibido como Parcialmente Saudável e os bancos de dados em réplicas secundárias do AG secundário (AG2) serão mostrados como Sincronizando/Em Recuperação (mesmo que o AG esteja em confirmação síncrono).
- Depois de o AG distribuído ser transferido para a versão mais recente (AG2), AG2 deve tornar-se operacional.
- Durante este tempo, o retorno para AG1 não será possível, pois está numa versão inferior.
- Como o AG1 está em uma versão inferior, as atualizações do AG2 após o failover para o AG2 não serão replicadas para o AG1.
- A partir daqui, escolha se deseja desativar a AG original (primária) ou se deseja atualizar a AG1 e manter a AG distribuída.
- Se você optar por desativar o AG1, remova o AG primário original do AG distribuído e o processo será concluído.
- Se você optar por manter o AG distribuído, atualize a versão do SQL Server para AG1 para corresponder ao AG2. Depois que o AG1 é atualizado, o AG1 torna-se íntegro, o AG distribuído torna-se íntegro, as réplicas alcançam a sincronização e o failback torna-se possível.
Aumente o número de réplicas legíveis
Um único grupo de disponibilidade distribuída pode ter até 16 réplicas secundárias, conforme necessário. Assim, pode ter até 18 cópias para leitura, incluindo as duas réplicas primárias dos diferentes grupos de disponibilidade. Essa abordagem significa que mais de um site pode ter acesso quase em tempo real para relatórios para vários aplicativos.
Os grupos de disponibilidade distribuídos podem ajudá-lo a expandir uma infraestrutura de leitura exclusiva mais do que seria possível com apenas um único grupo de disponibilidade. Um grupo de disponibilidade distribuída pode expandir réplicas legíveis de duas maneiras:
- Você pode usar a réplica primária do segundo grupo de disponibilidade em um grupo de disponibilidade distribuída para criar outro grupo de disponibilidade distribuída, mesmo que o banco de dados não esteja em RECUPERAÇÃO.
- Você também pode usar a réplica primária do primeiro grupo de disponibilidade para criar outro grupo de disponibilidade distribuído.
Em outras palavras, uma réplica primária pode participar de diferentes grupos de disponibilidade distribuída. A figura seguinte mostra a AG 1 e a AG 2 ambas a participar na Distributed AG 1, enquanto a AG 2 e a AG 3 participam na Distributed AG 2. A réplica primária (ou encaminhador) do AG 2 é uma réplica secundária para o Distributed AG 1 e uma réplica primária do Distributed AG 2.
A figura a seguir mostra AG 1 como a réplica primária para dois grupos de disponibilidade distribuída diferentes: AG 1 distribuído (composto por AG 1 e AG2) e AG 2 distribuído (composto por AG 1 e AG 3).
Em ambos os exemplos anteriores, pode haver até 27 réplicas totais nos três grupos de disponibilidade, todas as quais podem ser usadas para consultas somente leitura.
O roteamento somente leitura não funciona completamente com Grupos de Disponibilidade Distribuídos. Mais especificamente,
- Read-Only O roteamento pode ser configurado e funcionará para o grupo de disponibilidade principal do grupo de disponibilidade distribuído.
- Read-Only O roteamento pode ser configurado, mas não funcionará para o grupo de disponibilidade secundário do grupo de disponibilidade distribuído. Todas as consultas que utilizem o ouvinte para se conectar ao grupo de disponibilidade secundário são direcionadas para a réplica primária desse grupo de disponibilidade secundário. Caso contrário, você precisará configurar cada réplica para permitir todas as conexões como uma réplica secundária e acessá-las diretamente. No entanto, o roteamento de leitura única funcionará se o grupo de disponibilidade secundário se tornar primário após uma transferência de função. Esse comportamento pode ser alterado em uma atualização para o SQL Server 2016 ou em uma versão futura do SQL Server.
Inicializar grupos de disponibilidade secundária
Os grupos de disponibilidade distribuídos foram projetados com propagação automática para ser o principal método 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 COM NORECOVERY.
- Se necessário, restaure os backups de log de transações adequados COM NORECOVERY.
- Crie o segundo grupo de disponibilidade sem especificar um nome de banco de dados e com SEEDING_MODE definido como AUTOMÁTICO.
- Crie o grupo de disponibilidade distribuída usando a propagação automática.
Quando você adiciona a réplica primária do segundo grupo de disponibilidade ao grupo de disponibilidade distribuída, a réplica é verificada em relação aos bancos de dados primários do primeiro grupo de disponibilidade e a propagação automática captura o banco de dados até a origem. Há algumas ressalvas:
A saída mostrada na
sys.dm_hadr_automatic_seedingréplica primária do segundo grupo de disponibilidade exibirá umcurrent_statede FAILED com o motivo "Seeding Check Message Timeout".O log de erros atual do SQL Server na réplica primária do segundo grupo de disponibilidade mostrará que a propagação automática funcionou e que os LSNs foram sincronizados.
A saída mostrada na
sys.dm_hadr_automatic_seedingréplica primária do primeiro grupo de disponibilidade mostrará um estado atual de CONCLUÍDO.A semeadura automática também tem um comportamento diferente com grupos de disponibilidade distribuídos. Para que a propagação automática comece na segunda réplica, você deve executar o comando command
ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASEna réplica. Embora essa condição ainda seja válida para qualquer réplica secundária que participe do grupo de disponibilidade subjacente, a réplica primária do segundo grupo de disponibilidade já tem as permissões certas para permitir que a propagação automática comece depois de ser adicionada ao grupo de disponibilidade distribuída.
Observação
- O grupo de disponibilidade secundário deve usar o mesmo ponto de extremidade de espelhamento da base de dados. Caso contrário, a replicação será interrompida após um failover local.
- Os grupos de disponibilidade subjacentes devem estar no mesmo modo de disponibilidade - ambos os grupos de disponibilidade devem estar no modo de confirmação síncrona ou ambos devem estar no modo de confirmação assíncrona. Se não tens certeza de qual usar, coloca ambos em modo de confirmação assíncrona até estares pronto para efetuar o failover.
Monitorizar a saúde
Um grupo de disponibilidade distribuída é uma construção somente do SQL Server e não é visto no WSFC subjacente. O exemplo de código a seguir mostra dois WSFCs diferentes (CLUSTER_A e CLUSTER_B), cada um com seus próprios grupos de disponibilidade. Apenas AG1 em CLUSTER_A e AG2 em CLUSTER_B são discutidos aqui.
PS C:\> Get-ClusterGroup -Cluster CLUSTER_A
Name OwnerNode State
---- --------- -----
AG1 DENNIS Online
Available Storage GLEN Offline
Cluster Group JY Online
New_RoR DENNIS Online
Old_RoR DENNIS Online
SeedingAG DENNIS Online
PS C:\> Get-ClusterGroup -Cluster CLUSTER_B
Name OwnerNode State
---- --------- -----
AG2 TOMMY Online
Available Storage JC Offline
Cluster Group JC Online
Todas as informações detalhadas sobre um grupo de disponibilidade distribuído estão no SQL Server, especificamente nas exibições de gerenciamento dinâmico do grupo de disponibilidade. Atualmente, as únicas informações mostradas no SQL Server Management Studio para um grupo de disponibilidade distribuído estão na réplica primária para os grupos de disponibilidade. Conforme mostrado na figura a seguir, na pasta Grupos de Disponibilidade, o SQL Server Management Studio mostra que há um grupo de disponibilidade distribuído. A figura mostra o AG1 como uma réplica primária para um grupo de disponibilidade individual que é local para essa instância, não para um grupo de disponibilidade distribuída.
No entanto, se você clicar com o botão direito do mouse no grupo de disponibilidade distribuída, nenhuma opção estará disponível (consulte a figura a seguir) e as pastas expandidas Bancos de Dados de Disponibilidade, Ouvintes do Grupo de Disponibilidade e Réplicas de Disponibilidade estarão vazias. O SQL Server Management Studio 16 exibe esse resultado, mas ele pode mudar em uma versão futura do SQL Server Management Studio.
Conforme mostrado na figura a seguir, as réplicas secundárias não mostram nada no SQL Server Management Studio relacionado ao grupo de disponibilidade distribuída. Esses nomes de grupos de disponibilidade correspondem às funções apresentadas na imagem WSFC anterior do CLUSTER_A.
A DMV lista todos os nomes de réplicas de alta disponibilidade
Os mesmos conceitos são válidos quando se utilizam as vistas de gestão dinâmica. Usando a consulta a seguir, você pode ver todos os grupos de disponibilidade (regulares e distribuídos) e os nós que participam deles. Esse resultado será exibido somente se você consultar a réplica primária em um dos WSFCs que participam do grupo de disponibilidade distribuída. Há uma nova coluna no modo de exibição sys.availability_groups de gerenciamento dinâmico chamada is_distributed, que é 1 quando o grupo de disponibilidade é um grupo de disponibilidade distribuído. Para ver esta coluna:
-- shows replicas associated with availability groups
SELECT
ag.[name] AS [AG Name],
ag.Is_Distributed,
ar.replica_server_name AS [Replica Name]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
ON ag.group_id = ar.group_id;
GO
Um exemplo de saída do segundo WSFC que está participando em um grupo de disponibilidade distribuída é mostrado na figura a seguir. O SPAG1 é composto por duas réplicas: DENNIS e JY. No entanto, o grupo de disponibilidade distribuída chamado SPDistAG tem os nomes dos dois grupos de disponibilidade participantes (SPAG1 e SPAG2) em vez dos nomes das instâncias, como acontece com um grupo de disponibilidade tradicional.
DMV para listar saúde AG distribuída
No SQL Server Management Studio, qualquer status mostrado no Painel e em outras áreas é para sincronização local somente dentro desse grupo de disponibilidade. Para exibir a integridade de um grupo de disponibilidade distribuído, consulte as exibições de gerenciamento dinâmico. A consulta de exemplo a seguir estende e refina a consulta anterior:
-- shows sync status of distributed AG
SELECT
ag.[name] AS [AG Name],
ag.is_distributed,
ar.replica_server_name AS [Underlying AG],
ars.role_desc AS [Role],
ars.synchronization_health_desc AS [Sync Status]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
ON ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO
Detran para visualizar o desempenho subjacente
Para estender ainda mais a consulta anterior, você também pode ver o desempenho subjacente por meio das exibições de gerenciamento dinâmico adicionando sys.dm_hadr_database_replicas_states. Atualmente, o modo de exibição de gerenciamento dinâmico armazena informações apenas sobre o segundo grupo de disponibilidade. A consulta de exemplo a seguir, executada no grupo de disponibilidade principal, produz a saída de exemplo mostrada abaixo:
-- shows underlying performance of distributed AG
SELECT
ag.[name] AS [Distributed AG Name],
ar.replica_server_name AS [Underlying AG],
dbs.[name] AS [Database],
ars.role_desc AS [Role],
drs.synchronization_health_desc AS [Sync Status],
drs.log_send_queue_size,
drs.log_send_rate,
drs.redo_queue_size,
drs.redo_rate
FROM sys.databases AS dbs
INNER JOIN sys.dm_hadr_database_replica_states AS drs
ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups AS ag
ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas AS ar
ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO
DMV para visualizar contadores de desempenho para Grupos de Disponibilidade distribuídos
A consulta abaixo exibe contadores de desempenho associados ao grupo de disponibilidade distribuída específico.
-- displays OS performance counters related to the distributed ag named 'distributedag'
SELECT * FROM sys.dm_os_performance_counters WHERE instance_name LIKE '%distributed%'
Observação
O LIKE filtro deve ter o nome do grupo de disponibilidade distribuída. Neste exemplo, o nome do grupo de disponibilidade distribuída é 'distributedag'. Altere o LIKE modificador para refletir o nome do seu grupo de disponibilidade distribuído.
DMV para mostrar o estado de ambos AG e AG Distribuído
A consulta abaixo exibe uma grande variedade de informações sobre a saúde do grupo de disponibilidade e do grupo de disponibilidade distribuído. (Reproduzido com permissão de Tracy Boggiano.)
-- displays sync status, send rate, and redo rate of availability groups,
-- including distributed AG
SELECT ag.name AS [AG Name],
ag.is_distributed,
ar.replica_server_name AS [AG],
dbs.name AS [Database],
ars.role_desc,
drs.synchronization_health_desc,
drs.log_send_queue_size,
drs.log_send_rate,
drs.redo_queue_size,
drs.redo_rate,
drs.suspend_reason_desc,
drs.last_sent_time,
drs.last_received_time,
drs.last_hardened_time,
drs.last_redone_time,
drs.last_commit_time,
drs.secondary_lag_seconds
FROM sys.databases dbs
INNER JOIN sys.dm_hadr_database_replica_states drs
ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups ag
ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars
ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas ar
ON ar.replica_id = ars.replica_id
--WHERE ag.is_distributed = 1
GO
DMVs para visualizar metadados de Grupos de Disponibilidade distribuídos
As consultas abaixo exibirão informações sobre URLs de ponto de extremidade usadas pelos grupos de disponibilidade, incluindo o grupo de disponibilidade distribuída. (Reproduzido com permissão de David Barbarin.)
-- shows endpoint url and sync state for ag, and dag
SELECT
ag.name AS group_name,
ag.is_distributed,
ar.replica_server_name AS replica_name,
ar.endpoint_url,
ar.availability_mode_desc,
ar.failover_mode_desc,
ar.primary_role_allow_connections_desc AS allow_connections_primary,
ar.secondary_role_allow_connections_desc AS allow_connections_secondary,
ar.seeding_mode_desc AS seeding_mode
FROM sys.availability_replicas AS ar
JOIN sys.availability_groups AS ag
ON ar.group_id = ag.group_id;
GO
Detran mostra estado atual de semeadura
A consulta abaixo exibe informações sobre o estado atual da semeadura. Isso é útil para solucionar erros de sincronização entre réplicas. (Reproduzido com permissão de David Barbarin.)
-- shows current_state of seeding
SELECT ag.name AS aag_name,
ar.replica_server_name,
d.name AS database_name,
has.current_state,
has.failure_state_desc AS failure_state,
has.error_code,
has.performed_seeding,
has.start_time,
has.completion_time,
has.number_of_attempts
FROM sys.dm_hadr_automatic_seeding AS has
INNER JOIN sys.availability_groups AS ag
ON ag.group_id = has.ag_id
INNER JOIN sys.availability_replicas AS ar
ON ar.replica_id = has.ag_remote_replica_id
INNER JOIN sys.databases AS d
ON d.group_database_id = has.ag_db_id;
GO
