ALTERAR GRUPO DE DISPONIBILIDADE (Transact-SQL)

Aplica-se:SQL Server

Altera um grupo de disponibilidade Always On existente no SQL Server. A maioria dos ALTER AVAILABILITY GROUP argumentos tem suporte apenas na réplica primária atual. No entanto, há suporte para argumentos JOINe FORCE_FAILOVER_ALLOW_DATA_LOSS , FAILOVERno entanto, apenas em réplicas secundárias.

Convenções de sintaxe de Transact-SQL

Sintaxe

ALTER AVAILABILITY GROUP group_name
  {
     SET ( <set_option_spec> )
   | ADD DATABASE database_name
   | REMOVE DATABASE database_name
   | ADD REPLICA ON <add_replica_spec>
   | MODIFY REPLICA ON <modify_replica_spec>
   | REMOVE REPLICA ON <server_instance>
   | JOIN
   | JOIN AVAILABILITY GROUP ON <add_availability_group_spec> [ , ...2 ]
   | MODIFY AVAILABILITY GROUP ON <modify_availability_group_spec> [ , ...2 ]
   | GRANT CREATE ANY DATABASE
   | DENY CREATE ANY DATABASE
   | FAILOVER
   | FORCE_FAILOVER_ALLOW_DATA_LOSS
   | ADD LISTENER 'dns_name' ( <add_listener_option> )
   | MODIFY LISTENER 'dns_name' ( <modify_listener_option> )
   | RESTART LISTENER 'dns_name'
   | REMOVE LISTENER 'dns_name'
   | OFFLINE
  }
[ ; ]

<set_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 }
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | ROLE = SECONDARY
  | CLUSTER_CONNECTION_OPTIONS = 'key_value_pairs> [ ;... ] '

<server_instance> ::=
 { 'system_name [ \instance_name ] ' | 'FCI_network_name [ \instance_name ] ' }

<add_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY } ,
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <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

<modify_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port'
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
     | FAILOVER_MODE = { AUTOMATIC | MANUAL }
     | SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }  ]
        | [ READ_ONLY_ROUTING_URL = { 'TCP://system-address:port' | NONE } ]
          } )
     | PRIMARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { READ_WRITE | ALL }   ]
        | [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        | [ READ_WRITE_ROUTING_URL = { 'TCP://system-address:port' | NONE }  ]
          } )
     | SESSION_TIMEOUT = seconds
    )

<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 }
    )

<modify_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER = 'TCP://system-address:port'
       | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
       | SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<add_listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     'ipv4_address' , 'ipv4_mask'

  <ip_address_option> ::=
     {
        'four_part_ipv4_address' , 'four_part_ipv4_mask'
      | 'ipv6_address'
     }

<modify_listener_option>::=
    {
       ADD IP ( <ip_address_option> )
     | PORT = listener_port
     | REMOVE IP ( 'ipv4_address' | 'ipv6_address')
    }

Argumentos

group_name

Especifica o nome do novo grupo de disponibilidade. group_name deve ser um identificador válido do SQL Server e deve ser exclusivo em todos os grupos de disponibilidade no cluster WSFC.

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECUNDÁRIO | NONE }

Especifica uma preferência sobre como um trabalho de backup avalia a réplica primária ao escolher onde executar backups. Você pode criar um script de um determinado trabalho de backup para considerar a preferência de backup automatizada. É importante entender que a preferência não é imposta pelo SQL Server e, portanto, não tem nenhum efeito em backups ad hoc.

Com suporte apenas na réplica principal.

Os valores são os seguintes:

PRIMÁRIO

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

Importante

Se você planeja usar o envio de logs para preparar os bancos de dados secundários para um grupo de disponibilidade, defina a preferência de backup automatizado para Primary até que todos os bancos de dados secundários sejam preparados e unidos ao grupo de disponibilidade.

SECONDARY_ONLY

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

SECUNDÁRIO

Especifica que os backups ocorrem em uma réplica secundária, exceto quando a réplica primária é a única réplica online. Nesse caso, o backup ocorre na réplica primária. Esse é o comportamento padrão.

Nenhuma

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

Importante

Não há nenhuma imposição da AUTOMATED_BACKUP_PREFERENCE configuração. A interpretação dessa preferência depende da lógica, se houver, de que você faça script em trabalhos de backup para os bancos de dados em um determinado grupo de disponibilidade. A configuração de preferência de backup automatizado não tem efeito sobre backups ad hoc. Para obter mais informações, consulte Configurar backups em réplicas secundárias de um grupo de disponibilidade Always On.

Observação

