SQL Server Grupos de disponibilidade Always On: Guia completo [2026]

1. Compreendendo os Grupos de Disponibilidade Always On

1.1 O que é e como funciona

Os Grupos de Disponibilidade Always On (AG) são um SQL Server Empreendimento alta disponibilidade e uma solução de recuperação de desastres que opera no nível do banco de dados. Um grupo de disponibilidade agrupa um ou mais bancos de dados de usuário em uma única unidade de failover e os replica para até oito réplicas secundárias por meio do envio contínuo de logs de transações. Quando a réplica primária falha, uma réplica secundária síncrona designada assume automaticamente o controle, restaurando o acesso em segundos, sem armazenamento compartilhado ou intervenção manual.

1.2 Grupos de Disponibilidade Always On vs. Instâncias de Cluster de Failover

SQL Server O Always On inclui duas tecnologias distintas: Grupos de Disponibilidade (AG) e Instâncias de Cluster de Failover (FCI):

	Grupos de Disponibilidade Always On	Instâncias de cluster de failover sempre ativas
Escopo de failover	Nível de banco de dados	Nível de instância (todos os bancos de dados são submetidos a failover simultaneamente)
Replicação de dados	Replicação baseada em logs para cada secundário	Nenhum — todos os nós compartilham o mesmo armazenamento.
Armazenamento compartilhado	Não é necessária	Requisitos: (Rede de Área de Armazenamento (SAN), iSCSI, S2D ou SMB)
secundários legíveis	Sim	Não
A recuperação de desastres	Integrado (réplicas assíncronas entre sites)	Não vem integrado sem emparelhamento com o AG.

Quando usar cada um: Use FCI quando precisar de failover em nível de instância e já tiver infraestrutura de armazenamento compartilhada. Use AG quando precisar de granularidade em nível de banco de dados, réplicas secundárias legíveis ou recuperação de desastres. Para a proteção mais completa, combine ambos: execute cada réplica como um nó FCI e vincule-as em um AG.

1.3 Benefícios e Limitações

Benefícios:

• Failover automático com objetivo de tempo de recuperação (RTO) próximo de zero para réplicas síncronas;
• perda de dados zero (Objetivo de Ponto de Recuperação (RPO) = 0) no modo de confirmação síncrona;
• Não é necessário armazenamento compartilhado — cada réplica usa armazenamento local independente;
• Os servidores secundários legíveis descarregam as cargas de trabalho de relatório e backup do servidor primário;
• Suporta alta disponibilidade (HA) local e recuperação de desastres (DR) entre locais diferentes em uma única configuração.

Limitações:

• Requer Clustering de Failover do Windows Server em todas as réplicas;
• A Edição Enterprise oferece o conjunto completo de recursos (a Edição Standard suporta o AG Básico com restrições significativas);
• O modo de confirmação síncrona adiciona latência às operações de gravação, proporcional ao tempo de ida e volta da rede;
• Logins, trabalhos do SQL Agent e servidores vinculados não são sincronizados automaticamente em SQL Server 2019 e anos anteriores (resolvido em SQL Server 2022 continha grupos de disponibilidade).

2. Arquitetura de Grupos de Disponibilidade Sempre Ativos

2.1 Componentes e conceitos principais

2.1.1 Bancos de Dados de Disponibilidade

Bancos de dados de disponibilidade são os bancos de dados de usuário que participam de um grupo de disponibilidade. Esses bancos de dados devem atender a requisitos específicos: devem usar o modelo de recuperação completa, ter um backup completo e existir na réplica primária antes de serem adicionados a um grupo de disponibilidade.

Quando um banco de dados entra em um grupo de disponibilidade, ele passa a fazer parte de um conjunto sincronizado que realiza failover como uma unidade. Todos os bancos de dados em um grupo de disponibilidade compartilham o mesmo estado de failover, o que significa que, se a réplica primária falhar, todos os bancos de dados farão failover para a mesma réplica secundária simultaneamente. Isso garante a consistência para aplicativos que dependem de vários bancos de dados relacionados.

2.1.2 Disponibilidade de Réplicas

As réplicas de disponibilidade são SQL Server Instâncias que hospedam cópias de bancos de dados de disponibilidade. Cada réplica mantém sua própria cópia física dos bancos de dados, sincronizadas por meio do envio de registros de log de transações. Um grupo de disponibilidade pode conter até nove réplicas: uma réplica primária e até oito réplicas secundárias.

2.1.3 Réplica Primária

A réplica primária hospeda a cópia de leitura e gravação dos bancos de dados de disponibilidade. Todas as modificações de dados (INSERIR, ATUALIZAR, EXCLUIR) ocorrem na réplica primária. Os aplicativos cliente se conectam à réplica primária para todas as operações de gravação e, por padrão, também para operações de leitura.

2.1.4 Réplicas Secundárias

As réplicas secundárias hospedam cópias somente leitura dos bancos de dados de disponibilidade, mantidas por meio da aplicação contínua de registros de log de transações recebidos da réplica primária. Cada réplica secundária recebe, protege e aplica os registros de log para manter suas cópias do banco de dados sincronizadas com a primária.

2.2 Modos de disponibilidade

2.2.1 Modo de Confirmação Síncrona

O modo de confirmação síncrona oferece proteção contra perda de dados, exigindo que a réplica primária aguarde a confirmação de que os registros de log de transações foram protegidos na réplica secundária antes de confirmar as transações. Esse modo é essencial para configurações de alta disponibilidade, onde a perda de dados é inaceitável.

2.2.2 Modo de confirmação assíncrona

O modo de confirmação assíncrona prioriza o desempenho da réplica primária, permitindo que as transações sejam confirmadas sem esperar que as réplicas secundárias confirmem o reforço de logs. Esse modo é apropriado para réplicas de recuperação de desastres ou quando a latência da rede torna a confirmação síncrona impraticável.

