Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL Server
Altera um grupo de disponibilidade Always On existente no SQL Server. A maioria dos argumentos ALTER AVAILABILITY GROUP é suportada apenas na réplica primária atual. No entanto, os argumentos JOIN, FAILOVER e FORCE_FAILOVER_ALLOW_DATA_LOSS são suportados apenas em réplicas secundárias.
Transact-SQL convenções de sintaxe
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 = { 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.
Suportado apenas na réplica primária.
Os valores 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. Esta função sempre retornará 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 acionarão 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.
Suportado apenas na 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 15000 milissegundos (15 segundos) e o valor máximo é de 4.294.967.295 milissegundos.
Suportado apenas na réplica primária.
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 }
Especifica se as transações distribuídas estão habilitadas para este Grupo de Disponibilidade. As transações distribuídas só têm suporte para bancos de dados de grupo de disponibilidade a partir do SQL Server 2016 (13.x) e as transações entre bancos de dados só são suportadas a partir do SQL Server 2016 (13.x) SP2.
PER_DB cria o grupo de disponibilidade com suporte para essas transações e promoverá 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 um 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 entre bancos de dados e transações distribuídas para grupos de disponibilidade Always On e espelhamento de banco de dados (SQL Server).
Observação
O suporte para alterar a configuração de DTC_SUPPORT de um Grupo de Disponibilidade foi introduzido no SQL Server 2016 (13.x) Service Pack 2. Esta 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 SOLTAR e CRIAR o grupo de disponibilidade novamente.
Importante
O DTC tem um limite de 32 alistamentos por transação distribuída. Como cada banco de dados dentro de um grupo de disponibilidade se alista com o DTC separadamente, se sua transação envolver mais de 32 bancos de dados, você poderá obter 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 Distributed transactions
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.
A partir do SQL Server 2022 (16.x), você pode definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT em um grupo de disponibilidade distribuído. Esta definição não é suportada para 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ÇÕES
O único parâmetro válido é 'SECONDARY', e esta opção SET só é válida em Grupos de Disponibilidade Distribuída. Ele é usado para fazer failover de um grupo de disponibilidade distribuído, conforme documentado aqui: ALTER AVAILABILITY GROUP
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 reverter para a criptografia padrão, defina a CLUSTER_CONNECTION_OPTIONS cláusula como uma cadeia de caracteres vazia. O SQL Server 2025 (17.x) tem por defeito , Encrypt=Mandatorye TrustServerCertificate=Yes para ligações a réplicas de grupos de disponibilidade e ouvintes.
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 | Description |
|---|---|---|
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 HostNameInCertificateo , 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. |
CLUSTER_CONNECTION_OPTIONS |
String vazia ('') |
Limpa a configuração existente e reverte para as configurações de criptografia padrão de Encrypt=Mandatory e TrustServerCertificate=Yes. |
Confira 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 de usuário que você deseja adicionar ao grupo de disponibilidade. Esses bancos de dados devem residir na instância do SQL Server que hospeda a réplica primária atual. 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.
Suportado apenas na réplica primária.
Observação
Depois de criar o grupo de disponibilidade, você precisará se conectar a cada instância do servidor que hospeda uma réplica secundária e, em seguida, preparar cada banco de dados secundário e associá-lo 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).
REMOVER database_name BANCO DE DADOS
Remove o banco de dados primário especificado e os bancos de dados secundários correspondentes do grupo de disponibilidade. Suportado apenas na réplica primária.
Para obter informações sobre as etapas recomendadas após a remoção de um banco de dados de disponibilidade de um grupo de disponibilidade, consulte Remover um banco de dados primário de um grupo de disponibilidade (SQL Server).
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 cláusula WITH (...).
Suportado apenas na réplica primária.
Você precisa unir cada nova réplica secundária 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 instância de cluster de failover (FCI). A sintaxe é a seguinte:
{ '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 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 executando SELECT @@SERVERNAME.
\
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://endereço do sistema: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 hospedará a réplica de disponibilidade que você está adicionando ou modificando.
ENDPOINT_URL é obrigatório na cláusula ADD REPLICA ON e opcional na cláusula MODIFY REPLICA ON. 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:
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 sistema do computador de destino.
porto
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 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.
SYNCHRONOUS_COMMIT
Especifica que a réplica primária aguardará 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.Para obter mais informações, consulte Réplica somente de configuração.
AVAILABILITY_MODE é obrigatório na cláusula ADD REPLICA ON e opcional na cláusula MODIFY REPLICA ON. 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. AUTOMATIC é suportado somente se você também especificar AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Você pode especificar AUTOMATIC para três réplicas de disponibilidade, incluindo a réplica primária.
Observação
- Antes do SQL Server 2016, você estava limitado a duas réplicas automáticas de failover, incluindo a réplica primária.
- 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 failover manual ou failover manual forçado (failover forçado) pelo administrador do banco de dados.
FAILOVER_MODE é obrigatório na cláusula ADD REPLICA ON e opcional na cláusula MODIFY REPLICA ON. Existem dois tipos de failover manual, failover manual sem perda de dados e failover forçado (com possível perda de dados), que 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 será inicialmente propagada.
AUTOMÁTICO
Permite a semeadura direta. Esse método semeará a réplica secundária pela rede. Esse método não requer backup e restauração de 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 nunca será escolhida para 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 Ative Secondaries: Backup on Secondary Replicas (Always On Availability Groups).
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' | NENHUM
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 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), pode especificar NONE como READ_ONLY_ROUTING_URL destino reverter o encaminhamento apenas de leitura especificado para a réplica de disponibilidade, e encaminhar o tráfego com base no comportamento padrão.
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 de disponibilidade, consulte Calculando read_only_routing_url para Always 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, acima).
Ter sua URL de roteamento somente leitura definida (consulte o argumento READ_ONLY_ROUTING_URL da opção SECONDARY_ROLE, acima).
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 de disponibilidade 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 seguirá 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 for a réplica primária, o roteamento somente leitura não será suportado. Este é 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' | NENHUM
Aplica-se a: SQL Server 2019 (15.x) e versões posteriores
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.
A partir do SQL Server 2025 (17.x), pode especificar NONE como READ_WRITE_ROUTING_URL destino reverter o encaminhamento de leitura-escrita especificado para a réplica de disponibilidade e encaminhar o tráfego com base no comportamento predefinido.
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 = segundos
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).
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 cláusula WITH (...) para cada réplica.
Suportado apenas na réplica primária.
REMOVER RÉPLICA EM
Remove a réplica secundária especificada do grupo de disponibilidade. A réplica primária atual não pode ser removida de um grupo de disponibilidade. Ao ser removida, a réplica para de receber dados. Seus bancos de dados secundários são removidos do grupo de disponibilidade e entram no estado RESTORE.
Suportado apenas na réplica primária.
Observação
Se você remover uma réplica enquanto ela estiver indisponível ou falhar, quando ela voltar a ficar online, descobrirá que ela não pertence mais ao grupo de disponibilidade.
ADERIR
Faz com que a instância do servidor local hospede uma réplica secundária no grupo de disponibilidade especificado.
Suportado apenas em uma réplica secundária que ainda não foi associada ao grupo de disponibilidade.
Para obter mais informações, consulte associar uma réplica secundária a um grupo de disponibilidade (SQL Server).
ATIVAÇÃO PÓS-FALHA
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 hospedará a réplica primária é o destino de failover . O destino de failover assumirá a função principal e recuperará sua cópia de cada banco de dados e os colocará online como os novos bancos de dados primários. A réplica primária anterior transita simultaneamente para a função secundária e seus bancos de dados se tornam bancos de dados secundários e são imediatamente suspensos. Potencialmente, esses papéis podem ser alternados de um lado para o outro por uma série de falhas.
O failover só é suportado para uma réplica secundária de confirmação síncrona que esteja atualmente sincronizada com a réplica primária. 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 failover na réplica primária ou secundária. Para instâncias replicadas por meio do link Instância Gerenciada, o comando failover deve ser emitido 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 failover do grupo de disponibilidade.
- Para um failover de link de Instância Gerenciada, o comando failover retorna após um failover bem-sucedido em que a origem e o destino trocaram de função, ou se o comando failover falhar depois que as verificações de pré-condição de failover falharem.
- O comando failover não pode ser usado 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, pré-requisitos e recomendações para executar um failover manual planejado, consulte Executar um failover manual planejado de um grupo de disponibilidade (SQL Server).
FORCE_FAILOVER_ALLOW_DATA_LOSS
Atenção
Forçar o failover, que pode envolver alguma perda de dados, é estritamente um método de recuperação de desastres. Portanto, é altamente recomendável que você force o failover somente se a réplica primária não estiver mais em execução, se estiver disposto a correr o risco de perder dados e se tiver que restaurar o serviço para o grupo de disponibilidade imediatamente.
Suportado apenas em uma réplica cuja função está no estado SECUNDÁRIO ou RESOLVENDO. --A réplica na qual você insere um comando de failover é conhecida como 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 assumirá a função principal e recuperará sua cópia de cada banco de dados e os colocará online como os novos bancos de dados primários. Em todas as réplicas secundárias restantes, cada banco de dados secundário é suspenso até ser retomado manualmente. Quando a réplica primária anterior estiver disponível, ela alternará para a função secundária e seus bancos de dados se tornarão bancos de dados secundários suspensos.
Para instâncias replicadas por meio do link Instância Gerenciada, o FORCE_FAILOVER_ALLOW_DATA_LOSS comando deve ser emitido na réplica secundária (o destino de failover).
Observação
Um comando 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 failover do grupo de disponibilidade.
Para obter informações sobre as limitações, pré-requisitos e recomendações para forçar 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 (SQL Server).
ADICIONAR OUVINTE 'dns_name'( <add_listener_option> )
Define um novo ouvinte do grupo de disponibilidade para esse grupo de disponibilidade. Suportado apenas na réplica primária.
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, receberá um erro informando 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.
JUNTE-SE AO GRUPO DE DISPONIBILIDADE EM
Junta-se a um grupo de disponibilidade distribuída . Quando você cria um grupo de disponibilidade distribuído, o grupo de disponibilidade no cluster onde ele é criado é o grupo de disponibilidade principal. O grupo de disponibilidade que se junta ao grupo de disponibilidade distribuída é o grupo de disponibilidade secundário.
<ag_name>
Especifica o nome do grupo de disponibilidade que compõe metade do grupo de disponibilidade distribuída.
LISTENER = 'TCP://endereço do sistema:port'
Especifica o caminho da URL para o ouvinte associado ao grupo de disponibilidade.
A cláusula LISTENER é 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 }
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 aguardará 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.
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 será inicialmente propagado.
AUTOMÁTICO
Permite a propagação automática. Este método semeará o grupo de disponibilidade secundário através da 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 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.
MODIFICAR O GRUPO DE DISPONIBILIDADE EM
Modifica qualquer uma das configurações do grupo de disponibilidade de 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 cláusula WITH (...) para cada grupo de disponibilidade.
Importante
Esse comando deve ser repetido nas instâncias do grupo de disponibilidade primária e secundária.
CONCEDER A CRIAÇÃO DE QUALQUER BANCO DE DADOS
Permite que o grupo de disponibilidade crie bancos de dados em nome da réplica primária, que oferece suporte à propagação direta (SEEDING_MODE = AUTOMÁTICA). Esse parâmetro deve ser executado em cada réplica secundária que ofereça suporte à propagação direta depois que a secundária ingressar no grupo de disponibilidade. Requer a permissão CREATE ANY DATABASE.
NEGAR A CRIAÇÃO DE QUALQUER BANCO DE DADOS
Remove a capacidade do grupo de disponibilidade 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 [ EM { ('four_part_ipv4_address'',four_part_ipv4_mask') } ]
Especifica que o ouvinte do grupo de disponibilidade usará o protocolo DHCP (Dynamic Host Configuration Protocol). Opcionalmente, use a cláusula ON para identificar a rede na qual esse ouvinte será 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 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 usará 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 hospedará 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
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
MODIFICAR OUVINTE 'dns_name'( <modify_listener_option> )
Modifica um ouvinte de grupo de disponibilidade existente para esse grupo de disponibilidade. Suportado apenas na réplica primária.
<modify_listener_option>
MODIFY LISTENER usa uma das seguintes opções:
ADD IP { ('four_part_ipv4_address'',four_part_ipv4_mask') | ('dns_nameipv6_address__')__ }
Adiciona o endereço IP especificado ao ouvinte do grupo de disponibilidade especificado por dns_name.
PORTA = listener_port
Consulte a descrição deste 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 OUVINTE 'dns_name'
Reinicia o ouvinte associado ao nome DNS especificado. Suportado apenas na réplica primária.
REMOVER OUVINTE 'dns_name'
Remove o ouvinte associado ao nome DNS especificado. Suportado apenas na réplica primária.
Offline
Coloca um grupo de disponibilidade online offline. Não há perda de dados para bancos de dados de confirmação síncrona.
Depois que um grupo de disponibilidade fica offline, seus bancos de dados ficam indisponíveis para os clientes e você não pode colocar o grupo de disponibilidade online novamente. Portanto, use a opção OFFLINE somente durante uma migração entre clusters de grupos de disponibilidade Always On, ao migrar recursos do grupo de disponibilidade para um novo cluster WSFC.
Para obter mais informações, consulte 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 (SQL Server).
Para obter informações sobre restrições nas instruções Transact-SQL AVAILABILITY GROUP, consulte Overview of Transact-SQL Statements for Always On Availability Groups (SQL Server).
Permissões
Requer a permissão ALTER AVAILABILITY GROUP no grupo de disponibilidade, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER. Também requer a permissão ALTER ANY DATABASE.
Exemplos
Um. Associando 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çando 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 criptografia em conexões com o 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:
ALTER 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.
ALTER 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:
ALTER AVAILABILITY GROUP [AccountsAG]
SET (
CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;ServerCertificate=C:\Users\admin\SqlAGCertificate.cer')
Ver também
CRIAR GRUPO DE DISPONIBILIDADE (Transact-SQL)
ALTERAR DATABASE SET HADR (Transact-SQL)
GRUPO DROP AVAILABILITY (Transact-SQL)
sys.availability_replicas (Transact-SQL)
sys.availability_groups (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 de Grupo de Disponibilidade, Conectividade de Cliente e Failover de Aplicativo (SQL Server)