Para exibir a preferência de backup automatizado de um grupo de disponibilidade existente, selecione a coluna ou automated_backup_preference_desc a automated_backup_preference exibição do catálogo sys.availability_groups. Além disso, sys.fn_hadr_backup_is_preferred_replica pode ser usado para determinar a réplica de backup preferencial. Essa função sempre 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 disparam 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 = AUTOMATIC) e a réplica secundária estiver sincronizada com a réplica primária no momento.

Com suporte apenas na réplica principal.

Os níveis da condição de falha (1 a 5) variam do menos restritivo, nível 1, até o mais restritivo, nível 5. Um determinado nível de condição abrange todos os níveis menos restritivos. Assim, o nível de condição mais rígido, 5, inclui os quatro níveis de condição menos restritivos (1 a 4), o nível 4 inclui os níveis 1 a 3 e assim sucessivamente. 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 é iniciado quando qualquer um dos seguintes ocorre: O serviço SQL Server está inativo. A concessão do grupo de disponibilidade para se conectar ao cluster WSFC expira porque não `ACK` é recebida da instância do servidor. Para obter mais informações, confira Como funciona: Tempo limite de concessão do Always On do SQL Server.
2	Especifica que um failover automático é iniciado quando qualquer um dos seguintes ocorre: A instância do SQL Server não se conecta ao cluster e o limite especificado `HEALTH_CHECK_TIMEOUT` 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 é iniciado em erros internos críticos do SQL Server, como spinlocks órfãos, violações graves de acesso de gravação ou muito despejo. Esse é o comportamento padrão.
4	Especifica que um failover automático é iniciado em erros internos moderados do SQL Server, como uma condição persistente de memória insuficiente no pool de recursos interno do SQL Server.
5	Especifica que um failover automático é iniciado em quaisquer condições de falha qualificadas, incluindo: Esgotamento dos threads de trabalho do SQL Engine. Detecção de um deadlock insolúvel.

Observação

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

Os FAILURE_CONDITION_LEVEL valores e HEALTH_CHECK_TIMEOUT os valores definem uma política de failover flexível para um determinado grupo. Essa política de failover flexível permite a você um controle granular sobre quais condições devem causar um failover automático. Para obter mais informações, consulte Configurar uma política de failover automático flexível para um grupo de disponibilidade Always On.

`HEALTH_CHECK_TIMEOUT` = Milissegundos

Especifica o tempo de espera, em milissegundos, para que o procedimento armazenado do sistema sp_server_diagnostics retorne informações de integridade do servidor antes que o cluster WSFC assuma que a instância do servidor está lenta ou não respondendo. Defina HEALTH_CHECK_TIMEOUT no nível do grupo, mas é relevante apenas em réplicas de disponibilidade que você configura 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 poderá 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 = AUTOMATIC) e a réplica secundária estiver sincronizada com a réplica primária no momento.

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

Com suporte apenas na réplica principal.

Importante

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

DB_FAILOVER = { ON | DESLIGADO }

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

Para obter mais informações sobre essa configuração, consulte a opção de failover de detecção de integridade no nível do banco de dados do grupo de disponibilidade.

DTC_SUPPORT = { PER_DB | NENHUM }

Especifica se as transações distribuídas estão habilitadas para esse grupo de disponibilidade. Somente há suporte para transações distribuídas para bancos de dados de grupo de disponibilidade do SQL Server 2016 (13.x) em diante e transações entre bancos de dados têm suporte apenas do SQL Server 2016 (13.x) SP2 em diante. PER_DB cria o grupo de disponibilidade com suporte para essas transações e promove automaticamente transações entre bancos de dados envolvendo bancos de dados no grupo de disponibilidade em transações distribuídas. NONE impede a promoção automática de transações entre bancos de dados para transações distribuídas e não registra o banco de dados com uma RMID estável no DTC. As transações distribuídas não são impedidas quando a configuração de NONE é usada, mas o failover do banco de dados e a recuperação automática podem não ter êxito em algumas circunstâncias. Para obter mais informações, consulte Transações – grupos de disponibilidade e espelhamento de banco de dados.

Observação

O suporte para alterar a DTC_SUPPORT configuração de um grupo de disponibilidade foi introduzido no SQL Server 2016 (13.x) Service Pack 2. Essa opção não pode ser usada com versões anteriores. Para alterar essa configuração em versões anteriores do SQL Server, você deve DROP e CREATE o grupo de disponibilidade novamente.

Importante

O DTC tem um limite de 32 inscrições por transação distribuída. Como cada banco de dados em um grupo de disponibilidade se insere com o DTC separadamente, se a transação envolver mais de 32 bancos de dados, você poderá receber o seguinte erro quando o SQL Server tentar inscrever o 33º banco de dados:

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