A desvantagem é a potencial perda de dados durante a recuperação de falhas. Se a réplica primária falhar, algumas transações confirmadas podem não ter chegado à réplica secundária. A quantidade de perda potencial de dados depende da largura de banda da rede, do desempenho da réplica secundária e do momento da falha. As organizações devem aceitar esse risco ao usar o modo assíncrono.

2.3 Tipos de Failover

2.3.1 Failover automático

O failover automático permite que o grupo de disponibilidade detecte falhas na réplica primária e promova automaticamente uma réplica secundária a primária, sem intervenção do administrador. Essa funcionalidade minimiza o RTO (Objetivo de Tempo de Recuperação) ao eliminar a necessidade de resposta manual a falhas.

O failover automático requer o modo de confirmação síncrona para garantir zero perda de dados. Quando ativado, o grupo de disponibilidade monitora continuamente a integridade da réplica primária. Se a réplica primária parar de responder ou falhar, o Cluster de Failover do Windows Server inicia o failover automático para uma réplica secundária designada.

2.3.2 Failover Manual

O failover manual permite que os administradores alternem intencionalmente a função da réplica primária para uma réplica secundária, geralmente para fins de manutenção planejada ou testes. Ao contrário do failover automático, o failover manual requer ação explícita do administrador para ser iniciado.

O failover manual sem perda de dados está disponível para réplicas com commit síncrono. O administrador inicia o failover através de SQL Server Management Studio, Transact-SQL ou PowerShell. A réplica primária termina de processar as transações atuais, envia todos os registros de log restantes para a réplica secundária de destino e aguarda a confirmação antes de transferir a função de primária.

O failover manual também pode ocorrer com réplicas de confirmação assíncrona, mas isso requer um failover forçado com potencial perda de dados. Os administradores devem usar o failover manual forçado somente em cenários reais de desastre, quando a réplica primária estiver indisponível e a perda de dados for aceitável em comparação com um tempo de inatividade prolongado.

2.3.3 Failover Forçado

O failover forçado permite a transição para uma réplica secundária assíncrona ou para uma réplica secundária que não esteja totalmente sincronizada, com o reconhecimento explícito da potencial perda de dados. Essa opção serve como último recurso quando a réplica primária está indisponível e não existe uma réplica secundária sincronizada.

2.4 Sincronização de Dados

2.4.1 Como funciona a sincronização de dados

A sincronização de dados em Grupos de Disponibilidade Always On ocorre por meio do envio contínuo de registros de log de transações da réplica primária para todas as réplicas secundárias. Essa sincronização baseada em logs garante a consistência, permitindo, ao mesmo tempo, o armazenamento independente para cada réplica.

2.4.2 Registros de Log de Transações e Reforço de Segurança

O fortalecimento do log de transações é a etapa crítica em que os registros de log são gravados em armazenamento durável em réplicas secundárias. O fortalecimento garante que os registros de log sobrevivam a falhas de réplicas secundárias e possam ser reproduzidos durante a recuperação.

2.5 Escala de leitura e réplicas secundárias legíveis

2.5.1 Descarregamento de cargas de trabalho somente leitura

Réplicas secundárias legíveis permitem que as organizações descarreguem cargas de trabalho com uso intensivo de leitura da réplica primária, melhorando o desempenho geral do sistema e a utilização de recursos. Essa capacidade de escalabilidade de leitura é uma das principais vantagens dos grupos de disponibilidade em relação às soluções de alta disponibilidade mais antigas.

Ao projetar configurações de grupos de disponibilidade, as organizações devem considerar os requisitos de carga de trabalho somente leitura. Vários servidores secundários com permissão de leitura podem distribuir a carga de relatórios entre diversos servidores. Listas de roteamento somente leitura definem a ordem em que os servidores secundários recebem conexões com intenção de leitura, possibilitando estratégias de balanceamento de carga.

2.5.2 Operações de backup em réplicas secundárias

Executar backups em réplicas secundárias reduz a carga de entrada/saída (E/S) e da Unidade Central de Processamento (CPU) na réplica primária, permitindo que ela se concentre em cargas de trabalho transacionais. Essa capacidade ajuda as organizações a atender aos requisitos de backup sem afetar o desempenho da produção.

SQL Server Suporta backups completos do banco de dados, backups diferenciais e backups de logs de transações em réplicas secundárias. As preferências de backup podem ser configuradas para priorizar réplicas secundárias, priorizar a réplica primária, somente as secundárias ou qualquer réplica. O sistema de backup seleciona automaticamente a réplica apropriada com base nessas preferências e na disponibilidade atual.

Para mais detalhes sobre SQL Server Para fazer backup, consulte nosso guia completo.

2.6 Ouvintes de Grupo de Disponibilidade

2.6.1 O que é um ouvinte?

Um listener de grupo de disponibilidade é um nome de rede virtual (VNN) e um endereço IP que os aplicativos cliente usam para se conectar aos bancos de dados do grupo de disponibilidade. O listener redireciona automaticamente as conexões para a réplica primária atual, eliminando a necessidade de os aplicativos rastrearem qual servidor é o primário no momento.

2.6.2 Roteamento de Conexão do Cliente

O roteamento de conexões do cliente por meio do listener suporta intenções de conexão de leitura e gravação, bem como intenções somente leitura. O listener examina a solicitação de conexão e a encaminha para a réplica apropriada com base na intenção do aplicativo.

3. Pré-requisitos e Requisitos

3.1 Clustering de Failover do Windows Server para Grupos de Disponibilidade

3.1.1 Fundamentos de Clustering de Failover do Windows Server

