CRIAR GRUPO DE DISPONIBILIDADE (Transact-SQL)

Aplica-se a:SQL Server

Cria um novo grupo de disponibilidade, se a instância do SQL Server estiver habilitada para o recurso Grupos de disponibilidade Always On.

Importante

Execute CREATE AVAILABILITY GROUP na instância do SQL Server que você pretende usar como a réplica primária inicial do seu novo grupo de disponibilidade. Essa instância do servidor deve residir em um nó WSFC (Cluster de Failover do Windows Server).

Transact-SQL convenções de sintaxe

Sintaxe

  
CREATE AVAILABILITY GROUP group_name  
   WITH (<with_option_spec> [ ,...n ] )  
   FOR [ DATABASE database_name [ ,...n ] ]  
   REPLICA ON <add_replica_spec> [ ,...n ]  
   AVAILABILITY GROUP ON <add_availability_group_spec> [ ,...2 ]  
   [ LISTENER 'dns_name' ( <listener_option> ) ]  
[ ; ]  
  
<with_option_spec>::=   
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }  
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 }   
  | HEALTH_CHECK_TIMEOUT = milliseconds  
  | DB_FAILOVER  = { ON | OFF }   
  | DTC_SUPPORT  = { PER_DB | NONE }  
  | [ BASIC | DISTRIBUTED | CONTAINED [ REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ] ]
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | CLUSTER_TYPE = { WSFC | EXTERNAL | NONE } 
  | WRITE_LEASE_VALIDITY = { seconds }
  | CLUSTER_CONNECTION_OPTIONS = 'key_value_pairs>[;...]`
  
<add_replica_spec>::=  
  <server_instance> WITH  
    (  
       ENDPOINT_URL = 'TCP://system-address:port',  
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY },  
       FAILOVER_MODE = { AUTOMATIC | MANUAL | EXTERNAL }  
       [ , <add_replica_option> [ ,...n ] ]  
    )   
  
  <add_replica_option>::=  
       SEEDING_MODE = { AUTOMATIC | MANUAL }  
     | BACKUP_PRIORITY = n  
     | SECONDARY_ROLE ( {   
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]   
        [,] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]  
     } )  
     | PRIMARY_ROLE ( {   
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]   
        [,] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | NONE } ]  
        [,] [ READ_WRITE_ROUTING_URL = 'TCP://system-address:port' ]
     } )  
     | SESSION_TIMEOUT = integer  
  
<add_availability_group_spec>::=  
 <ag_name> WITH  
    (  
       LISTENER_URL = 'TCP://system-address:port',  
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT },  
       FAILOVER_MODE = MANUAL,  
       SEEDING_MODE = { AUTOMATIC | MANUAL }  
    )  
  
<listener_option> ::=  
   {  
      WITH DHCP [ ON ( <network_subnet_option> ) ]  
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]  
   }  
  
  <network_subnet_option> ::=  
     'ip4_address', 'four_part_ipv4_mask'    
  
  <ip_address_option> ::=  
     {   
        'ip4_address', 'pv4_mask'  
      | 'ipv6_address'  
     }

Argumentos

group_name

Especifica o nome do novo grupo de disponibilidade. group_name deve ser um identificador dedo SQL Server válidoe deve ser exclusivo em todos os grupos de disponibilidade no cluster WSFC. O comprimento máximo para um nome de grupo de disponibilidade é de 128 caracteres para cluster_type = WSFC e 64 caracteres para cluster_type = NONE e EXTERNAL.

AUTOMATED_BACKUP_PREFERENCE = { PRIMÁRIO | SECONDARY_ONLY | SECUNDÁRIO | NENHUM }

Especifica uma preferência sobre como um trabalho de backup deve avaliar a réplica principal ao escolher onde executar backups. Você pode criar um script para uma determinada tarefa de backup para levar em conta a preferência de backup automatizado. É importante entender que a preferência não é imposta pelo SQL Server, portanto, não tem impacto nos backups ad hoc.

Os valores suportados são os seguintes:

PRIMÁRIO

Especifica que os backups devem sempre ocorrer na réplica primária. Essa opção é útil se você precisar de recursos de backup, como a criação de backups diferenciais, que não são suportados quando o backup é executado em uma réplica secundária.

Importante

Se você planeja usar o envio de logs para preparar bancos de dados secundários para um grupo de disponibilidade, defina a preferência de backup automatizado como primário até que todos os bancos de dados secundários tenham sido preparados e ingressados no grupo de disponibilidade.

SECONDARY_ONLY

Especifica que os backups nunca devem ser executados na réplica primária. Se a réplica primária for a única réplica online, o backup não deverá ocorrer.

SECUNDÁRIO

Especifica que os backups devem ocorrer em uma réplica secundária, exceto quando a réplica primária for a única réplica online. Nesse caso, o backup deve ocorrer na réplica primária. Este é o comportamento padrão.

NENHUM

Especifica que você prefere que os trabalhos de backup ignorem a função das réplicas de disponibilidade ao escolher a réplica para executar backups. Observação Os trabalhos de backup podem avaliar outros fatores, como a prioridade de backup de cada réplica de disponibilidade em combinação com seu estado operacional e estado conectado.

Importante

Não há aplicação da configuração de AUTOMATED_BACKUP_PREFERENCE. A interpretação dessa preferência depende da lógica, se houver, que você cria scripts em trabalhos de retorno para os bancos de dados em um determinado grupo de disponibilidade. A configuração de preferência de backup automatizado não tem impacto nos backups ad hoc. Para obter mais informações, consulte Configurar backup em réplicas de disponibilidade (SQL Server).

Observação

Para exibir a preferência de backup automatizado de um grupo de disponibilidade existente, selecione a coluna automated_backup_preference ou automated_backup_preference_desc da exibição de catálogo sys.availability_groups. Além disso, sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) pode ser usado para determinar a réplica de backup preferida. Essa função retorna 1 para pelo menos uma das réplicas, mesmo quando AUTOMATED_BACKUP_PREFERENCE = NONE.

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