Para obter mais detalhes sobre transações distribuídas no SQL Server, consulte Transações distribuídas.

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 que devem ser confirmadas antes que a réplica primária confirme uma transação. Garante que as transações do SQL Server esperem 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 refere-se 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 nas réplicas síncronas sejam confirmadas no log de transação 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 marca essa réplica secundária como NOT SYNCHRONIZED e continua. Quando o banco de dados sem resposta volta a ficar online, ele está em um estado "não sincronizado" e a réplica é marcada como não íntegra até que o primário possa sincronizá-la 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, as confirmações no primário falharão. 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 as configurações de grupo de disponibilidade.

A partir do SQL Server 2022 (16.x), você pode definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT em um grupo de disponibilidade distribuído. Não há suporte para essa configuração.CREATE AVAILABILITY GROUP Você pode usar ALTER AVAILABILITY GROUP para definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Por exemplo:

ALTER AVAILABILITY GROUP [<name>]
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = <integer>);

FUNÇÃO

O único parâmetro válido é SECONDARY, e essa SET opção só é válida em grupos de disponibilidade distribuídos. Use-o para fazer failover de um grupo de disponibilidade distribuído.

CLUSTER_CONNECTION_OPTIONS

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

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

Para reverter para criptografia padrão, defina a CLUSTER_CONNECTION_OPTIONS cláusula como uma cadeia de caracteres vazia. O SQL Server 2025 (17.x) define por padrão , Encrypt=Mandatorye TrustServerCertificate=Yes para conexões a réplicas de grupos de disponibilidade e ouvintes.

Para obter mais informações, examine a conexão 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 com suporte	Description
`Encrypt`	`Mandatory`, , `StrictOptional`	Especifica como a criptografia para o grupo de disponibilidade é imposta. Se o servidor não der suporte à criptografia, a conexão falhará. Se você definir a criptografia como `Mandatory`, deverá `TrustServerCertificate` ser definido como sim. Se você definir a criptografia como `Strict`, será `TrustServerCertificate` ignorada. Observação: esse par de valores de chave é necessário.
`HostNameInCertificate`	Nome da réplica ou nome do ouvinte do 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. Observação: esse par de valores de chave é opcional.
`TrustServerCertificate`	`Yes`, `No`	Defina para `yes` especificar que o driver não valida o certificado TLS/SSL do servidor. Se `no`o driver validar o certificado. Para obter mais informações, examine o TDS 8.0. Observação: esse par de valores de chave é opcional.
`ServerCertificate`	Caminho para seu certificado	Se você não quiser usar `HostNameInCertificate`, poderá passar o caminho para o certificado. A conta de serviço do cluster deve ter permissão para ler o certificado do local determinado. Observação: esse par de valores de chave é opcional.
`CLUSTER_CONNECTION_OPTIONS`	Cadeia de caracteres vazia (`''`)	Limpa a configuração existente e reverte para as configurações de criptografia padrão de `Encrypt=Mandatory` e `TrustServerCertificate=Yes`.

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

ADICIONAR database_name DE BANCO DE DADOS

Especifica uma lista de um ou mais bancos de dados do usuário que você deseja acrescentar ao grupo de disponibilidade. Esses bancos de dados devem residir na instância do SQL Server que hospeda a réplica primária atual. É possível 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 dar suporte, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On. Para descobrir quais bancos de dados locais já pertencem a um grupo de disponibilidade, consulte a replica_id coluna na exibição do catálogo sys.databases .

Com suporte apenas na réplica principal.

Observação

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

REMOVER database_name DO BANCO DE DADOS

Remove o banco de dados primário especificado e os bancos de dados secundários correspondentes do grupo de disponibilidade. Com suporte apenas na réplica principal.

Para obter informações sobre as etapas recomendadas depois de remover um banco de dados de disponibilidade de um grupo de disponibilidade, consulte Remover um banco de dados primário de um grupo de disponibilidade Always On.

ADICIONAR RÉPLICA EM

Especifica de uma a oito instâncias do SQL Server para hospedar réplicas secundárias em um grupo de disponibilidade. Cada réplica é especificada pelo endereço da instância do servidor seguido por uma WITH (...) cláusula.

Com suporte apenas na réplica principal.

É necessário unir cada réplica secundária nova ao grupo de disponibilidade. Para obter mais informações, consulte a descrição da opção JOIN , mais adiante nesta seção.