O Clustering de Failover do Windows Server (WSFC) fornece a base para os Grupos de Disponibilidade Always On, gerenciando a associação ao cluster, o monitoramento de integridade e a orquestração de failover. Ao contrário das Instâncias de Cluster de Failover, os grupos de disponibilidade usam o WSFC apenas para coordenação do cluster, não para gerenciamento de armazenamento compartilhado.

Cada SQL Server Uma instância que participa de um grupo de disponibilidade deve ser um nó em um cluster WSFC. O cluster gerencia a votação de quorum, a detecção de integridade do nó e o estado dos recursos do grupo de disponibilidade. Quando a réplica primária falha, o WSFC coordena o processo de failover e atualiza os recursos do cluster para refletir a nova réplica primária.

3.1.2 Configuração de Quórum do Cluster

O quórum do cluster determina quais nós podem operar quando ocorrem problemas de conectividade de rede, evitando cenários de "cérebro dividido" onde vários nós reivindicam independentemente a função primária. A configuração do quórum define o que constitui um voto majoritário para as decisões do cluster.

Vários modos de quorum estão disponíveis para grupos de disponibilidade:

• O Node Majority utiliza apenas os votos dos nós do cluster e funciona bem para clusters com um número ímpar de nós.
• A funcionalidade "Node and File Share Majority" adiciona uma votação de testemunha de compartilhamento de arquivos, adequada para clusters com número par de nós.
• A abordagem Node and Disk Majority utiliza um disco como testemunha, mas é menos comum em grupos de disponibilidade, já que o armazenamento compartilhado não é necessário.

3.1.3 Agrupamento de múltiplas sub-redes

O agrupamento em múltiplas sub-redes permite que as réplicas do grupo de disponibilidade abranjam diferentes sub-redes de rede, suportando implantações geograficamente distribuídas em vários centros de dados. Essa capacidade é essencial para configurações de recuperação de desastres em que as réplicas existem em locais separados.

3.2 SQL Server Requisitos de edição

3.2.1 Recursos da Edição Empresarial

SQL Server A Enterprise Edition oferece funcionalidade completa de grupos de disponibilidade sem limitações. A Enterprise Edition suporta até oito réplicas secundárias, secundárias legíveis, seeding automático, grupos de disponibilidade distribuídos e todos os recursos avançados.

3.2.2 Recursos da Edição Padrão (Grupos Básicos de Disponibilidade)

SQL Server A edição Standard de 2016 e posteriores oferecem suporte a Grupos de Disponibilidade Básicos, porém com limitações significativas. Os Grupos de Disponibilidade Básicos fornecem funcionalidades essenciais de alta disponibilidade a um custo menor, sendo adequados para organizações com requisitos mais simples.

4. Configurando Grupos de Disponibilidade Always On

4.1 Preparando o Ambiente

Antes de criar um grupo de disponibilidade, o ambiente deve ser devidamente preparado com contas do Active Directory, configurações de servidor e infraestrutura de rede implementadas.

4.1.1 Configuração do Controlador de Domínio

O controlador de domínio do Active Directory deve ser configurado para suportar o cluster do grupo de disponibilidade e SQL Server contas de serviço.

1. Faça login no controlador de domínio com as credenciais de administrador de domínio.
2. Abra server Manager e navegue até Ferramentas -> Usuários e computadores do Active Directory.
3. Criar uma unidade organizacional para SQL Server objetos se nenhum existir.
4. Verifique se os objetos de computador para todos os nós do cluster existem no Active Directory.
5. Certifique-se de que os serviços do Sistema de Nomes de Domínio (DNS) estejam configurados corretamente e que todos os nomes de servidor sejam resolvidos corretamente.

4.1.2 Criação de contas de serviço

Crie contas de serviço do Active Directory dedicadas para SQL Server serviços em cada nó.

1. Abra Usuários e computadores do Active Directory no controlador de domínio.
2. Clique com o botão direito do mouse na unidade organizacional apropriada e selecione New -> Utilizador.
3. Insira o nome da conta de serviço (por exemplo, svc_SQLServer) e defina o Nome de login do usuário.
4. Clique Seguinte e digite uma senha forte.
5. Selecionar O usuário não pode alterar a senha. e A senha nunca expira.
6. Clique Seguinte e depois Acabamento para criar a conta.
7. Repita o processo para quaisquer contas de serviço adicionais necessárias (SQL Server Agente, SSRS, etc.).

4.1.3 Configurando permissões de administrador

Contas de serviço e contas usadas para configurar SQL Server Deve possuir as permissões adequadas em todos os nós do cluster.

1. Faça login em cada servidor de nó do cluster.
2. Abra Gerenciamento do computador do Começar menu ou Gerenciador de Servidor.
3. Expandir Usuários e Grupos Locais e selecione Grupos.
4. Botão direito do mouse Administradores e selecione Propriedades.
5. Clique Adicione e insira o nome da conta de serviço.
6. Clique Verificar Nomes Para validar a conta, clique em OK.
7. Clique OK Para fechar a caixa de diálogo Propriedades do Administrador.
8. Repita o processo em todos os nós do cluster.

4.2 Instalação e configuração do WSFC

O Clustering de Failover do Windows Server deve ser instalado e configurado em todos os nós antes de habilitar os Grupos de Disponibilidade Always On.

4.2.1 Instalando o recurso de cluster de failover

Instale o recurso de Clustering de Failover em cada servidor que participará do grupo de disponibilidade.

