Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:SQL Server
Num grupo de disponibilidade Always On, pode configurar uma ou mais réplicas de disponibilidade para permitir conexões apenas de leitura ao serem executadas como réplicas secundárias (ou seja, quando estão sob o papel secundário). Também pode configurar cada réplica de disponibilidade para permitir ou excluir ligações apenas de leitura quando está a funcionar sob a função principal (ou seja, quando funciona como réplica primária).
Para facilitar o acesso do cliente às bases de dados primárias ou secundárias de um dado grupo de disponibilidade, deve definir um ouvinte de grupo de disponibilidade. Por padrão, o listener do grupo de disponibilidade direciona as ligações recebidas para a réplica primária. No entanto, pode configurar um grupo de disponibilidade para suportar o encaminhamento apenas de leitura, o que permite ao listener do grupo de disponibilidade redirecionar as solicitações de conexão das aplicações com intenção de leitura para uma réplica secundária legível. Para mais informações, consulte Configuração de Roteamento Apenas para Leitura para um Grupo de Disponibilidade (SQL Server).
Durante um failover, uma réplica secundária transita para a função primária e a réplica primária anterior transita para a função secundária. Durante o processo de failover, todas as ligações do cliente tanto à réplica primária como às réplicas secundárias são terminadas. Após o failover, quando um cliente se reconecta ao listener do grupo de disponibilidade, o listener reconecta o cliente à nova réplica primária, exceto para um pedido de conexão com intenção de leitura. Se o encaminhamento apenas de leitura estiver configurado no cliente e nas instâncias do servidor que alojam a nova réplica primária e em pelo menos uma réplica secundária legível, os pedidos de ligação de intenção de leitura são redirecionados para uma réplica secundária que suporta o tipo de acesso à ligação que o cliente necessita. Para garantir uma experiência de cliente eficiente após um failover, é importante configurar o acesso à ligação tanto para os papéis secundários como primários de cada réplica de disponibilidade.
Observação
Para informações sobre o ouvinte do grupo de disponibilidade, que gere pedidos de ligação dos clientes, consulte Ouvintes do Grupo de Disponibilidade, Conectividade do Cliente e Failover de Aplicações (SQL Server).
Tipos de acesso à ligação suportados pelo papel secundário
O papel secundário suporta três alternativas para ligações ao cliente, conforme segue:
Sem ligações
Não são permitidas ligações de utilizadores. Os bancos de dados secundários não estão disponíveis para acesso de leitura. Este é o comportamento padrão na função secundária.
Apenas ligações com intenção de leitura
A(s) base de dados secundária(s) estão disponíveis apenas para ligações em que a propriedade de ligação Application Intent esteja definida como ReadOnly (ligações de intenção de leitura).
Para informações sobre esta propriedade de ligação, consulte Suporte Nativo de Cliente SQL Server para Alta Disponibilidade, Recuperação em Desastres.
Permitir qualquer ligação de só leitura
A(s) base de dados secundária(s) estão todas disponíveis para acesso de leitura. Esta opção permite que clientes com versões inferiores se liguem.
Para obter mais informações, consulte Configurar o acesso Read-Only em uma réplica de disponibilidade (SQL Server).
Tipos de acesso à conexão suportados pela função principal
A função principal oferece suporte a duas alternativas para conexões de cliente, conforme segue:
Todas as ligações são permitidas
Tanto ligações de leitura-escrita como de leitura somente são permitidas para bases de dados primárias. Este é o comportamento padrão para a função principal.
Permitir apenas ligações de leitura e escrita
Quando a propriedade de ligação Application Intent está definida para ReadWrite ou não está definida, a ligação é permitida. Ligações para as quais a palavra-chave string de ligação Application Intent está definida como ReadOnly não são permitidas. Permitir apenas uma ligação de leitura-escrita pode ajudar a evitar que os seus clientes liguem uma carga de trabalho com intenção de leitura à réplica principal por engano.
Para obter informações sobre esta propriedade de ligação, consulte Utilização de Palavras-chave de String de Ligação com Cliente Nativo do SQL Server.
Para obter mais informações, consulte Configurar o acesso Read-Only em uma réplica de disponibilidade (SQL Server).
Como a Configuração do Acesso à Ligação Afeta a Conectividade do Cliente
As definições de acesso à ligação de uma réplica determinam se uma tentativa de ligação falha ou tem sucesso. A tabela seguinte resume se uma dada tentativa de ligação tem sucesso ou falha para cada configuração de acesso à ligação.
| Função de réplica | Acesso à Conexão Suportado na Replica | Intenção de Ligação | Resultado da Tentativa de Conexão |
|---|---|---|---|
| Secundária | Todos | Intenção de leitura, leitura-escrita ou sem intenção de ligação especificada | Sucesso |
| Secundária | Nenhum (Este é o comportamento secundário padrão.) | Intenção de leitura, leitura-escrita ou sem intenção de ligação especificada | Failure |
| Secundária | Apenas para leitura | Intenção de leitura | Sucesso |
| Secundária | Permissão apenas para leitura | Leitura-escrita ou sem intenção de ligação especificada | Failure |
| Primary | Todos (Este é o comportamento primário padrão.) | Apenas leitura, leitura-escrita ou sem intenção de ligação especificada | Sucesso |
| Primary | Leitura/escrita | Apenas para leitura | Failure |
| Primary | Leitura/escrita | Leitura-escrita ou sem intenção de conexão especificada | Sucesso |
Para informações sobre como configurar um grupo de disponibilidade para aceitar conexões de clientes às suas réplicas, consulte Ouvintes de Grupo de Disponibilidade, Conectividade do Cliente e Failover de Aplicações (SQL Server).
Exemplo de Configuração de Ligação-Acesso
Dependendo de como as diferentes réplicas de disponibilidade estão configuradas para o acesso à ligação, o suporte para ligações dos clientes pode mudar após o failover de um grupo de disponibilidade. Por exemplo, considere um grupo de disponibilidade em que se realizam relatórios em réplicas secundárias de commit assíncrono remoto. Todas as aplicações de apenas leitura para as bases de dados deste grupo de disponibilidade têm a sua propriedade de ligação Application Intent configurada para ReadOnly, de modo que todas as ligações de apenas leitura sejam ligações com intenção de leitura.
Este grupo de disponibilidade de exemplo possui duas réplicas de commit síncrono no centro de computação principal e duas réplicas de commit assíncrono num sítio satélite. Para a função primária, todas as réplicas estão configuradas para acesso de leitura e escrita, o que impede quaisquer ligações prévios à réplica primária em todas as situações. A função secundária de commit síncrono utiliza a configuração padrão de acesso à ligação ("nenhum"), que impede todas as ligações do cliente sob a função secundária. Em contraste, as réplicas de commit assíncronas estão configuradas para permitir ligações com intenção de leitura sob a função secundária. A tabela seguinte resume esta configuração de exemplo:
| Replica | Modo de confirmação | Papel inicial | Acesso de Conexão para Função Secundária | Acesso à Ligação para Função Primária |
|---|---|---|---|---|
| Réplica1 | Synchronous | Primary | Nenhum | Leitura/escrita |
| Replica2 | Synchronous | Secundária | Nenhum | Leitura/escrita |
| Replica3 | Asynchronous | Secundária | Somente para leitura | Leitura/escrita |
| Réplica4 | Asynchronous | Secundária | Apenas intenção de leitura | Leitura/escrita |
Normalmente, neste cenário de exemplo, os failovers ocorrem apenas entre as réplicas de synchronous-commit e, imediatamente após o failover, as aplicações com intenção de leitura conseguem reconectar-se a uma das réplicas secundárias de asynchronous-commit. No entanto, quando ocorre um desastre no centro de dados principal, ambas as réplicas de commit síncrono são perdidas. O administrador da base de dados no local do satélite responde realizando um failover manual forçado para uma réplica secundária de commit assíncrono. As bases de dados secundárias na réplica secundária remanescente são suspensas devido ao failover forçado, o que as torna indisponíveis para cargas de trabalho de leitura apenas. A nova réplica primária, configurada para ligações de leitura-escrita, impede que a carga de trabalho de intenção de leitura concorra com a carga de leitura-escrita. Isto significa que, até que o administrador das bases de dados retome as bases de dados secundárias na réplica secundária de commit assíncrono restante, os clientes com intenção de leitura não podem ligar-se a nenhuma réplica de disponibilidade.
Tarefas relacionadas
Configurar Read-Only Access numa réplica de disponibilidade (SQL Server)
Configurar o roteamento de Read-Only para um grupo de disponibilidade (SQL Server)
Exibir propriedades da réplica de disponibilidade (SQL Server)
Usar a caixa de diálogo Novo Grupo de Disponibilidade (SQL Server Management Studio)
Conteúdo relacionado
Ver também
Visão geral dos grupos de disponibilidade Always On (SQL Server)
Ouvintes de Grupos de Disponibilidade, Conectividade de Clientes e Failover de Aplicações (SQL Server)
Estatísticas