<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 uma instância nomeada e se é uma instância autônoma ou uma FCI (instância de cluster de failover). A sintaxe é mostrada a seguir:

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

Os componentes desse 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. Esse computador deve ser um nó WSFC.

FCI_network_name

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

Para obter mais informações, consulte @@SERVERNAME.

instance_name

O nome de uma instância de um SQL Server que system_name ou FCI_network_name hosts e que tem Always On 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 de servidor autônomo, esse nome de valor é o mesmo que o valor retornado pela execução SELECT @@SERVERNAME.

\

Um separador usado somente 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.

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

Especifica o caminho da URL para o 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á adicionando ou modificando.

ENDPOINT_URL é necessário na ADD REPLICA ON cláusula e opcional na MODIFY REPLICA ON cláusula. Para obter mais informações, consulte Especificar URL do Ponto de Extremidade – Adicionando ou modificando a réplica de disponibilidade.

'TCP:// system-address:port'

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

system-address

Uma cadeia de caracteres, como um nome de sistema, um nome de domínio totalmente qualificado ou um endereço IP, que identifica sem ambiguidade o sistema de computador de destino.

porta

Um número de porta associado ao ponto de extremidade de espelhamento da instância do servidor (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 }

Especifica se a réplica primária aguarda a réplica secundária reconhecer 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 independentemente.

SYNCHRONOUS_COMMIT

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

ASYNCHRONOUS_COMMIT

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

CONFIGURATION_ONLY

Especifica que a réplica primária confirma de forma síncrona os metadados de configuração do grupo de disponibilidade para o master banco de dados nesta réplica. A réplica não contém dados do usuário. Essa opção:

Pode ser hospedada em qualquer edição do SQL Server, inclusive a Express Edition.
Requer que o ponto de extremidade de espelhamento de dados da CONFIGURATION_ONLY réplica seja digitado WITNESS.
Não pode ser alterado.
Não é válido quando CLUSTER_TYPE = WSFC.

Para obter mais informações, confira Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

AVAILABILITY_MODE é necessário na ADD REPLICA ON cláusula e opcional na MODIFY REPLICA ON cláusula. Para obter mais informações, consulte Diferenças entre os modos de disponibilidade de um grupo de disponibilidade AlwaysOn.

FAILOVER_MODE = { AUTOMÁTICO | MANUAL }

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

AUTOMÁTICO

Permite o failover automático. AUTOMATIC só terá suporte se você também especificar AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Você pode especificar AUTOMATIC três réplicas de disponibilidade, incluindo a réplica primária.

Observação

Antes do SQL Server 2016 (13.x), você está limitado a duas réplicas de failover automático, incluindo a réplica primária.
As FCIs (Instâncias de Cluster de Failover) do SQL Server não dão suporte ao failover automático por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade que um host FCI só pode ser configurada para failover manual.

MANUAL

Habilita o failover manual ou o failover manual forçado (failover forçado) pelo administrador de banco de dados.

Você deve especificar FAILOVER_MODE na ADD REPLICA ON cláusula. Opcionalmente, você pode especificá-lo na MODIFY REPLICA ON cláusula. Existem dois tipos de failover manual: failover manual sem perda de dados e failover forçado (com possível perda de dados). Condições diferentes dão suporte a esses tipos. Para obter mais informações, confira Failover e modos de failover (grupos de disponibilidade Always On).

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

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

AUTOMÁTICO

Habilita a propagação direta. Esse método propaga a réplica 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 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 nesta réplica em relação às outras réplicas no mesmo grupo de disponibilidade. O valor é um número inteiro no intervalo de 0..100. Esses valores têm estes 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 = 1a réplica de disponibilidade for 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 nunca é escolhida para executar backups. Essa opção é útil, por exemplo, para uma réplica de disponibilidade remota à qual você nunca deseja que os backups façam failover.

Para mais informações, confira Descarregar backups com suporte em réplicas secundárias de um grupo de disponibilidade.

SECONDARY_ROLE ( ... )

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

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

ALLOW_CONNECTIONS = { NÃO | READ_ONLY | ALL }

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

Não

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

SOMENTE_LEITURA

Somente conexões são permitidas para 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 Using Connection String Keywords with SQL Server Native Client.

TODOS

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

Para obter mais informações, consulte Descarregar carga de trabalho somente leitura para a réplica secundária de um grupo de disponibilidade Always On.

READ_ONLY_ROUTING_URL = { 'TCP:// system-address:port' | NONE }

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

A partir do SQL Server 2025 (17.x), você pode especificar NONE como READ_ONLY_ROUTING_URL destino reverter o roteamento somente leitura especificado para a réplica de disponibilidade e rotear o tráfego com base no comportamento padrão.

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