1. Abra server Manager no primeiro nó do cluster.
2. Clique Gerenciar -> Adicionar funções e recursos.
3. Clique Seguinte através das telas de introdução.
4. Selecionar Instalação baseada em funções ou recursos e clique Seguinte.
5. Selecione o servidor local e clique em Seguinte.
6. Ignore a tela de Funções e clique em Seguinte.
7. Na tela Recursos, selecione Clustering de Failover.
8. Clique Adicionar recursos quando solicitado a incluir ferramentas de gestão.
9. Clique Seguinte e depois Instale.
10. Aguarde a conclusão da instalação e clique em Fechar.
11. Repita o procedimento em todos os servidores que participarão do cluster.

4.2.2 Criando o Cluster de Failover

Após instalar o recurso de Clustering de Failover em todos os nós, crie o cluster a partir de um dos nós.

1. Abra Gerenciador de Cluster de Failover da server Manager -> Ferramentas.
2. Clique Criar cluster no painel Ações.
3. Clique Seguinte na página Antes de Começar.
4. Clique Explorar e adicione todos os servidores que serão nós do cluster.
5. Clique Seguinte após adicionar todos os nós.
6. Deixar Executar todos os testes (recomendado) selecionado e clique Seguinte.
7. Analise os resultados dos testes de validação e corrija quaisquer erros ou avisos.
8. Clique Acabamento após a validação ser concluída com sucesso.
9. Insira um nome para o cluster e o endereço IP.
10. Desmarcar Adicione todo o armazenamento elegível ao cluster. já que o armazenamento compartilhado não é necessário.
11. Clique Seguinte e revise a confirmação.
12. Clique Acabamento para criar o cluster.

4.2.3 Validação da Configuração do Cluster

Valide a configuração do cluster para garantir que todos os nós possam se comunicar corretamente e que o cluster esteja funcionando adequadamente.

1. In Gerenciador de Cluster de Failover, clique com o botão direito do mouse no nome do cluster.
2. Selecionar Validar Cluster a partir do menu.
3. Clique Seguinte na página Antes de Começar.
4. Selecionar Executar todos os testes (recomendado) e clique Seguinte.
5. Clique Seguinte Para iniciar os testes de validação.
6. Analise o relatório de validação quando os testes forem concluídos.
7. Corrija quaisquer falhas ou avisos identificados no relatório.
8. Clique Acabamento Para fechar o assistente.

NUNCA instalando SQL Server para Grupos de Disponibilidade

Instale SQL Server em cada nó que participará do grupo de disponibilidade usando a opção de instalação independente.

1. execute o SQL Server Mídia de instalação no primeiro nó.
2. Selecionar New SQL Server instalação independente.
3. Insira a chave do produto ou selecione a versão de avaliação.
4. Aceite os termos de licença e clique em Seguinte.
5. Conclua as verificações de pré-requisitos e resolva quaisquer problemas.
6. Na página Seleção de Recursos, selecione Serviços do mecanismo de banco de dados.
7. Configure o nome da instância (use o mesmo nome de instância em todos os nós).
8. Na página de Configuração do Servidor, especifique as credenciais da conta de serviço.
9. Configure os tipos de inicialização de serviço como Automático.
10. Na página de Configuração do Mecanismo de Banco de Dados, selecione o modo de autenticação.
11. Adicionar contas de administrador.
12. Configure os diretórios de dados usando caminhos consistentes em todos os nós.
13. Conclua a instalação e verifique se ela foi bem-sucedida.
14. Repita a instalação em todos os outros nós do cluster com configurações idênticas.

4.4 Habilitando o recurso de Grupos de Disponibilidade Sempre Ativos

Depois de instalar SQL Server Em todos os nós, habilite o recurso Grupos de Disponibilidade Sempre Ativos em cada instância.

4.4.1 Habilitando via SQL Server Gerenciador de configuração

Uso SQL Server O Configuration Manager permite habilitar os Grupos de Disponibilidade Always On por meio da interface gráfica.

1. Abra SQL Server Gerenciador de configuração no primeiro nó.
2. Expandir SQL Server Serviços no painel esquerdo.
3. Clique com o botão direito do mouse no SQL Server instância e selecione Propriedades.
4. Clique na Alta disponibilidade AlwaysOn aba.
5. Verifique Ativar Grupos de Disponibilidade AlwaysOn.
6. Verifique se o nome do cluster de failover do Windows está correto.
7. Clique OK para salvar as mudanças.
8. Clique OK com o aviso de que o serviço precisa ser reiniciado.
9. Clique com o botão direito do mouse no SQL Server serviço e seleção Reiniciar.
10. Aguarde até que o serviço seja reiniciado com sucesso.
11. Repita o processo em todos os nós do cluster.

4.4.2 Habilitando via PowerShell

O PowerShell fornece um método baseado em script para habilitar Grupos de Disponibilidade Always On em vários nós.

1. Abra o PowerShell como administrador no primeiro nó.
2. Importe o SQL Server Módulo do PowerShell:

   Import-Module SQLPS -DisableNameChecking

3. Ativar Grupos de Disponibilidade Sempre Ativos:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. O serviço será reiniciado automaticamente ao usar o parâmetro Force.
5. Verifique se o recurso está ativado:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Repita o processo para cada nó do cluster, substituindo os nomes de servidor e instância apropriados.

4.4.3 Verificando se o recurso está ativado

Verifique se os Grupos de Disponibilidade Always On estão ativados em todas as instâncias antes de prosseguir com a configuração.

1. Conecte-se a cada um SQL Server instância usando SQL Server Estúdio de Gestão.
2. Abra uma nova janela de consulta e execute:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Verifique se o resultado é 1 (ativado).
4. Verifique se o SQL Server A instância aparece no Gerenciador de Cluster de Failover em funções do cluster.
5. Verifique se o ponto de extremidade do grupo de disponibilidade existe executando o seguinte comando:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Caso o ponto de extremidade não exista, ele será criado durante a criação do grupo de disponibilidade.