Especifica quais condições de falha acionam um failover automático para esse grupo de disponibilidade. FAILURE_CONDITION_LEVEL é definido no nível do grupo, mas é relevante apenas em réplicas de disponibilidade configuradas para o modo de disponibilidade de confirmação síncrona (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Além disso, as condições de falha podem disparar um failover automático somente se as réplicas primária e secundária estiverem configuradas para o modo de failover automático (FAILOVER_MODE = AUTOMÁTICO) e se a réplica secundária estiver sincronizada com a réplica primária.

Os níveis de condição de falha (1-5) variam do menos restritivo, nível 1, ao mais restritivo, nível 5. Um determinado nível de condição engloba todos os níveis menos restritivos. Assim, o nível de condição mais rigoroso, 5, inclui os quatro níveis de condição menos restritivos (1-4), o nível 4 inclui os níveis 1-3, e assim por diante. A tabela a seguir descreve a condição de falha que corresponde a cada nível.

Nível	Condição de falha
1	Especifica que um failover automático deve ser iniciado quando ocorrer qualquer uma das seguintes situações: -O serviço do SQL Server está inativo. -A concessão do grupo de disponibilidade para conexão com o cluster WSFC expira porque nenhum ACK é recebido da instância do servidor. Para obter mais informações, consulte Como funciona: Tempo limite de concessão Always On do SQL Server.
2	Especifica que um failover automático deve ser iniciado quando ocorrer qualquer uma das seguintes situações: -A instância do SQL Server não se conecta ao cluster e o limite de HEALTH_CHECK_TIMEOUT especificado pelo usuário do grupo de disponibilidade é excedido. -A réplica de disponibilidade está em estado de falha.
3	Especifica que um failover automático deve ser iniciado em erros internos críticos do SQL Server, como spinlocks órfãos, violações graves de acesso de gravação ou muito dumping. Este é o comportamento padrão.
4	Especifica que um failover automático deve ser iniciado em erros internos moderados do SQL Server, como uma condição persistente de falta de memória no pool de recursos internos do SQL Server.
5	Especifica que um failover automático deve ser iniciado em quaisquer condições de falha qualificadas, incluindo: -Exaustão de threads de trabalho do SQL Engine. -Deteção de um impasse insolúvel.

Observação

A falta de resposta de uma instância do SQL Server às solicitações do cliente não é relevante para os grupos de disponibilidade.

Os valores FAILURE_CONDITION_LEVEL e HEALTH_CHECK_TIMEOUT definem uma política de failover flexível para um determinado grupo. Essa política de failover flexível fornece controle granular sobre quais condições devem causar um failover automático. Para obter mais informações, consulte Política de failover flexível para failover automático de um grupo de disponibilidade (SQL Server).

HEALTH_CHECK_TIMEOUT = milissegundos

Especifica o tempo de espera (em milissegundos) para o procedimento armazenado do sistema sp_server_diagnostics retornar informações de integridade do servidor antes que o cluster WSFC assuma que a instância do servidor está lenta ou não está respondendo. HEALTH_CHECK_TIMEOUT é definido no nível do grupo, mas é relevante apenas em réplicas de disponibilidade configuradas para o modo de disponibilidade de confirmação síncrona com failover automático (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Além disso, um tempo limite de verificação de integridade pode acionar um failover automático somente se as réplicas primária e secundária estiverem configuradas para o modo de failover automático (FAILOVER_MODE = AUTOMÁTICO) e se a réplica secundária estiver sincronizada com a réplica primária.

O valor HEALTH_CHECK_TIMEOUT padrão é 30000 milissegundos (30 segundos). O valor mínimo é de 15.000 milissegundos (15 segundos) e o valor máximo é de 4.294.967.295 milissegundos.

Importante

sp_server_diagnostics não executa verificações de integridade no nível do banco de dados.

DB_FAILOVER = { EM | DESLIGADO }

Especifica a resposta a ser tomada quando um banco de dados na réplica primária estiver offline. Quando definido como ON, qualquer status diferente de ONLINE para um banco de dados no grupo de disponibilidade dispara um failover automático. Quando essa opção é definida como OFF, somente a integridade da instância é usada para disparar o failover automático.

Para obter mais informações sobre essa configuração, consulte opção de deteção de integridade no nível de banco de dados

DTC_SUPPORT = { PER_DB | NENHUM }

Aplica-se a: SQL Server (a partir do SQL Server 2016 (13.x))

Especifica se as transações entre bancos de dados são suportadas por meio do coordenador de transações distribuídas (DTC). As transações entre bancos de dados só são suportadas a partir do SQL Server 2016 (13.x). PER_DB cria o grupo de disponibilidade com suporte para essas transações. Para obter mais informações, consulte transações entre bancos de dados e transações distribuídas para grupos de disponibilidade Always On e espelhamento de banco de dados (SQL Server).

BÁSICO

Aplica-se a: SQL Server (a partir do SQL Server 2016 (13.x))

Usado para criar um grupo de disponibilidade básica. Os grupos de disponibilidade básica são limitados a um banco de dados e duas réplicas: uma réplica primária e uma réplica secundária. Essa opção substitui o recurso de espelhamento de banco de dados preterido no SQL Server Standard Edition. Para obter mais informações, consulte Grupos de disponibilidade básica (grupos de disponibilidade Always On). Os grupos de disponibilidade básica são suportados a partir do SQL Server 2016 (13.x).

DISTRIBUÍDO

Aplica-se a: SQL Server (a partir do SQL Server 2016 (13.x))

Usado para criar um grupo de disponibilidade distribuído. Essa opção é usada com o parâmetro AVAILABILITY GROUP ON para conectar dois grupos de disponibilidade em Clusters de Failover do Windows Server separados. Para obter mais informações, consulte Grupos de disponibilidade distribuídos (grupos de disponibilidade Always On). Há suporte para grupos de disponibilidade distribuídos a partir do SQL Server 2016 (13.x).

CONTIDO [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES]

Introduzido no SQL Server 2022 (16.x).

Crie um grupo de disponibilidade contido. Essa opção é usada para criar um grupo de disponibilidade com seus próprios bancos de dados master e msdb, que são mantidos sincronizados em todo o conjunto de réplicas no grupo de disponibilidade.

A REUSE_SYSTEM_DATABASES opção faz com que os bancos de dados contidos master e msdb de uma versão anterior do grupo de disponibilidade sejam usados na criação desse novo grupo de disponibilidade. Para obter mais informações sobre grupos de disponibilidade contidos, consulte Visão geral do grupo de disponibilidade contida (grupos de disponibilidade Always On).

O SQL Server 2025 (17.x) introduz suporte para um grupo distribuído de disponibilidade contida. Se você pretende usar um AG contido como o encaminhador em um grupo de disponibilidade distribuída, você deve criar o AG contido usando a AUTOSEEDING_SYSTEM_DATABASES cláusula para a WITH | CONTAINED opção da CREATE AVAILABILITY GROUP instrução.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Aplica-se a: SQL Server (a partir do SQL Server 2017 (14.x))

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Introduzido no SQL Server 2017 (14.x). Define um número mínimo de réplicas secundárias síncronas necessárias para confirmar antes que a réplica primária confirme uma transação. Garante que as transações do SQL Server aguarde até que os logs de transações sejam atualizados no número mínimo de réplicas secundárias.

Padrão: 0. Fornece o mesmo comportamento que o SQL Server 2016 (13.x).
Mínimo: 0.
Máximo: Número de réplicas menos 1.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT está relacionado a réplicas no modo de confirmação síncrona. Quando as réplicas estão no modo de confirmação síncrona, as gravações na réplica primária aguardam até que as gravações em réplicas síncronas sejam confirmadas no log de transações do banco de dados de réplica. Se um SQL Server que hospeda uma réplica síncrona secundária parar de responder, o SQL Server que hospeda a réplica primária marcará essa réplica secundária como NÃO SINCRONIZADA e continuará. Quando o banco de dados que não responde voltar a ficar online, ele estará em um estado "não sincronizado" e a réplica será marcada como não íntegra até que o primário possa sincronizá-lo novamente. Essa configuração garante que a réplica primária não prossiga até que o número mínimo de réplicas tenha confirmado cada transação. Se o número mínimo de réplicas não estiver disponível, confirmará na falha primária. Para o tipo de cluster, EXTERNAL a configuração é alterada quando o grupo de disponibilidade é adicionado a um recurso de cluster. Consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Não suportado para CREATE AVAILABILITY GROUP. A partir do SQL Server 2022 (16.x), você pode usar o ALTER AVAILABILITY GROUP para definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT em um grupo de disponibilidade distribuído. Consulte ALTER AVAILABILITY GROUP (Transact-SQL).

TIPO_DE_CLUSTER

Aplica-se a: SQL Server (a partir do SQL Server 2017 (14.x)).

Usado para identificar se o grupo de disponibilidade está em um WSFC (Cluster de Failover do Windows Server). Defina como WSFC quando o grupo de disponibilidade estiver em uma instância de cluster de failover em um cluster de failover do Windows Server. Defina como EXTERNO quando o cluster é gerenciado por um gerenciador de cluster que não é um cluster de failover do Windows Server, como o Linux Pacemaker. Defina como NONE quando o grupo de disponibilidade não estiver usando o WSFC para coordenação de cluster. Por exemplo, quando um grupo de disponibilidade inclui servidores Linux sem gerenciador de cluster.

WRITE_LEASE_VALIDITY

Aplica-se a: SQL Server 2017 (14.x) e versões posteriores.

Especifica o tempo de concessão (em segundos) antes de expirar ou precisar de renovação. Isso monitora a integridade e a comunicação entre o orquestrador de cluster local e os processos de instância do SQL Server. O mecanismo de validade de concessão usa sinais de pulsação para a instância primária do SQL Server do grupo de disponibilidade. Se o primário não enviar ou receber uma renovação de locação dentro do período de validade do contrato, ele será considerado sem resposta e o principal ficará offline. Esse mecanismo evita situações de cérebro dividido quando o orquestrador de cluster não pode notificar o SQL Server para deixar de ser primário quando um novo primário é eleito por um failover. É aplicável apenas para CLUSTER_TYPE = EXTERNAL, quando o cluster é gerenciado por um gerenciador de cluster que não é um cluster de failover do Windows Server, como o Linux Pacemaker.

O orquestrador externo é responsável por garantir que o processo de renovação do contrato de arrendamento externo seja consistentemente estável. Se a mensagem de renovação de concessão for perdida inesperadamente, a réplica AG atual será definida offline, o que causará perda de disponibilidade AG.

CLUSTER_CONNECTION_OPTIONS

Aplica-se a: SQL Server 2025 (17.x) e versões posteriores

Use a cláusula para impor a CLUSTER_CONNECTION_OPTIONS criptografia TLS 1.3 para comunicação entre o Cluster de Failover do Windows Server e as réplicas do grupo de disponibilidade. As opções são especificadas como uma lista de pares chave-valor, separados por ponto-e-vírgula. Os pares chave-valor são usados para configurar a criptografia de cadeia de conexão para o grupo de disponibilidade.

Para obter mais informações, consulte Conectar-se a um grupo de disponibilidade com criptografia estrita e TDS 8.0.

A tabela a seguir descreve os pares chave-valor que você pode usar na CLUSTER_CONNECTION_OPTIONS cláusula:

Key	Valores suportados	Descrição
`Encrypt`	`Mandatory`, `Strict`, `Optional`	Especifica como a criptografia para o grupo de disponibilidade é imposta. Se o servidor não suportar encriptação, a ligação falhará. Se encrypt estiver definido como `Mandatory`, então `TrustServerCertificate` deve ser definido como yes. Se encrypt estiver definido como `Strict` então `TrustServerCertificate` será ignorado. Este par de valores de chave é necessário.
`HostNameInCertificate`	Nome da réplica ou nome do ouvinte AG	Especifica o nome da réplica ou o nome do ouvinte do grupo de disponibilidade no certificado usado para criptografia. Esse valor deve corresponder ao valor no Nome Alternativo da Entidade do certificado. Se o nome do servidor estiver listado no certificado, você poderá omitir o `HostNameInCertificate` par chave-valor. Se o nome do servidor não estiver listado no certificado, você deverá especificar o `HostNameInCertificate` par chave-valor com o nome do servidor. Este par de valores de chave é opcional.*
`TrustServerCertificate`	`Yes`, `No`	Defina como `yes` para especificar que o driver não valida o certificado TLS/SSL do servidor. Se `no`, o driver valida o certificado. Para obter mais informações, consulte TDS 8.0. Este par de valores de chave é opcional.*
`ServerCertificate`	Caminho para o certificado	Se não quiser usar `HostNameInCertificate`o , você pode passar o caminho para o seu certificado. A conta de serviço de cluster deve ter permissão para ler o certificado do local determinado. Este par de valores de chave é opcional.

Confira os exemplos para saber como usar a CLUSTER_CONNECTION_OPTIONS cláusula.

database_name DA BASE DE DADOS

Especifica uma lista de um ou mais bancos de dados de usuário na instância local do SQL Server (ou seja, a instância do servidor na qual você está criando o grupo de disponibilidade). Você pode especificar vários bancos de dados para um grupo de disponibilidade, mas cada banco de dados pode pertencer a apenas um grupo de disponibilidade. Para obter informações sobre o tipo de bancos de dados que um grupo de disponibilidade pode suportar, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On (SQL Server). Para descobrir quais bancos de dados locais já pertencem a um grupo de disponibilidade, consulte a coluna replica_id no sys.databases exibição de catálogo.

A cláusula DATABASE é opcional. Se você omiti-lo, o novo grupo de disponibilidade estará vazio.

Depois de criar o grupo de disponibilidade, conecte-se a cada instância do servidor que hospeda uma réplica secundária e, em seguida, prepare cada banco de dados secundário e associe-o ao grupo de disponibilidade. Para obter mais informações, consulte Iniciar movimentação de dados em um banco de dados secundário Always On (SQL Server).

Observação

Mais tarde, você pode adicionar bancos de dados qualificados na instância do servidor que hospeda a réplica primária atual a um grupo de disponibilidade. Você também pode remover um banco de dados de um grupo de disponibilidade. Para obter mais informações, consulte ALTER AVAILABILITY GROUP (Transact-SQL).

RÉPLICA EM

Especifica de uma a cinco instâncias do SQL Server para hospedar réplicas de disponibilidade no novo grupo de disponibilidade. Cada réplica é especificada pelo endereço da instância do servidor, seguido por uma cláusula WITH (...). Minimamente, você deve especificar sua instância do servidor local, que se torna a réplica primária inicial. Opcionalmente, você também pode especificar até quatro réplicas secundárias.

Você precisa unir todas as réplicas secundárias ao grupo de disponibilidade. Para obter mais informações, consulte ALTER AVAILABILITY GROUP (Transact-SQL).

Observação

Se você especificar menos de quatro réplicas secundárias ao criar um grupo de disponibilidade, poderá especificar uma réplica secundária adicional a qualquer momento usando a instrução ALTER AVAILABILITY GROUPTransact-SQL. Você também pode usar essa instrução para remover qualquer réplica secundária de um grupo de disponibilidade existente.

server_instance

Especifica o endereço da instância do SQL Server que é o host de uma réplica. O formato de endereço depende se a instância é a instância padrão ou nomeada e se é uma instância autônoma ou uma FCI (instância de cluster de failover), da seguinte maneira:

{ '*system_name*[\\*instance_name*]' | '*FCI_network_name*[\\*instance_name*]' }

Os componentes deste endereço são os seguintes:

system_name

É o nome NetBIOS do sistema de computador no qual reside a instância de destino do SQL Server. Este computador deve ser um nó WSFC.

FCI_network_name

É o nome da rede usado para acessar um cluster de failover do SQL Server. Use isso se a instância do servidor participar como um parceiro de failover do SQL Server. A execução de @@SERVERNAME SELECT em uma instância do servidor FCI retorna toda a cadeia de caracteres 'FCI_network_name[\instance_name]' (que é o nome completo da réplica).

instance_name

É o nome de uma instância de um SQL Server que é hospedado por system_name ou FCI_network_name e que tem o serviço HADR está habilitado. Para uma instância de servidor padrão, instance_name é opcional. O nome da instância não diferencia maiúsculas de minúsculas. Em uma instância nomeada, esse nome de valor é o mesmo que o valor retornado pela execução select ServerProperty(N'InstanceName');.

\

É um separador usado apenas ao especificar instance_name, a fim de separá-lo de system_name ou FCI_network_name.

Para obter informações sobre os pré-requisitos para nós WSFC e instâncias de servidor, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On (SQL Server).

ENDPOINT_URL ='TCP:// system-address:port'

Especifica o caminho da URL para o de ponto de extremidade de espelhamento de banco de dados na instância do SQL Server que hospeda a réplica de disponibilidade que você está definindo em sua cláusula REPLICA ON atual.

A cláusula ENDPOINT_URL é obrigatória. Para obter mais informações, consulte especificar a URL do ponto de extremidade ao adicionar ou modificar uma réplica de disponibilidade (SQL Server).

«TCP://endereço do sistema:port»

Especifica uma URL para especificar uma URL de ponto de extremidade ou uma URL de roteamento somente leitura. Os parâmetros de URL são os seguintes:

endereço do sistema

É uma cadeia de caracteres, como um nome de sistema, um nome de domínio totalmente qualificado ou um endereço IP, que identifica inequivocamente o sistema do computador de destino.

porta

É um número de porta associado ao ponto de extremidade de espelhamento da instância do servidor parceiro (para a opção ENDPOINT_URL) ou ao número da porta usado pelo Mecanismo de Banco de Dados da instância do servidor (para a opção READ_ONLY_ROUTING_URL).

AVAILABILITY_MODE = {SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT ou ASYNCHRONOUS_COMMIT especifica se a réplica primária precisa aguardar que a réplica secundária reconheça a proteção (gravação) dos registros de log no disco antes que a réplica primária possa confirmar a transação em um determinado banco de dados primário. As transações em bancos de dados diferentes na mesma réplica primária podem ser confirmadas de forma independente. O SQL Server 2017 (14.x) CU1 apresenta CONFIGURATION_ONLY. CONFIGURATION_ONLY réplica só se aplica a grupos de disponibilidade com CLUSTER_TYPE = EXTERNAL ou CLUSTER_TYPE = NONE.

SYNCHRONOUS_COMMIT

Especifica que a réplica primária aguarda para confirmar transações até que elas tenham sido reforçadas nessa réplica secundária (modo de confirmação síncrona). Você pode especificar SYNCHRONOUS_COMMIT para até três réplicas, incluindo a réplica primária.

ASYNCHRONOUS_COMMIT

Especifica que a réplica primária confirma transações sem esperar que essa réplica secundária proteja o log (modo de disponibilidade de confirmação síncrona). Você pode especificar ASYNCHRONOUS_COMMIT para até cinco réplicas de disponibilidade, incluindo a réplica primária.

CONFIGURATION_ONLY

Especifica que a réplica primária confirme de forma síncrona os metadados de configuração do grupo de disponibilidade no banco de dados mestre nessa réplica. A réplica não conterá dados do usuário. Esta opção:

Pode ser hospedado em qualquer edição do SQL Server, incluindo o Express Edition.
Requer que o ponto de extremidade de espelhamento de dados da réplica CONFIGURATION_ONLY seja do tipo WITNESS.
Não pode ser alterado.
Não é válido quando CLUSTER_TYPE = WSFC.
As opções failover_mode e seeding_mode não são suportadas quando availability_mode está definido como configuration_only para uma réplica. Um exemplo é mostrado aqui.

Para obter mais informações, consulte Réplica somente de configuração.

A cláusula AVAILABILITY_MODE é obrigatória. Para obter mais informações, consulte Modos de disponibilidade (grupos de disponibilidade Always On).

FAILOVER_MODE = { AUTOMÁTICO | MANUAL }

Especifica o modo de failover da réplica de disponibilidade que você está definindo.

AUTOMÁTICO

Permite failover automático. Esta opção só é suportada se você também especificar AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Você pode especificar AUTOMATIC para duas réplicas de disponibilidade, incluindo a réplica primária.

Observação

As FCIs (Instâncias de Cluster de Failover) do SQL Server não oferecem suporte a failover automático por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade hospedada por uma FCI só pode ser configurada para failover manual.

MANUAL

Permite o failover manual planejado ou o failover manual forçado (normalmente chamado de failover forçado) pelo administrador do banco de dados.

A cláusula FAILOVER_MODE é necessária. Os dois tipos de failover manual, failover manual sem perda de dados e failover forçado (com possível perda de dados), são suportados em condições diferentes. Para obter mais informações, consulte modos de failover e failover (grupos de disponibilidade Always On).

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

Especifica como a réplica secundária é inicialmente propagada.

AUTOMÁTICO

Permite a semeadura direta. Este método semeia a réplica secundária através da rede. Esse método não requer que você faça backup e restaure uma cópia do banco de dados primário na réplica.

Observação

Para propagação direta, você deve permitir a criação de banco de dados em cada réplica secundária chamando ALTER AVAILABILITY GROUP com a opção GRANT CREATE ANY DATABASE.

MANUAL

Especifica a propagação manual (padrão). Esse método requer que você crie um backup do banco de dados na réplica primária e restaure manualmente esse backup na réplica secundária.

BACKUP_PRIORITY = n

Especifica sua prioridade para executar backups nessa réplica em relação às outras réplicas no mesmo grupo de disponibilidade. O valor é um inteiro no intervalo de 0,100. Estes valores têm os seguintes significados:

1..100 indica que a réplica de disponibilidade pode ser escolhida para executar backups. 1 indica a prioridade mais baixa e 100 indica a prioridade mais alta. Se BACKUP_PRIORITY = 1, a réplica de disponibilidade será escolhida para executar backups somente se nenhuma réplica de disponibilidade de prioridade mais alta estiver disponível no momento.
0 indica que essa réplica de disponibilidade não se destina a executar backups. Isso é útil, por exemplo, para uma réplica de disponibilidade remota para a qual você nunca deseja que os backups façam failover.

Para obter mais informações, consulte Secundários ativos: backup em réplicas secundárias (grupos de disponibilidade Always On).

SECONDARY_ROLE ( ... )

Especifica as configurações específicas da função que entrarão em vigor se essa réplica de disponibilidade for atualmente proprietária da função secundária (ou seja, sempre que for uma réplica secundária). Entre parênteses, especifique uma ou ambas as opções de função secundária. Se você especificar ambos, use uma lista separada por vírgula.

As opções de função secundária são as seguintes:

ALLOW_CONNECTIONS = { NÃO | READ_ONLY | TODOS }

Especifica se os bancos de dados de uma determinada réplica de disponibilidade que está executando a função secundária (ou seja, está agindo como uma réplica secundária) podem aceitar conexões de clientes, uma das seguintes:

NÃO

Nenhuma conexão de usuário é permitida para bancos de dados secundários dessa réplica. Eles não estão disponíveis para acesso de leitura. Este é o comportamento padrão.

READ_ONLY

Somente conexões são permitidas com os bancos de dados na réplica secundária em que a propriedade Application Intent está definida como ReadOnly. Para obter mais informações sobre essa propriedade, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

TUDO

Todas as conexões são permitidas aos bancos de dados na réplica secundária para acesso somente leitura.

Para obter mais informações, consulte Secundários ativos: réplicas secundárias legíveis (grupos de disponibilidade Always On).

READ_ONLY_ROUTING_URL ='TCP:// system-address:port'

Especifica a URL a ser usada para rotear solicitações de conexão de intenção de leitura para essa réplica de disponibilidade. Esta é a URL na qual o Mecanismo de Banco de Dados escuta. Normalmente, a instância padrão do SQL Server escuta na porta TCP 1433.

Para uma instância nomeada, você pode obter o número da porta consultando a de porta e as colunas type_desc da exibição de gerenciamento dinâmico sys.dm_tcp_listener_states. A instância do servidor usa o ouvinte Transact-SQL (type_desc='TSQL').

Para obter mais informações sobre como calcular a URL de roteamento somente leitura para uma réplica, consulte Calculando read_only_routing_url paraAlways On .

Observação

Para uma instância nomeada do SQL Server, o ouvinte Transact-SQL deve ser configurado para usar uma porta específica. Para obter mais informações, consulte Configurar um servidor para escutar em uma porta TCP específica (SQL Server Configuration Manager).

PRIMARY_ROLE ( ... )

Especifica as configurações específicas da função que entrarão em vigor se essa réplica de disponibilidade for atualmente proprietária da função principal (ou seja, sempre que for a réplica primária). Entre parênteses, especifique uma ou ambas as opções de função primária. Se você especificar ambos, use uma lista separada por vírgula.

As principais opções de função são as seguintes:

ALLOW_CONNECTIONS = { READ_WRITE | TODOS }

Especifica o tipo de conexão que os bancos de dados de uma determinada réplica de disponibilidade que está executando a função principal (ou seja, está agindo como uma réplica primária) podem aceitar dos clientes, uma das seguintes:

LEITURA_ESCRITA

As conexões em que a propriedade de conexão Application Intent está definida como ReadOnly não são permitidas. Quando a propriedade Application Intent é definida como ReadWrite ou a propriedade de conexão Application Intent não está definida, a conexão é permitida. Para obter mais informações sobre a propriedade de conexão Application Intent, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

TUDO

Todas as conexões são permitidas aos bancos de dados na réplica primária. Este é o comportamento padrão.

READ_ONLY_ROUTING_LIST = { ('_server_instance_' [ , ... n ] ) | NENHUM }

Especifica uma lista separada por vírgulas de instâncias de servidor que hospedam réplicas de disponibilidade para esse grupo de disponibilidade que atendem aos seguintes requisitos quando executadas na função secundária:

Ser configurado para permitir todas as conexões ou conexões somente leitura (consulte o argumento ALLOW_CONNECTIONS da opção SECONDARY_ROLE).
Ter sua URL de roteamento somente leitura definida (consulte o argumento READ_ONLY_ROUTING_URL da opção SECONDARY_ROLE).

Os valores READ_ONLY_ROUTING_LIST são os seguintes:

server_instance

Especifica o endereço da instância do SQL Server que é o host de uma réplica que é uma réplica secundária legível quando executada sob a função secundária.

Use uma lista separada por vírgulas para especificar todas as instâncias do servidor que podem hospedar uma réplica secundária legível. O roteamento somente leitura segue a ordem na qual as instâncias do servidor são especificadas na lista. Se você incluir a instância do servidor host de uma réplica na lista de roteamento somente leitura da réplica, colocar essa instância do servidor no final da lista normalmente é uma boa prática, para que as conexões de intenção de leitura vão para uma réplica secundária, se houver uma disponível.

A partir do SQL Server 2016 (13.x), você pode balancear a carga de solicitações de intenção de leitura em réplicas secundárias legíveis. Para especificar isso, coloque as réplicas em um conjunto aninhado de parênteses na lista de roteamento somente leitura. Para obter mais informações e exemplos, consulte Configurar o balanceamento de carga entre réplicas somente leitura.

NENHUM

Especifica que, quando essa réplica de disponibilidade é a réplica primária, o roteamento somente leitura não é suportado. Este é o comportamento padrão.

READ_WRITE_ROUTING_URL ='TCP://endereço do sistema:porta'

Aplica-se a: SQL Server (a partir do SQL Server 2019 (15.x))

Especifica instâncias de servidor que hospedam réplicas de disponibilidade para esse grupo de disponibilidade que atendem aos seguintes requisitos quando executadas sob a função principal:

A especificação da réplica PRIMARY_ROLE inclui READ_WRITE_ROUTING_URL.
A cadeia de conexão é ReadWrite definindo ApplicationIntent como ReadWrite ou não definindo ApplicationIntent e deixando o padrão (ReadWrite) entrar em vigor.

Para obter mais informações, consulte Redirecionamento de conexão de leitura/gravação de réplica primária (grupos de disponibilidade Always On).

SESSION_TIMEOUT = inteiro

Especifica o período de tempo limite da sessão em segundos. Se você não especificar essa opção, por padrão, o período de tempo será de 10 segundos. O valor mínimo é de 5 segundos.

Importante

Recomendamos que você mantenha o período de tempo limite em 10 segundos ou mais.

Para obter mais informações sobre o período de tempo limite da sessão, consulte Visão geral dos grupos de disponibilidade Always On (SQL Server).

GRUPO DE DISPONIBILIDADE EM

Especifica dois grupos de disponibilidade que constituem um grupo de disponibilidade distribuído . Cada grupo de disponibilidade faz parte de seu próprio WSFC (Cluster de Failover do Windows Server). Quando você cria um grupo de disponibilidade distribuída, o grupo de disponibilidade na instância atual do SQL Server se torna o grupo de disponibilidade principal. O segundo grupo de disponibilidade torna-se o grupo de disponibilidade secundário.

Você precisa unir o grupo de disponibilidade secundário ao grupo de disponibilidade distribuída. Para obter mais informações, consulte ALTER AVAILABILITY GROUP (Transact-SQL).

ag_name

Especifica o nome do grupo de disponibilidade que compõe metade do grupo de disponibilidade distribuída.

LISTENER_URL ='TCP:// system-address:port'

Especifica o caminho da URL para o ouvinte associado ao grupo de disponibilidade.

A cláusula LISTENER_URL é obrigatória.

«TCP://endereço do sistema:port»

Especifica uma URL para o ouvinte associado ao grupo de disponibilidade. Os parâmetros de URL são os seguintes:

de endereço do sistema

É uma cadeia de caracteres, como um nome de sistema, um nome de domínio totalmente qualificado ou um endereço IP, que identifica inequivocamente o ouvinte.

porto

É um número de porta associado ao ponto de extremidade de espelhamento do grupo de disponibilidade. Observe que essa não é a porta do ouvinte.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Especifica se a réplica primária precisa aguardar que o grupo de disponibilidade secundário reconheça a proteção (gravação) dos registros de log em disco antes que a réplica primária possa confirmar a transação em um determinado banco de dados primário.

SYNCHRONOUS_COMMIT

Especifica que a réplica primária aguarda para confirmar transações até que elas tenham sido reforçadas no grupo de disponibilidade secundário. Você pode especificar SYNCHRONOUS_COMMIT para até dois grupos de disponibilidade, incluindo o grupo de disponibilidade principal.

ASYNCHRONOUS_COMMIT

Especifica que a réplica primária confirma transações sem esperar que esse grupo de disponibilidade secundário proteja o log. Você pode especificar ASYNCHRONOUS_COMMIT para até dois grupos de disponibilidade, incluindo o grupo de disponibilidade principal.

A cláusula AVAILABILITY_MODE é obrigatória.

FAILOVER_MODE = { MANUAL }

Especifica o modo de failover do grupo de disponibilidade distribuído.

MANUAL

Permite o failover manual planejado ou o failover manual forçado (normalmente chamado de failover forçado) pelo administrador do banco de dados.

A cláusula FAILOVER_MODE é obrigatória, e a única opção é MANUAL. Não há suporte para failover automático para o grupo de disponibilidade secundário.

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

Especifica como o grupo de disponibilidade secundário é inicialmente propagado.

AUTOMÁTICO

Permite a semeadura direta. Este método semeia o grupo de disponibilidade secundária na rede. Esse método não exige que você faça backup e restaure uma cópia do banco de dados primário nas réplicas do grupo de disponibilidade secundário.

MANUAL

Especifica a propagação manual (padrão). Esse método requer que você crie um backup do banco de dados na réplica primária e restaure manualmente esse backup na(s) réplica(s) do grupo de disponibilidade secundário.

OUVINTE 'dns_name'( listener_option )

Define um novo ouvinte do grupo de disponibilidade para esse grupo de disponibilidade. LISTENER é um argumento opcional.

Importante

Antes de criar seu primeiro ouvinte, é altamente recomendável que você leia Criar ou configurar um ouvinte de grupo de disponibilidade (SQL Server).

Depois de criar um ouvinte para um determinado grupo de disponibilidade, é altamente recomendável que você faça o seguinte:

Peça ao administrador da rede para reservar o endereço IP do ouvinte para seu uso exclusivo.
Forneça o nome de host DNS do ouvinte aos desenvolvedores de aplicativos para usar em cadeias de conexão ao solicitar conexões de cliente para esse grupo de disponibilidade.

dns_name

Especifica o nome do host DNS do ouvinte do grupo de disponibilidade. O nome DNS do ouvinte deve ser exclusivo no domínio e no NetBIOS.

dns_name é um valor de cadeia de caracteres. Este nome pode conter apenas caracteres alfanuméricos, traços (-) e hífenes (_), em qualquer ordem. Os nomes de host DNS não diferenciam maiúsculas de minúsculas. O comprimento máximo é de 63 caracteres.

Recomendamos que você especifique uma cadeia de caracteres significativa. Por exemplo, para um grupo de disponibilidade chamado AG1, um nome de host DNS significativo seria ag1-listener.

Importante

NetBIOS reconhece apenas os primeiros 15 caracteres no dns_name. Se você tiver dois clusters WSFC controlados pelo mesmo Ative Directory e tentar criar ouvintes de grupo de disponibilidade em ambos os clusters usando nomes com mais de 15 caracteres e um prefixo idêntico de 15 caracteres, um erro informará que o recurso Nome da Rede Virtual não pôde ser colocado online. Para obter informações sobre regras de nomenclatura de prefixo para nomes DNS, consulte Atribuindo nomes de domínio.

listener_option

LISTENER usa uma das seguintes opções de <listener_option>:

COM DHCP [ EM { ('four_part_ipv4_address'',four_part_ipv4_mask') } ]

Especifica que o ouvinte do grupo de disponibilidade usa o protocolo DHCP (Dynamic Host Configuration Protocol). Opcionalmente, use a cláusula ON para identificar a rede na qual esse ouvinte é criado. O DHCP é limitado a uma única sub-rede usada para cada instância de servidor que hospeda uma réplica no grupo de disponibilidade.

Importante

Não recomendamos DHCP no ambiente de produção. Se houver um tempo de inatividade e a concessão de IP DHCP expirar, será necessário tempo extra para registrar o novo endereço IP da rede DHCP associado ao nome DNS do ouvinte e afetar a conectividade do cliente. No entanto, o DHCP é bom para configurar seu ambiente de desenvolvimento e teste para verificar funções básicas de grupos de disponibilidade e para integração com seus aplicativos.

Por exemplo:

WITH DHCP ON ('10.120.19.0','255.255.254.0')

COM IP ( { ('four_part_ipv4_address'',four_part_ipv4_mask') | ('ipv6_address') } [ , ...n ] ) [ , PORTA =listener_port ]

Especifica que, em vez de usar DHCP, o ouvinte do grupo de disponibilidade usa um ou mais endereços IP estáticos. Para criar um grupo de disponibilidade em várias sub-redes, cada sub-rede requer um endereço IP estático na configuração do ouvinte. Para uma determinada sub-rede, o endereço IP estático pode ser um endereço IPv4 ou um endereço IPv6. Entre em contato com o administrador da rede para obter um endereço IP estático para cada sub-rede que hospeda uma réplica para o novo grupo de disponibilidade.

Por exemplo:

WITH IP ( ('10.120.19.155','255.255.254.0') )

ip4_address

Especifica um endereço IPv4 de quatro partes para um ouvinte do grupo de disponibilidade. Por exemplo, 10.120.19.155.

ipv4_mask

Especifica uma máscara IPv4 de quatro partes para um ouvinte do grupo de disponibilidade. Por exemplo, 255.255.254.0.

ipv6_address

Especifica um endereço IPv6 para um ouvinte do grupo de disponibilidade. Por exemplo, 2001::4898:23:1002:20f:1fff:feff:b3a3.

PORTA = listener_port

Especifica o número da porta -listener_port- a ser usado por um ouvinte do grupo de disponibilidade especificado por uma cláusula IP WITH. PORT é opcional.

O número de porta padrão, 1433, é suportado. No entanto, se você tiver preocupações de segurança, recomendamos o uso de um número de porta diferente.

Por exemplo: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

Pré-requisitos e restrições

Para obter informações sobre os pré-requisitos para criar um grupo de disponibilidade, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On (SQL Server).

Para obter informações sobre restrições nas instruções de Transact-SQL AVAILABILITY GROUP, consulte Overview of Transact-SQL Statements for Always On availability groups (SQL Server).

Segurança

Permissões

Requer associação à função de servidor fixa sysadmin e permissão de servidor CREATE AVAILABILITY GROUP, permissão ALTER ANY AVAILABILITY GROUP ou permissão CONTROL SERVER.

Exemplos

Um. Configurar backup em réplicas secundárias, política flexível de failover e acesso à conexão

O exemplo a seguir cria um grupo de disponibilidade chamado MyAg para dois bancos de dados de usuário, ThisDatabase e ThatDatabase. A tabela a seguir resume os valores especificados para as opções definidas para o grupo de disponibilidade como um todo.

Opção de grupo	Cenário	Descrição
AUTOMATED_BACKUP_PREFERENCE	SECUNDÁRIO	Essa preferência de backup automatizado indica que os backups devem ocorrer em uma réplica secundária, exceto quando a réplica primária for a única réplica online (esse é o comportamento padrão). Para que a configuração AUTOMATED_BACKUP_PREFERENCE tenha algum efeito, você precisa criar scripts de tarefas de backup nos bancos de dados de disponibilidade para levar em conta a preferência de backup automatizado.
FAILURE_CONDITION_LEVEL	3	Essa configuração de nível de condição de falha especifica que um failover automático deve ser iniciado em erros internos críticos do SQL Server, como spinlocks órfãos, violações graves de acesso de gravação ou muito dumping.
HEALTH_CHECK_TIMEOUT	600000	Esse valor de tempo limite de verificação de integridade, 60 segundos, especifica que o cluster WSFC aguarda 60000 milissegundos para que o procedimento armazenado do sistema sp_server_diagnostics retorne informações de integridade do servidor sobre uma instância de servidor que está hospedando uma réplica de confirmação síncrona com automática antes que o cluster assuma que a instância do servidor host está lenta ou não está respondendo. (O valor padrão é 30000 milissegundos).

Três réplicas de disponibilidade devem ser hospedadas pelas instâncias de servidor padrão em computadores chamados COMPUTER01, COMPUTER02e COMPUTER03. A tabela a seguir resume os valores especificados para as opções de réplica de cada réplica.

Opção de réplica	Configuração em `COMPUTER01`	Configuração em `COMPUTER02`	Configuração em `COMPUTER03`	Descrição
ENDPOINT_URL	TCP:// COMPUTER01:5022	TCP:// COMPUTER02:5022	TCP:// COMPUTER03:5022	Neste exemplo, os sistemas são do mesmo domínio, portanto, as URLs do ponto de extremidade podem usar o nome do sistema do computador como o endereço do sistema.
AVAILABILITY_MODE	SYNCHRONOUS_COMMIT	SYNCHRONOUS_COMMIT	ASYNCHRONOUS_COMMIT	Duas das réplicas usam o modo de confirmação síncrona. Quando sincronizados, eles suportam failover sem perda de dados. A terceira réplica, que usa o modo de disponibilidade de confirmação assíncrona.
MODO_DE_REDUNDÂNCIA	AUTOMÁTICO	AUTOMÁTICO	MANUAL	As réplicas de confirmação síncrona oferecem suporte a failover automático e failover manual planejado. A réplica do modo de disponibilidade de confirmação síncrona suporta apenas failover manual forçado.
BACKUP_PRIORITY	30	30	90	Uma prioridade mais alta, 90, é atribuída à réplica de confirmação assíncrona do que às réplicas de confirmação síncrona. Os backups tendem a ocorrer na instância do servidor que hospeda a réplica de confirmação assíncrona.
SECONDARY_ROLE	( ALLOW_CONNECTIONS = NÃO, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01:1433' )	( ALLOW_CONNECTIONS = NÃO, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02:1433' )	( ALLOW_CONNECTIONS = READ_ONLY, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03:1433' )	Somente a réplica de confirmação assíncrona serve como uma réplica secundária legível. Especifica o nome do computador e o número da porta padrão do Mecanismo de Banco de Dados (1433). Este argumento é opcional.
PRIMARY_ROLE	( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (COMPUTER03) )	( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (COMPUTER03) )	( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = NENHUM )	Na função principal, todas as réplicas rejeitam tentativas de conexão com intenção de leitura. As solicitações de conexão com intenção de leitura são roteadas para COMPUTER03 se a réplica local estiver sendo executada na função secundária. Quando essa réplica é executada na função principal, o roteamento somente leitura é desabilitado. Este argumento é opcional.
SESSION_TIMEOUT	10	10	10	Este exemplo especifica o valor de tempo limite de sessão padrão (10). Este argumento é opcional.

Finalmente, o exemplo especifica a cláusula LISTENER opcional para criar um ouvinte de grupo de disponibilidade para o novo grupo de disponibilidade. Um nome DNS exclusivo, MyAgListenerIvP6, é especificado para este ouvinte. As duas réplicas estão em sub-redes diferentes, portanto, o ouvinte deve usar endereços IP estáticos. Para cada uma das duas réplicas de disponibilidade, a cláusula WITH IP especifica um endereço IP estático, 2001:4898:f0:f00f::cf3c e 2001:4898:e0:f213::4ce2, que usam o formato IPv6. Este exemplo também usa o argumento PORT opcional para especificar a porta 60173 como a porta do ouvinte.

CREATE AVAILABILITY GROUP MyAg   
   WITH (  
      AUTOMATED_BACKUP_PREFERENCE = SECONDARY,  
      FAILURE_CONDITION_LEVEL  =  3,   
      HEALTH_CHECK_TIMEOUT = 600000  
       )  
  
   FOR   
      DATABASE  ThisDatabase, ThatDatabase   
   REPLICA ON   
      'COMPUTER01' WITH   
         (  
         ENDPOINT_URL = 'TCP://COMPUTER01:5022',  
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,  
         FAILOVER_MODE = AUTOMATIC,  
         BACKUP_PRIORITY = 30,  
         SECONDARY_ROLE (ALLOW_CONNECTIONS = NO,   
            READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01:1433' ),
         PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,   
            READ_ONLY_ROUTING_LIST = (COMPUTER03) ),  
         SESSION_TIMEOUT = 10  
         ),   
  
      'COMPUTER02' WITH   
         (  
         ENDPOINT_URL = 'TCP://COMPUTER02:5022',  
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,  
         FAILOVER_MODE = AUTOMATIC,  
         BACKUP_PRIORITY = 30,  
         SECONDARY_ROLE (ALLOW_CONNECTIONS = NO,   
            READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02:1433' ),  
         PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,   
            READ_ONLY_ROUTING_LIST = (COMPUTER03) ),  
         SESSION_TIMEOUT = 10  
         ),   
  
      'COMPUTER03' WITH   
         (  
         ENDPOINT_URL = 'TCP://COMPUTER03:5022',  
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,  
         FAILOVER_MODE =  MANUAL,  
         BACKUP_PRIORITY = 90,  
         SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY,   
            READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03:1433' ),  
         PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,   
            READ_ONLY_ROUTING_LIST = NONE ),  
         SESSION_TIMEOUT = 10  
         );
GO  
ALTER AVAILABILITY GROUP [MyAg]
  ADD LISTENER 'MyAgListenerIvP6' ( WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , PORT = 60173 );   
GO

B. Impor criptografia em conexões com um grupo de disponibilidade

Os exemplos nesta seção forçam a criptografia em conexões com o grupo de AccountsAG disponibilidade.

Se o nome do servidor estiver listado em cada certificado, conforme definido por qualquer um dos métodos, você poderá omitir a HostNameInCertificate opção:

CREATE AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict')

Se você seguiu o método 1 e o nome do servidor não está listado como um Nome Alternativo da Entidade no certificado, então você deve especificar qualquer valor listado no Nome Alternativo da HostNameInCertificate Entidade na opção.

CREATE AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;HostNameInCertificate=<Subject Alternative Name>')

Se você seguiu o método 1 e deseja utilizar a ServerCertificate propriedade em vez de fornecer um valor para HostNameInCertificate:

CREATE AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;ServerCertificate=C:\Users\admin\SqlAGCertificate.cer')

Tarefas relacionadas

Ver também

GRUPO ALTERAR DISPONIBILIDADE (Transact-SQL)
ALTERAR DATABASE SET HADR (Transact-SQL)
GRUPO DROP AVAILABILITY (Transact-SQL)
Solucionar problemas de configuração de grupos de disponibilidade Always On (SQL Server)
Visão geral dos grupos de disponibilidade Always On (SQL Server)
Ouvintes do grupo de disponibilidade, conectividade de cliente e failover de aplicativos (SQL Server)

Comentários

Esta página foi útil?

Last updated on 2025-08-15

Partilhar via

CRIAR GRUPO DE DISPONIBILIDADE (Transact-SQL)

Sintaxe

Argumentos

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMÁRIO | SECONDARY_ONLY | SECUNDÁRIO | NENHUM }

PRIMÁRIO

SECONDARY_ONLY

SECUNDÁRIO

NENHUM

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

HEALTH_CHECK_TIMEOUT = milissegundos

DB_FAILOVER = { EM | DESLIGADO }

DTC_SUPPORT = { PER_DB | NENHUM }

BÁSICO

DISTRIBUÍDO

CONTIDO [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES]

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

TIPO_DE_CLUSTER

WRITE_LEASE_VALIDITY

CLUSTER_CONNECTION_OPTIONS

database_name DA BASE DE DADOS

RÉPLICA EM

server_instance

system_name

FCI_network_name

instance_name

\

ENDPOINT_URL ='TCP:// system-address:port'

«TCP://endereço do sistema:port»

endereço do sistema

porta

AVAILABILITY_MODE = {SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

CONFIGURATION_ONLY

FAILOVER_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

BACKUP_PRIORITY = n

SECONDARY_ROLE ( ... )

ALLOW_CONNECTIONS = { NÃO | READ_ONLY | TODOS }

NÃO

READ_ONLY

TUDO

READ_ONLY_ROUTING_URL ='TCP:// system-address:port'

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | TODOS }

LEITURA_ESCRITA

TUDO

READ_ONLY_ROUTING_LIST = { ('_server_instance_' [ , ... n ] ) | NENHUM }

server_instance

NENHUM

READ_WRITE_ROUTING_URL ='TCP://endereço do sistema:porta'

SESSION_TIMEOUT = inteiro

GRUPO DE DISPONIBILIDADE EM

ag_name

LISTENER_URL ='TCP:// system-address:port'

«TCP://endereço do sistema:port»

de endereço do sistema

porto

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUAL }

MANUAL

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

OUVINTE 'dns_name'( listener_option )

dns_name

listener_option

COM DHCP [ EM { ('four_part_ipv4_address'',four_part_ipv4_mask') } ]

COM IP ( { ('four_part_ipv4_address'',four_part_ipv4_mask') | ('ipv6_address') } [ , ...n ] ) [ , PORTA =listener_port ]

ip4_address

ipv4_mask

ipv6_address