Para obter mais informações de como calcular a URL de roteamento somente leitura de uma réplica de disponibilidade, confira Calculating read_only_routing_url for Always On (Calculando a read_only_routing_url para Always On).

Observação

Para uma instância nomeada do SQL Server, configure o ouvinte Transact-SQL para usar uma porta específica. Para obter mais informações, consulte Configurar o SQL Server para escutar em uma porta TCP específica.

PRIMARY_ROLE ( ... )

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

As opções de função primária 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 primária (atuando como uma réplica primária) podem aceitar de clientes, um dos seguintes:

LEITURA/ESCRITA

As conexões em que a propriedade de conexão Application Intent está definida ReadOnly não são permitidas. Quando a propriedade Intenção de Aplicativo é definida ReadWrite ou a propriedade de conexão de Intenção de Aplicativo não é definida, a conexão é permitida. Para obter mais informações sobre a propriedade de conexão Tentativa de Aplicativo, consulte Using Connection String Keywords with SQL Server Native Client.

TODOS

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

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ... n ] ) | NONE }

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

Seja configurado para permitir todas as conexões ou conexões somente leitura (consulte o ALLOW_CONNECTIONS argumento da opção SECONDARY_ROLE , anteriormente neste artigo).
Tenha sua URL de roteamento somente leitura definida (consulte o READ_ONLY_ROUTING_URL argumento da opção SECONDARY_ROLE , anteriormente neste artigo).

Os READ_ONLY_ROUTING_LIST valores são os seguintes:

<server_instance>

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

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

Começando com o SQL Server 2016 (13.x), você pode balancear a carga de solicitações de tentativa de leitura entre réplicas secundárias legíveis. Especifique isso colocando 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.

Nenhuma

Especifica que, quando essa réplica de disponibilidade for a réplica primária, não haverá suporte para roteamento somente leitura. Esse é o comportamento padrão. Quando usado com MODIFY REPLICA ON, esse valor desabilita uma lista existente, se houver.

{ READ_WRITE_ROUTING_URL = 'TCP:// system-address:port' | NONE }

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

Especifica instâncias de servidor que hospedam réplicas para este grupo de disponibilidade que atendem aos seguintes requisitos ao serem executadas na função primária:

A especificação PRIMARY_ROLE da réplica inclui READ_WRITE_ROUTING_URL.
A cadeia de conexão é ReadWrite ao definir ApplicationIntent como ReadWrite ou ao não definir ApplicationIntent e permitir que o padrão (ReadWrite) tenha efeito.

A partir do SQL Server 2025 (17.x), você pode especificar NONE como READ_WRITE_ROUTING_URL destino reverter o roteamento de leitura-escrita especificado para a réplica de disponibilidade e rotear o tráfego com base no comportamento padrão.

Confira mais informações em Redirecionamento de conexão leitura/gravação de réplica secundária para primária (Grupos de Disponibilidade Always On).

SESSION_TIMEOUT = segundos

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

Importante

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 O que é um grupo de disponibilidade AlwaysOn?

MODIFICAR A RÉPLICA EM

Modifica qualquer uma das réplicas do grupo de disponibilidade. A lista de réplicas a serem modificadas contém o endereço da instância do servidor e uma WITH (...) cláusula para cada réplica.

Com suporte apenas na réplica principal.

REMOVER RÉPLICA EM

Remove a réplica secundária especificada do grupo de disponibilidade. Você não pode remover a réplica primária atual de um grupo de disponibilidade. Quando você remove uma réplica, ela para de receber dados. Os bancos de dados secundários da réplica são removidos do grupo de disponibilidade e entram no RESTORING estado.

Com suporte apenas na réplica principal.

Observação

Se você remover uma réplica enquanto ela estiver indisponível ou com falha, quando ela voltar a ficar online, ela descobrirá que ela não pertence mais ao grupo de disponibilidade.

ENTRAR

Faz com que a instância de servidor local hospede a réplica secundária no grupo de disponibilidade.

Com suporte apenas em uma réplica secundária que ainda não está ingressada no grupo de disponibilidade.

Para obter mais informações, consulte Ingressar uma réplica secundária em um grupo de disponibilidade Always On.

FAILOVER

Inicia um failover manual do grupo de disponibilidade sem perda de dados para a réplica secundária à qual você está conectado. A réplica que hospeda a réplica primária é o destino de failover. O destino de failover assume a função primária e recupera sua cópia de cada banco de dados, colocando-os online como os novos bancos de dados primários. A réplica principal antiga faz a transição concorrente para a função secundária, seus bancos de dados se tornam bancos de dados secundários e são imediatamente suspensos. Potencialmente, essas funções podem alternar para frente e para trás por uma série de falhas.