4.5 Preparando bancos de dados para grupos de disponibilidade

Os bancos de dados devem atender a requisitos específicos antes de poderem ser adicionados a um grupo de disponibilidade.

4.5.1 Requisitos do Modelo de Recuperação de Banco de Dados

Altere o modelo de recuperação do banco de dados para FULL na réplica primária antes de adicioná-la a um grupo de disponibilidade.

1. Conecte-se à réplica primária usando SQL Server Estúdio de Gestão.
2. Clique com o botão direito do mouse no banco de dados e selecione Propriedades.
3. Selecione os Opções Disputas de Comerciais.
4. Mudar Modelo de recuperação para completo.
5. Clique OK para salvar a mudança.
6. Alternativamente, utilize Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Realizando backups completos do banco de dados

Faça um backup completo do banco de dados para estabelecer a cadeia de backups necessária para os grupos de disponibilidade.

1. In SQL Server No Management Studio, clique com o botão direito do mouse no banco de dados.
2. Selecionar tarefas -> Back Up.
3. verificar Tipo de backup está definido para completo.
4. Selecione um destino de backup ou adicione um novo destino.
5. Clique OK para realizar o backup.
6. Alternativamente, utilize Transact-SQL:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Realizando backups do log de transações

Faça um backup do log de transações para garantir que a cadeia de logs seja estabelecida e minimizar o tempo de inicialização.

1. In SQL Server No Management Studio, clique com o botão direito do mouse no banco de dados.
2. Selecionar tarefas -> Back Up.
3. Mudar Tipo de backup para Log de transações.
4. Selecione um destino de backup.
5. Clique OK para realizar o backup.
6. Alternativamente, utilize Transact-SQL:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Criando o Grupo de Disponibilidade

Crie o grupo de disponibilidade usando um dos vários métodos disponíveis, dependendo de suas preferências e requisitos de automação.

4.6.1 Usando o Assistente de Novo Grupo de Disponibilidade

O Assistente de Novo Grupo de Disponibilidade fornece uma interface gráfica para a criação de grupos de disponibilidade.

1. In SQL Server No Management Studio, conecte-se à instância que hospedará a réplica primária.
2. Expandir Alta disponibilidade AlwaysOn no Explorador de Objetos.
3. Botão direito do mouse Grupos de disponibilidade e selecione Novo assistente de grupo de disponibilidade.
   
4. Clique Seguinte na página de Introdução.
5. Insira um nome para o grupo de disponibilidade e clique em Seguinte.
6. Na página Selecionar Bancos de Dados, selecione os bancos de dados que deseja incluir.
7. Verifique se os bancos de dados atendem a todos os pré-requisitos e clique em Seguinte.
8. Na página Especificar Réplicas, clique em Adicionar Réplica.
9. Conecte-se a cada instância de réplica secundária.
10. Configure as propriedades da réplica para cada instância (modo de disponibilidade, modo de failover).
11. Clique na Pontos finais Aba e revise a configuração do endpoint.
12. Clique na Preferências de backup Na guia, configure as prioridades de backup.
13. Clique na Ouvinte Selecione a guia e, opcionalmente, crie um ouvinte.
14. Clique Seguinte e selecione o método de sincronização de dados.
15. Analise os resultados da validação e resolva quaisquer problemas.
16. Clique Seguinte e revise o resumo.
17. Clique Acabamento Para criar o grupo de disponibilidade.
18. Acompanhe o progresso e verifique se a criação foi bem-sucedida.

4.6.2 Usando Transact-SQL

Crie grupos de disponibilidade usando Transact-SQL para implantações programáveis ​​e repetíveis.

1. Crie o grupo de disponibilidade na réplica primária:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Adicione a réplica secundária ao grupo de disponibilidade:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Ingressar no banco de dados secundário:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Usando o PowerShell

O PowerShell oferece recursos de script para criação e gerenciamento de grupos de disponibilidade.

1. Crie o objeto de grupo de disponibilidade:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Adicionar bancos de dados:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Configure as réplicas com as propriedades desejadas usando o cmdlet New-SqlAvailabilityReplica.
4. Una as réplicas secundárias usando o cmdlet Join-SqlAvailabilityGroup.

4.7 Adicionando réplicas ao grupo de disponibilidade

Configure propriedades específicas da réplica que controlam como cada instância participa do grupo de disponibilidade.

4.7.1 Configurando as propriedades da réplica

Defina as propriedades de cada réplica para definir sua função e capacidades dentro do grupo de disponibilidade.

1. In SQL Server Estúdio de Gestão, expandir Alta disponibilidade AlwaysOn -> Grupos de disponibilidade.
2. Expanda o grupo de disponibilidade e, em seguida, expanda Réplicas disponíveis.
   
3. Clique com o botão direito do mouse em uma réplica e selecione Propriedades.
4. Analise e modifique as configurações de conexão para as funções primária e secundária.
5. Configure os valores de tempo limite da sessão, se necessário.
6. Clique OK para salvar as alterações.

4.7.2 Configuração dos Modos de Disponibilidade

Configure o modo de disponibilidade para controlar o comportamento de sincronização entre as réplicas.

1. Clique com o botão direito do mouse no grupo de disponibilidade e selecione Propriedades.
2. De acordo com o relatório Geral página, vá para Réplicas disponíveis seção.
3. Para cada réplica, selecione Confirmação síncrona or Confirmação assíncrona da lista suspensa.
4. Use o commit síncrono para réplicas locais de alta disponibilidade.
5. Utilize o commit assíncrono para réplicas de recuperação de desastres geograficamente distantes.
6. Clique OK para salvar a configuração.

4.7.3 Configurando os modos de failover

Configure o modo de failover para controlar como o failover ocorre para cada réplica.

1. Clique com o botão direito do mouse no grupo de disponibilidade e selecione Propriedades.
2. De acordo com o relatório Geral página, vá para Réplicas disponíveis seção.
3. Para réplicas de commit síncronas, selecione Automático or manual Modo de failover.
4. O failover automático requer o modo de confirmação síncrona e permite o failover sem intervenção humana.
5. Para réplicas de commit assíncronas, somente o failover manual está disponível.
6. Configure até três réplicas para failover automático (uma primária e duas secundárias).
7. Clique OK para aplicar as configurações.

4.7.4 Configurando as preferências de backup

Defina as preferências de backup para controlar onde as operações de backup devem ocorrer.

1. Clique com o botão direito do mouse no grupo de disponibilidade e selecione Propriedades.
2. Selecionar Preferências de backup no painel esquerdo.
3. Escolha uma das opções de backup:
   • Preferencialmente secundárioCópias de segurança no servidor secundário, se disponível; caso contrário, no servidor primário.
   • Somente secundárioCópias de segurança apenas em réplicas secundárias
   • Primário: Backups apenas na réplica primária
   • Qualquer réplicaCópias de segurança em qualquer réplica disponível
4. Defina os valores de prioridade de backup para cada réplica (0-100).
5. Valores de prioridade mais altos indicam destinos de backup preferenciais.
6. Clique OK Para salvar as preferências.

4.8 Configurando o Listener do Grupo de Disponibilidade

Crie um ouvinte para fornecer um ponto de conexão único que redirecione automaticamente para a réplica primária atual.

4.8.1 Criando o Ouvinte

Adicione um ouvinte ao grupo de disponibilidade para gerenciamento de conexões de clientes.

1. In SQL Server Management Studio, expanda o grupo de disponibilidade.
2. Botão direito do mouse Ouvintes do Grupo de Disponibilidade e selecione Adicionar Ouvinte.
   
3. Insira um nome DNS para o ouvinte (por exemplo, AG_Listener).
4. Digite o número da porta (o padrão é 1433).
5. Selecionar IP estático para o modo de rede.
6. Clique Adicione Adicionar um endereço IP para cada sub-rede.
7. Insira o endereço IP e selecione a sub-rede.
8. Clique OK para criar o ouvinte.
9. Verifique se o ouvinte aparece no Explorador de Objetos e se está online.

4.8.2 Configurando as definições de DNS e IP

Verifique o registro DNS e a configuração de rede do servidor de escuta.

1. Abra o Gerenciador de DNS no controlador de domínio.
2. Verifique se o nome do ouvinte foi registrado com todos os endereços IP.
3. Testar a resolução de DNS a partir de máquinas cliente:

   nslookup ListenerName

4. Verifique se todos os endereços IP configurados foram retornados.
5. No Gerenciador de Cluster de Failover, expanda Setores e selecione o grupo de disponibilidade.
6. Verifique se os recursos de endereço IP estão online.
7. Verifique se o recurso de nome de rede está online.
   

4.8.3 Testando a conectividade do ouvinte

Verifique se os aplicativos cliente conseguem se conectar através do listener.

1. A partir de um computador cliente, abra SQL Server Estúdio de Gestão.
2. Conecte-se usando o nome do ouvinte em vez do nome do servidor.
3. Execute uma consulta para verificar a conexão com a réplica primária atual:

   SELECT @@SERVERNAME;

4. Teste o roteamento de intenção de leitura adicionando ApplicationIntent=ReadOnly à string de conexão.
5. A verificação de redirecionamento de conexão aponta para uma réplica secundária legível.
6. Teste o failover realizando uma falha manual no grupo de disponibilidade e verificando a reconexão.

4.9 Métodos de Sincronização de Dados

Escolha um método de sincronização de dados para inicializar as réplicas secundárias com cópias do banco de dados.

4.9.1 Semeadura automática

A inicialização automática transfere dados do banco de dados pela rede sem a necessidade de backups e restaurações manuais.

1. Durante a criação do grupo de disponibilidade, selecione Semeadura automática como método de sincronização.
   
2. Garantir a conectividade de rede e largura de banda suficiente entre as réplicas.
3. A réplica primária transmite automaticamente os dados do banco de dados para as réplicas secundárias.
4. Acompanhe o progresso do seeding usando o painel de controle do grupo de disponibilidade ou os DMVs.
5. A semeadura automática requer SQL Server 2016 ou posterior.
6. Para grandes bases de dados, considere o impacto na rede e agende as operações durante períodos de baixa utilização.

4.9.2 Semeadura manual (backup e restauração)

O processo de seeding manual envolve a criação de backups no servidor primário e a restauração desses backups nas réplicas secundárias.

1. Na réplica principal, faça um backup completo:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Faça um backup do registro de transações:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Em cada réplica secundária, restaure o backup completo:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Restaurar o backup do registro de eventos:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Adicione o banco de dados ao grupo de disponibilidade:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Verifique se a sincronização começou e se o banco de dados atingiu o estado SINCRONIZADO.

4.9.3 Arquivos de instantâneo do banco de dados

Utilize arquivos de instantâneo do banco de dados para inicializar réplicas secundárias a partir de arquivos de banco de dados existentes.

1. Desanexe ou faça backup do banco de dados na réplica primária.
2. Copie os arquivos do banco de dados para cada réplica secundária usando os mesmos caminhos de arquivo.
3. Em réplicas secundárias, anexe o banco de dados ou restaure sem recuperação.
4. Certifique-se de que o banco de dados esteja no estado RESTORING (restaurando).
5. Adicione o banco de dados ao grupo de disponibilidade.
6. Este método é útil para bases de dados muito grandes, onde a transferência pela rede seria impraticável.

5. FAQ

5.1 Perguntas Gerais