O failover só tem suporte para uma réplica secundária de confirmação síncrona que está sincronizada com a réplica primária no momento. Para que uma réplica secundária seja sincronizada, a réplica primária também deve estar em execução no modo de confirmação síncrona.

Para duas instâncias do SQL Server em um grupo de disponibilidade, você pode emitir o comando de failover na réplica primária ou secundária. Para instâncias replicadas por meio do link instância gerenciada, você deve emitir o comando de failover na réplica primária.

Observação

Para um grupo de disponibilidade, um comando de failover retorna assim que o destino de failover aceita o comando. No entanto, a recuperação do banco de dados ocorre de forma assíncrona após o término do failover do grupo de disponibilidade.
Para um failover de link da Instância Gerenciada, o comando de failover retorna após um failover bem-sucedido em que as funções de origem e de opção de destino ou se o comando de failover falhar após a falha nas verificações de pré-condição de failover.
Você não pode usar o comando de failover para um failover planejado de um grupo de disponibilidade distribuído entre duas instâncias do SQL Server.

Para obter informações sobre as limitações, os pré-requisitos e as recomendações para executar um failover manual planejado, consulte Executar um failover manual planejado de um grupo de disponibilidade Always On (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Cuidado

Inicie apenas um failover forçado como uma medida de recuperação de desastre, pois pode resultar em perda de dados. O failover de força deve ser executado somente quando a réplica primária não estiver disponível, você estiver preparado para aceitar uma possível perda de dados e deve restaurar o serviço para o grupo de disponibilidade imediatamente.

Com suporte apenas em uma réplica cuja função está no estado ou RESOLVING no SECONDARY estado. A réplica na qual você insere um comando de failover é o destino de failover.

Força o failover do grupo de disponibilidade, com possível perda de dados, para o destino de failover. O destino de failover assume a função primária e recupera sua cópia de cada banco de dados, colocando-os online como os novos bancos de dados primários. Em qualquer réplica secundária restante, todo banco de dados secundário ficará suspenso até que seja retomado manualmente. Quando a réplica primária anterior fica disponível, ela alterna para a função secundária e seus bancos de dados se tornam bancos de dados secundários suspensos.

Para instâncias replicadas por meio do link instância gerenciada, você deve emitir o FORCE_FAILOVER_ALLOW_DATA_LOSS comando na réplica secundária (o destino de failover).

Observação

Um comando de failover retorna assim que o destino de failover aceita o comando. No entanto, a recuperação do banco de dados ocorre de forma assíncrona após o término do failover do grupo de disponibilidade.

Para obter informações sobre as limitações, os pré-requisitos e as recomendações para forçar o failover e o efeito de um failover forçado nos bancos de dados primários anteriores no grupo de disponibilidade, consulte Executar um failover manual forçado de um grupo de disponibilidade Always On (SQL Server).

ADICIONAR O OUVINTE 'dns_name' ( <add_listener_option> )

Define um novo ouvinte de grupo de disponibilidade para esse grupo de disponibilidade. Com suporte apenas na réplica principal.

Importante

Antes de criar seu primeiro ouvinte, leia Configurar um ouvinte para um grupo de disponibilidade Always On.

Depois de criar um ouvinte para um determinado grupo de disponibilidade, execute as seguintes etapas:

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

dns_name

Especifica o nome de host DNS do ouvinte de 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 somente caracteres alfanuméricos, traços (-) e hífens (_), em qualquer ordem. Os nomes de host DNS diferenciam maiúsculas de minúsculas. O tamanho máximo é de 63 caracteres.

Especifique uma cadeia de caracteres significativa. Por exemplo, para um grupo de disponibilidade denominado AG1, um nome de host de DNS significativo seria ag1-listener.

Importante

O NetBIOS reconhece apenas os primeiros 15 caracteres no dns_name. Se você tiver dois clusters WSFC controlados pelo mesmo Active 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, você receberá um relatório de erro informando que o recurso Nome da Rede Virtual não pôde ser colocado online. Para obter informações sobre regras da nomenclatura de prefixos para nomes DNS, consulte Atribuindo nomes de domínio.

INGRESSAR NO GRUPO DE DISPONIBILIDADE EM

Une a um grupo de disponibilidade distribuído. Quando você cria um grupo de disponibilidade distribuído, o grupo de disponibilidade no cluster em que você o cria é o grupo de disponibilidade primário. O grupo de disponibilidade que se une ao grupo de disponibilidade distribuído é o grupo de disponibilidade secundário.

<ag_name>

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

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

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

A LISTENER cláusula é necessária.

'TCP:// system-address:port'

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

system-address

Uma cadeia de caracteres, como um nome de sistema, um nome de domínio totalmente qualificado ou um endereço IP, que identifica sem ambiguidade o ouvinte.

porta

Um número de porta associado ao ponto de extremidade de espelhamento do grupo de disponibilidade. Esta não é a porta do ouvinte.

MODO_DE_DISPONIBILIDADE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Especifica se a réplica primária aguarda o grupo de disponibilidade secundário reconhecer 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.

SYNCHRONOUS_COMMIT

Especifica que a réplica primária aguarda para confirmar transações até receber a confirmação de que as transações são protegidas no grupo de disponibilidade secundário. Você pode especificar SYNCHRONOUS_COMMIT para até dois grupos de disponibilidade, incluindo o grupo de disponibilidade primário.

ASYNCHRONOUS_COMMIT

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

A AVAILABILITY_MODE cláusula é necessária.

FAILOVER_MODE = { MANUAL }

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

MANUAL

Habilita o failover manual planejado ou o failover manual forçado (em geral, chamado failover forçado) pelo administrador de banco de dados.

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

Habilita a propagação automática. Esse método propaga o grupo de disponibilidade secundário 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. Esse método exige que você crie um backup do banco de dados na réplica primária e restaure manualmente esse backup nas réplicas do grupo de disponibilidade secundário.

MODIFICAR O GRUPO DE DISPONIBILIDADE EM

Modifica as configurações do grupo de disponibilidade para um grupo de disponibilidade distribuído. A lista de grupos de disponibilidade a serem modificados contém o nome do grupo de disponibilidade e uma WITH (...) cláusula para cada grupo de disponibilidade.

Importante

Você deve executar esse comando nas instâncias do grupo de disponibilidade primário e do grupo de disponibilidade secundário.

GRANT CRIAR QUALQUER BANCO DE DADOS

Permite que o grupo de disponibilidade crie bancos de dados em nome da réplica primária, que dá suporte à propagação direta (SEEDING_MODE = AUTOMATIC). Execute esse parâmetro em todas as réplicas secundárias que dão suporte à propagação direta depois que esse secundário ingressar no grupo de disponibilidade. Requer a permissão CREATE ANY DATABASE.

NEGAR CRIAR QUALQUER BANCO DE DADOS

Remove do grupo de disponibilidade a capacidade de criar bancos de dados em nome da réplica primária.

<add_listener_option>

ADD LISTENER usa uma das seguintes opções:

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

Especifica que o ouvinte do grupo de disponibilidade usa o protocolo DHCP. Opcionalmente, use a ON cláusula 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 de disponibilidade no grupo de disponibilidade.

Importante

Não use DHCP em um ambiente de produção. Se houver tempo de inatividade e a concessão de IP DHCP expirar, será necessário tempo extra para registrar o novo endereço IP de 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 as 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')

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

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 exige um endereço IP estático na configuração de ouvinte. Para determinada sub-rede, o endereço IP estático pode ser um endereço IPv4 ou um endereço IPv6. Contate o administrador de rede para obter um endereço IP estático para cada sub-rede que hospeda uma réplica de disponibilidade para o novo grupo de disponibilidade.

Por exemplo:

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

ipv4_address

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

ipv4_mask

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

ipv6_address

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

PORTA = listener_port

O número da porta (listener_port) a ser usado por um ouvinte de grupo de disponibilidade especificado pela WITH IP cláusula. PORT é opcional.

Há suporte para o número 1433da porta padrão. No entanto, você pode escolher um número de porta diferente.

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

MODIFICAR O OUVINTE 'dns_name' ( <modify_listener_option> )

Modifica um ouvinte de grupo de disponibilidade existente para esse grupo de disponibilidade. Com suporte apenas na réplica principal.

<modify_listener_option>

MODIFY LISTENER usa uma das seguintes opções:

ADICIONAR IP { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') }

Adiciona o endereço IP especificado ao ouvinte do grupo de disponibilidade especificado por dns_name.

PORTA = listener_port

Veja a descrição desse argumento anteriormente nesta seção.

REMOVER IP { ('four_part_ipv4_address') | ('ipv6_address') }

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

Remove o endereço IP especificado do ouvinte do grupo de disponibilidade especificado.

REINICIAR O OUVINTE 'dns_name'

Reinicia o ouvinte associado ao nome DNS especificado. Com suporte apenas na réplica principal.

REMOVER O OUVINTE 'dns_name'

Remove o ouvinte associado ao nome DNS especificado. Com suporte apenas na réplica principal.

Offline

Leva um grupo de disponibilidade online a se tornar offline Não há perda de dados para bancos de dados de confirmação síncrona.

Quando um grupo de disponibilidade fica offline, seus bancos de dados ficam indisponíveis para clientes e você não pode colocar o grupo de disponibilidade novamente online. Portanto, use a opção OFFLINE somente durante uma migração entre clusters de grupos de disponibilidade Always On, quando estiver migrando recursos do grupo de disponibilidade para um novo cluster WSFC.

Para obter mais informações, confira Colocar um grupo de disponibilidade offline (SQL Server).

Pré-requisitos e restrições

Para obter informações sobre pré-requisitos e restrições em réplicas de disponibilidade e em suas instâncias de servidor host e computadores, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.

Para obter informações sobre restrições AVAILABILITY GROUP nas instruções Transact-SQL, consulte Transact-SQL instruções para grupos de disponibilidade Always On.

Permissões

Você precisa de ALTER AVAILABILITY GROUP permissão no grupo de disponibilidade, CONTROL AVAILABILITY GROUP permissão, ALTER ANY AVAILABILITY GROUP permissão ou CONTROL SERVER permissão. Você também precisa de ALTER ANY DATABASE permissão.

Exemplos

a. Unir uma réplica secundária a um grupo de disponibilidade

O exemplo a seguir une uma réplica secundária à qual você está conectado ao grupo de disponibilidade AccountsAG.

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B. Forçar o failover de um grupo de disponibilidade

O exemplo a seguir força o grupo de disponibilidade AccountsAG a fazer failover para a réplica secundária à qual você está conectado.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

C. Forçar a criptografia em conexões com o grupo de disponibilidade

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

Se o nome do servidor aparecer em cada certificado conforme definido por qualquer método, você poderá omitir a opção HostNameInCertificate :

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

Se você seguiu o método 1 , mas não listou o nome do servidor como um Nome Alternativo da Entidade no certificado, deverá especificar o valor que aparece no Nome Alternativo da Entidade na opção HostNameInCertificate :

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

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

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

Comentários

Esta página foi útil?

Last updated on 2026-01-06

Compartilhar via

ALTERAR GRUPO DE DISPONIBILIDADE (Transact-SQL)

Sintaxe

Argumentos

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECUNDÁRIO | NONE }

PRIMÁRIO

SECONDARY_ONLY

SECUNDÁRIO

Nenhuma

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

HEALTH_CHECK_TIMEOUT = Milissegundos

DB_FAILOVER = { ON | DESLIGADO }

DTC_SUPPORT = { PER_DB | NENHUM }

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

FUNÇÃO

CLUSTER_CONNECTION_OPTIONS

ADICIONAR database_name DE BANCO DE DADOS

REMOVER database_name DO BANCO DE DADOS

ADICIONAR RÉPLICA EM

<server_instance>

system_name

FCI_network_name

instance_name

\

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

'TCP:// system-address:port'

system-address

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 | ALL }