P: Qual a diferença entre Always On FCI e Always On AG?

A: As instâncias de cluster Always On Failover oferecem alta disponibilidade em nível de instância usando armazenamento compartilhado, enquanto os Grupos de Disponibilidade Always On oferecem alta disponibilidade em nível de banco de dados sem armazenamento compartilhado. Os Grupos de Disponibilidade oferecem instâncias secundárias legíveis e distribuição geográfica mais flexível.

P: Posso usar Grupos de Disponibilidade Always On com SQL Server Edição padrão?

Um: sim, SQL Server A edição Standard de 2016 e versões posteriores oferecem suporte a Grupos de Disponibilidade Básicos, com limitações como um banco de dados por Grupo de Disponibilidade, no máximo duas réplicas e ausência de suporte para arquivos secundários legíveis.

P: Preciso de armazenamento compartilhado para Grupos de Disponibilidade Always On?

A: Não, os grupos de disponibilidade não exigem armazenamento compartilhado. Cada réplica mantém cópias independentes dos bancos de dados em armazenamento local, sincronizadas por meio do envio de logs de transação.

P: Qual é o número máximo de réplicas em um grupo de disponibilidade?

A: SQL Server A Enterprise Edition suporta até nove réplicas (uma primária e oito secundárias). Os grupos de disponibilidade distribuídos podem suportar até 18 réplicas no total, distribuídas em dois grupos de disponibilidade.

5.2 Perguntas de Configuração

P: Como faço para escolher entre os modos de confirmação síncrona e assíncrona?

A: Utilize o commit síncrono para requisitos de zero perda de dados dentro do mesmo data center ou em redes de baixa latência. Utilize o commit assíncrono para réplicas remotas de recuperação de desastres, onde o commit síncrono afetaria o desempenho.

P: Posso misturar réplicas síncronas e assíncronas no mesmo grupo de disponibilidade?

R: Sim, os grupos de disponibilidade suportam configurações mistas com réplicas síncronas e assíncronas. Isso permite alta disponibilidade local com réplicas síncronas e recuperação remota de desastres com réplicas assíncronas.

P: O que acontece com minhas conexões durante um failover?

A: As conexões existentes são encerradas quando ocorre um failover. Aplicativos com lógica de repetição de conexão se reconectam automaticamente ao novo servidor primário por meio do listener. O processo de failover normalmente é concluído em segundos ou minutos.

P: Preciso sincronizar logins e tarefas entre as réplicas?

R: Em SQL Server Sim, em versões de 2019 e anteriores – logins, trabalhos do SQL Agent e servidores vinculados devem ser sincronizados manualmente. SQL Server A versão 2022 introduz grupos de disponibilidade contidos que incluem automaticamente esses objetos.

5.3 Questões de Gestão

P: Posso executar backups em réplicas secundárias?

R: Sim, as réplicas secundárias suportam backups completos, diferenciais e de log de transações. Configure as preferências de backup para descarregar os backups da réplica primária e reduzir sua utilização de recursos.

P: Como faço para aplicar o patch? SQL Server Com tempo de inatividade mínimo?

A: Utilize atualizações contínuas, aplicando os patches primeiro nas réplicas secundárias, depois realizando um failover manual para uma réplica secundária já corrigida e, por fim, aplicando os patches na réplica primária anterior. Isso minimiza o tempo de inatividade ao tempo necessário para o failover.

P: Posso adicionar bancos de dados a um grupo de disponibilidade existente?

R: Sim, bancos de dados podem ser adicionados a grupos de disponibilidade em execução. O banco de dados deve estar no modelo de recuperação completa com um backup completo, e as réplicas secundárias devem ser inicializadas usando inicialização automática ou backup e restauração manual.

P: O que é semeadura automática e devo usá-la?

A: O seeding automático transfere dados do banco de dados pela rede para inicializar réplicas secundárias sem a necessidade de backups manuais. Use-o para bancos de dados menores ou quando a largura de banda da rede for suficiente. Para bancos de dados muito grandes, o seeding manual pode ser mais rápido.

P: Em qual grupo de disponibilidade devo executar o comando DBCC CHECKDB?

A: Você deve executar o comando DBCC CHECKDB nas réplicas secundárias para reduzir a carga na réplica primária. As verificações de consistência do banco de dados podem ser executadas nos bancos de dados secundários sem afetar o desempenho da réplica primária.

Para obter mais detalhes sobre o DBCC CHECKDB, consulte nosso guia completo.

5.4 Perguntas para solução de problemas

P: Por que meu banco de dados está no estado NÃO SINCRONIZANDO?

A: As causas comuns incluem problemas de conectividade de rede, suspensão da movimentação de dados, espaço insuficiente em disco nas réplicas secundárias ou problemas nos endpoints. Verifique a descrição da integridade da sincronização e SQL Server Para obter detalhes específicos, consulte os registros de erros. Se o banco de dados secundário tiver inserido um erro, estado de recuperação ou shows recuperação pendenteConsulte os guias vinculados para obter soluções específicas.

P: Como faço para forçar o failover quando o servidor primário estiver indisponível?

A: Conecte-se a uma réplica secundária e execute o comando ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Isso reconhece a possível perda de dados e promove a réplica secundária a primária imediatamente.

P: Por que os clientes não conseguem se conectar ao meu ouvinte?

A: Verifique se o servidor de escuta está online no Gerenciador de Cluster de Failover, se o registro de DNS foi bem-sucedido, se todos os IPs do servidor de escuta estão acessíveis aos clientes e se as regras do firewall permitem o tráfego para a porta do servidor de escuta.

P: O que significa uma fila de refazer grande?

A: Uma fila de refazer grande indica que a réplica secundária não consegue aplicar os registros de log tão rapidamente quanto eles chegam. Isso pode indicar gargalos de E/S de disco, limitações de CPU ou bloqueios causados ​​por consultas somente leitura na réplica secundária.

P: O que devo fazer se um desastre afetar todas as réplicas e meus backups também forem corrompidos?

A: Esse cenário catastrófico, embora extremamente raro, pode ocorrer devido a ataques de ransomware, falhas generalizadas de armazenamento ou desastres em cascata. Sua principal defesa é a prevenção: mantenha réplicas geograficamente distribuídas, armazene backups em locais separados e
Teste regularmente seus procedimentos de recuperação de desastres. Se todas as opções de recuperação padrão falharem, utilize um sistema especializado. Ferramenta de recuperação de dados SQL Pode-se tentar extrair dados de arquivos MDF danificados como medida de emergência ou último recurso.

5.5 Questões de licenciamento e custos

P: Como os Grupos de Disponibilidade Sempre Ativos são licenciados?

A: SQL Server O licenciamento depende da edição e do modelo de implantação. Os grupos de disponibilidade da Enterprise Edition exigem licenças Enterprise em todas as réplicas. Réplicas secundárias passivas podem ser elegíveis para licenciamento gratuito sob certas condições.

Q: Posso usar SQL Server Edição de desenvolvedor para grupos de disponibilidade?

R: Sim, a Developer Edition inclui todos os recursos da Enterprise Edition, incluindo suporte completo a grupos de disponibilidade. No entanto, ela é licenciada apenas para desenvolvimento e testes, não para uso em produção.

P: Arquivos secundários legíveis exigem licenças adicionais?

A: O licenciamento depende do cenário. Servidores secundários passivos para recuperação de desastres normalmente não exigem licenças. Servidores secundários ativos que atendem cargas de trabalho somente leitura geralmente exigem licenças, embora os termos específicos variem.

P: Existe alguma maneira gratuita de obter alta disponibilidade com SQL Server?

A: SQL Server A Express Edition não suporta grupos de disponibilidade. SQL Server A Edição Standard oferece suporte a Grupos de Disponibilidade Básicos a partir de SQL Server Em 2016, foi implementada uma oferta de alta disponibilidade básica com custos de licenciamento da Edição Padrão.

P: O que são Grupos de Disponibilidade Distribuídos?

A: Grupos de disponibilidade distribuídos são um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade separados, possibilitando cenários que excedem as capacidades dos grupos de disponibilidade tradicionais. Introduzido em SQL Server Em 2016, os grupos de disponibilidade distribuída abordaram os requisitos de escalabilidade e distribuição geográfica.

6. Conclusão

6.1 Resumo dos Pontos Chave

SQL Server Os Grupos de Disponibilidade Always On representam a principal solução de alta disponibilidade e recuperação de desastres da Microsoft para bancos de dados de missão crítica. Eles fornecem failover em nível de banco de dados sem a necessidade de armazenamento compartilhado, réplicas secundárias legíveis para descarregar cargas de trabalho e distribuição geográfica flexível para proteção abrangente de dados. Para organizações que ainda utilizam soluções como... transporte de toras or réplicaOs grupos de disponibilidade oferecem um caminho de atualização mais robusto e operacionalmente mais simples.

6.2 Quando usar Grupos de Disponibilidade Sempre Ativos

Escolha grupos de disponibilidade quando precisar de alta disponibilidade em nível de banco de dados com recursos de failover automático. Organizações que necessitam de proteção contra perda de dados para bancos de dados críticos se beneficiam de réplicas de commit síncronas com failover automático. Aplicativos que exigem recursos de escalabilidade de leitura utilizam réplicas secundárias legíveis para distribuir as cargas de trabalho de consulta.

6.3 Primeiros passos com a sua implementação

Inicie o planejamento do grupo de disponibilidade avaliando os requisitos de negócios, incluindo RTO, RPO e restrições orçamentárias. Documente a infraestrutura de banco de dados atual, as dependências de aplicativos e as lacunas de alta disponibilidade. Projete uma arquitetura de grupo de disponibilidade que atenda aos requisitos, respeitando as restrições de recursos.

Referências

• Documento oficial da Microsoft: O que é um grupo de disponibilidade Always On?
• Documento oficial da Microsoft: Primeiros passos com os Grupos de Disponibilidade Always On
• Documento oficial da Microsoft: grupos de disponibilidade distribuída

---

Sobre o autor

Yuan Sheng é um administrador de banco de dados sênior (DBA) com mais de 10 anos de experiência em SQL Server ambientes e gerenciamento de bancos de dados corporativos. Ele solucionou com sucesso centenas de cenários de recuperação de bancos de dados em organizações de serviços financeiros, saúde e manufatura.

Yuan é especialista em SQL Server recuperação de banco de dados, soluções de alta disponibilidade e otimização de desempenho. Sua vasta experiência prática inclui gerenciamento de bancos de dados multiterabytes, implementação de Grupos de Disponibilidade Always On e desenvolvimento de estratégias automatizadas de backup e recuperação para sistemas empresariais de missão crítica.

Por meio de sua experiência técnica e abordagem prática, Yuan se concentra na criação de guias abrangentes que ajudam administradores de banco de dados e profissionais de TI a resolver problemas complexos. SQL Server desafios de forma eficiente. Ele se mantém atualizado com as últimas SQL Server lançamentos e as tecnologias de banco de dados em evolução da Microsoft, testando regularmente cenários de recuperação para garantir que suas recomendações reflitam as melhores práticas do mundo real.

Tem dúvidas sobre SQL Server recuperação ou precisa de orientação adicional para solução de problemas de banco de dados? Yuan dá as boas-vindas comentários e sugestões para melhorar esses recursos técnicos.