Não

SOMENTE_LEITURA

TODOS

READ_ONLY_ROUTING_URL = { '*TCP:// system-address:*port' | NONE }

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | TODOS }

LEITURA/ESCRITA

TODOS

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ... n ] ) | NONE }

<server_instance>

Nenhuma

{ READ_WRITE_ROUTING_URL = '*TCP:// system-address:*port' | NONE }

SESSION_TIMEOUT = segundos

MODIFICAR A RÉPLICA EM

REMOVER RÉPLICA EM

ENTRAR

FAILOVER

FORCE_FAILOVER_ALLOW_DATA_LOSS

ADICIONAR O OUVINTE 'dns_name' ( <add_listener_option> )

dns_name

INGRESSAR NO GRUPO DE DISPONIBILIDADE EM

<ag_name>

LISTENER = '*TCP:// system-address:*port'

'*TCP:// system-address:*port'

system-address

porta

MODO_DE_DISPONIBILIDADE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUAL }

MANUAL

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

MODIFICAR O GRUPO DE DISPONIBILIDADE EM

GRANT CRIAR QUALQUER BANCO DE DADOS

NEGAR CRIAR QUALQUER BANCO DE DADOS

<add_listener_option>

`HEALTH_CHECK_TIMEOUT` = Milissegundos

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

READ_ONLY_ROUTING_URL = { 'TCP:// system-address:port' | NONE }

{ READ_WRITE_ROUTING_URL = 'TCP:// system-address:port' | NONE }

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

'TCP:// system-address:port'