ALTER AVAILABILITY GROUP (Transact-SQL)

Artikel
03/13/2025

van toepassing op:SQL Server-

Wijzigt een bestaande AlwaysOn-beschikbaarheidsgroep in SQL Server. De meeste ARGUMENTEN ALTER AVAILABILITY GROUP worden alleen ondersteund voor de huidige primaire replica. De argumenten JOIN, FAILOVER en FORCE_FAILOVER_ALLOW_DATA_LOSS worden echter alleen ondersteund op secundaire replica's.

Transact-SQL syntaxisconventies

Syntaxis

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

Argumenten

group_name

Hiermee geeft u de naam van de nieuwe beschikbaarheidsgroep. group_name moet een geldige SQL Server-id zijn en moet deze uniek zijn voor alle beschikbaarheidsgroepen in het WSFC-cluster.

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECUNDAIR | GEEN }

Hiermee geeft u een voorkeur over hoe een back-uptaak de primaire replica moet evalueren wanneer u kiest waar back-ups moeten worden uitgevoerd. U kunt een bepaalde back-uptaak uitvoeren om rekening te houden met de automatische back-upvoorkeur. Het is belangrijk om te begrijpen dat de voorkeur niet wordt afgedwongen door SQL Server, dus dit heeft geen invloed op ad-hocback-ups.

Alleen ondersteund op de primaire replica.

De waarden zijn als volgt:

PRIMAIR

Hiermee geeft u op dat de back-ups altijd moeten plaatsvinden op de primaire replica. Deze optie is handig als u back-upfuncties nodig hebt, zoals het maken van differentiële back-ups, die niet worden ondersteund wanneer back-ups worden uitgevoerd op een secundaire replica.

Belangrijk

Als u van plan bent logboekverzending te gebruiken om secundaire databases voor te bereiden voor een beschikbaarheidsgroep, stelt u de automatische back-upvoorkeur in op Primaire totdat alle secundaire databases zijn voorbereid en toegevoegd aan de beschikbaarheidsgroep.

SECONDARY_ONLY

Hiermee geeft u op dat back-ups nooit moeten worden uitgevoerd op de primaire replica. Als de primaire replica de enige onlinereplica is, mag de back-up niet plaatsvinden.

SECUNDAIR

Hiermee geeft u op dat back-ups moeten worden uitgevoerd op een secundaire replica, behalve wanneer de primaire replica de enige replica online is. In dat geval moet de back-up worden uitgevoerd op de primaire replica. Dit is het standaardgedrag.

GEEN

Hiermee geeft u de voorkeur aan dat back-uptaken de rol van de beschikbaarheidsreplica's negeren bij het kiezen van de replica om back-ups uit te voeren. Back-uptaken kunnen andere factoren evalueren, zoals de back-upprioriteit van elke beschikbaarheidsreplica in combinatie met de operationele status en de verbonden status.

Belangrijk

Er is geen afdwinging van de AUTOMATED_BACKUP_PREFERENCE instelling. De interpretatie van deze voorkeur is afhankelijk van de logica, indien van toepassing, die u scriptt in back-taken voor de databases in een bepaalde beschikbaarheidsgroep. De instelling voor automatische back-upvoorkeur heeft geen invloed op ad-hocback-ups. Zie Back-up configureren op beschikbaarheidsreplica's (SQL Server)voor meer informatie.

Notitie

Als u de automatische back-upvoorkeur van een bestaande beschikbaarheidsgroep wilt weergeven, selecteert u de kolom automated_backup_preference of automated_backup_preference_desc van de sys.availability_groups catalogusweergave. Daarnaast kan sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) worden gebruikt om de voorkeursback-upreplica te bepalen. Deze functie retourneert altijd 1 voor ten minste één van de replica's, zelfs wanneer AUTOMATED_BACKUP_PREFERENCE = NONE.

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

Hiermee geeft u op welke foutvoorwaarden een automatische failover voor deze beschikbaarheidsgroep wordt geactiveerd. FAILURE_CONDITION_LEVEL is ingesteld op groepsniveau, maar is alleen relevant voor beschikbaarheidsreplica's die zijn geconfigureerd voor de beschikbaarheidsmodus synchroon doorvoeren (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Bovendien kunnen foutvoorwaarden een automatische failover alleen activeren als zowel de primaire als de secundaire replica's zijn geconfigureerd voor de automatische failovermodus (FAILOVER_MODE = AUTOMATISCH) en de secundaire replica momenteel wordt gesynchroniseerd met de primaire replica.

Alleen ondersteund op de primaire replica.

De foutvoorwaardeniveaus (1-5) variëren van het minst beperkende niveau 1 tot het meest beperkende niveau 5. Een bepaald voorwaardeniveau omvat alle minder beperkende niveaus. Het strengste voorwaardeniveau, 5, omvat dus de vier minder beperkende voorwaardeniveaus (1-4), niveau 4 omvat niveaus 1-3, enzovoort. In de volgende tabel wordt de foutvoorwaarde beschreven die overeenkomt met elk niveau.

Niveau	Foutvoorwaarde
1	Hiermee geeft u op dat een automatische failover moet worden gestart wanneer een van de volgende situaties plaatsvindt: De SQL Server-service is niet beschikbaar. De lease van de beschikbaarheidsgroep voor het maken van verbinding met het WSFC-cluster verloopt omdat er geen ACK van het serverexemplaren wordt ontvangen. Zie How It Works: SQL Server AlwaysOn Lease Timeoutvoor meer informatie.
2	Hiermee geeft u op dat een automatische failover moet worden gestart wanneer een van de volgende situaties plaatsvindt: Het exemplaar van SQL Server maakt geen verbinding met het cluster en de door de gebruiker opgegeven HEALTH_CHECK_TIMEOUT drempelwaarde van de beschikbaarheidsgroep wordt overschreden. De beschikbaarheidsreplica heeft de status Mislukt.
3	Hiermee geeft u op dat een automatische failover moet worden gestart op kritieke interne SQL Server-fouten, zoals zwevende spinlocks, ernstige schendingen van schrijftoegang of te veel dumping. Dit is het standaardgedrag.
4	Hiermee geeft u op dat een automatische failover moet worden gestart op gemiddelde interne SQL Server-fouten, zoals een permanente out-of-memory-voorwaarde in de interne SQL Server-resourcegroep.
5	Hiermee geeft u op dat een automatische failover moet worden gestart op eventuele voorwaarden voor gekwalificeerde fouten, waaronder: Uitputting van SQL Engine-werkthreads. Detectie van een onoplosbare impasse.

Notitie

Gebrek aan reactie door een exemplaar van SQL Server voor clientaanvragen is niet relevant voor beschikbaarheidsgroepen.

De waarden voor FAILURE_CONDITION_LEVEL en HEALTH_CHECK_TIMEOUT definiëren een flexibel failoverbeleid voor een bepaalde groep. Dit flexibele failoverbeleid biedt gedetailleerde controle over welke voorwaarden een automatische failover moeten veroorzaken. Zie Flexibele failoverbeleid voor automatische failover van een beschikbaarheidsgroep (SQL Server)voor meer informatie.

HEALTH_CHECK_TIMEOUT = milliseconden

Hiermee geeft u de wachttijd (in milliseconden) voor de sp_server_diagnostics systeem opgeslagen procedure om serverstatusgegevens te retourneren voordat het WSFC-cluster ervan uitgaat dat het serverexemplaren traag of niet reageert. HEALTH_CHECK_TIMEOUT is ingesteld op groepsniveau, maar is alleen relevant voor beschikbaarheidsreplica's die zijn geconfigureerd voor de synchrone doorvoerbeschikbaarheidsmodus met automatische failover (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Bovendien kan een time-out voor statuscontrole alleen een automatische failover activeren als zowel de primaire als de secundaire replica's zijn geconfigureerd voor de automatische failovermodus (FAILOVER_MODE = AUTOMATISCH) en de secundaire replica momenteel wordt gesynchroniseerd met de primaire replica.

De standaardwaarde HEALTH_CHECK_TIMEOUT is 30000 milliseconden (30 seconden). De minimumwaarde is 15000 milliseconden (15 seconden) en de maximumwaarde is 4.294.967.295 milliseconden.

Alleen ondersteund op de primaire replica.

Belangrijk

sp_server_diagnostics voert geen statuscontroles uit op databaseniveau.

DB_FAILOVER = { ON | UIT }

Hiermee geeft u het antwoord op dat moet worden uitgevoerd wanneer een database op de primaire replica offline is. Wanneer deze instelling is ingesteld op AAN, activeert elke andere status dan ONLINE voor een database in de beschikbaarheidsgroep een automatische failover. Wanneer deze optie is ingesteld op UIT, wordt alleen de status van het exemplaar gebruikt om automatische failover te activeren.

Zie Optie voor statusdetectie op databaseniveau voor meer informatie over deze instelling

DTC_SUPPORT = { PER_DB | GEEN }

Hiermee geeft u op of gedistribueerde transacties zijn ingeschakeld voor deze beschikbaarheidsgroep. Gedistribueerde transacties worden alleen ondersteund voor databases van beschikbaarheidsgroepen vanaf SQL Server 2016 (13.x) en transacties tussen databases worden alleen ondersteund vanaf SQL Server 2016 (13.x) SP2. PER_DB maakt de beschikbaarheidsgroep met ondersteuning voor deze transacties en promoveert automatisch transacties tussen databases in de beschikbaarheidsgroep in gedistribueerde transacties. NONE voorkomt de automatische promotie van transacties tussen databases naar gedistribueerde transacties en registreert de database niet met een stabiele RMID in DTC. Gedistribueerde transacties worden niet voorkomen wanneer de NONE instelling wordt gebruikt, maar databasefailover en automatisch herstel kunnen in sommige omstandigheden niet lukken. Zie Cross-Database Transactions and Distributed Transactions for AlwaysOn Availability Groups and Database Mirroring (SQL Server)voor meer informatie.

Notitie

Ondersteuning voor het wijzigen van de DTC_SUPPORT-instelling van een beschikbaarheidsgroep is geïntroduceerd in SQL Server 2016 (13.x) Service Pack 2. Deze optie kan niet worden gebruikt met eerdere versies. Als u deze instelling in eerdere versies van SQL Server wilt wijzigen, moet u DROP en CREATE de beschikbaarheidsgroep opnieuw maken.

Belangrijk

DTC heeft een limiet van 32 aanmeldgegevens per gedistribueerde transactie. Omdat elke database in een beschikbaarheidsgroep afzonderlijk bij de DTC wordt ingeschreven, kunt u, als uw transactie meer dan 32 databases omvat, de volgende fout krijgen wanneer SQL Server probeert de 33e database in te schakelen:

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.

Zie gedistribueerde transacties voor meer informatie over gedistribueerde transacties in SQL Server

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Geïntroduceerd in SQL Server 2017 (14.x). Hiermee stelt u een minimum aantal synchrone secundaire replica's in die nodig zijn om door te voeren voordat de primaire replica een transactie doorvoert. Garandeert dat SQL Server-transacties wachten totdat de transactielogboeken worden bijgewerkt op het minimale aantal secundaire replica's.

Standaard: 0. Biedt hetzelfde gedrag als SQL Server 2016 (13.x).
Minimum: 0.
Maximum: aantal replica's min 1.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT heeft betrekking op replica's in de synchrone doorvoermodus. Wanneer replica's zich in de synchrone doorvoermodus bevinden, wachten schrijfbewerkingen op de primaire replica totdat schrijfbewerkingen op synchrone replica's worden doorgevoerd in het transactielogboek van de replicadatabase. Als een SQL Server die als host fungeert voor een secundaire synchrone replica niet meer reageert, markeert de SQL Server die als host fungeert voor de primaire replica die secundaire replica als NIET GESYNCHRONISEERD en gaat. Wanneer de niet-reagerende database weer online komt, heeft deze de status 'niet gesynchroniseerd' en wordt de replica gemarkeerd als beschadigd totdat de primaire database deze opnieuw kan synchroniseren. Met deze instelling wordt gegarandeerd dat de primaire replica pas verdergaat als het minimale aantal replica's elke transactie heeft doorgevoerd. Als het minimale aantal replica's niet beschikbaar is, mislukken doorvoeringen op de primaire replica. Voor clustertype EXTERNAL de instelling wordt gewijzigd wanneer de beschikbaarheidsgroep wordt toegevoegd aan een clusterresource. Zie Hoge beschikbaarheid en gegevensbeveiliging voor configuraties van beschikbaarheidsgroepen.

Vanaf SQL Server 2022 (16.x) kunt u REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT instellen voor een gedistribueerde beschikbaarheidsgroep. Deze instelling wordt niet ondersteund voor CREATE AVAILABILITY GROUP. U kunt ALTER AVAILABILITY GROUP gebruiken om REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in te stellen. Bijvoorbeeld:

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

ROL

De enige geldige parameter is SECUNDAIR en deze SET-optie is alleen geldig in gedistribueerde beschikbaarheidsgroepen. Er wordt een failover uitgevoerd voor een gedistribueerde beschikbaarheidsgroep, zoals hier wordt beschreven: ALTER AVAILABILITY GROUP

DATABASE toevoegen database_name

Hiermee geeft u een lijst op van een of meer gebruikersdatabases die u wilt toevoegen aan de beschikbaarheidsgroep. Deze databases moeten zich bevinden op het exemplaar van SQL Server dat als host fungeert voor de huidige primaire replica. U kunt meerdere databases opgeven voor een beschikbaarheidsgroep, maar elke database kan slechts tot één beschikbaarheidsgroep behoren. Zie vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server) voor informatie over het type databases dat een beschikbaarheidsgroep kan ondersteunen. Als u wilt achterhalen welke lokale databases al bij een beschikbaarheidsgroep horen, raadpleegt u de kolom replica_id in de sys.databases catalogusweergave.

Alleen ondersteund op de primaire replica.

Notitie

Nadat u de beschikbaarheidsgroep hebt gemaakt, moet u verbinding maken met elk serverexemplaren dat als host fungeert voor een secundaire replica en vervolgens elke secundaire database voorbereiden en deze toevoegen aan de beschikbaarheidsgroep. Zie Gegevensverplaatsing starten op een AlwaysOn Secondary Database (SQL Server)voor meer informatie.

DATABASE verwijderen database_name

Hiermee verwijdert u de opgegeven primaire database en de bijbehorende secundaire databases uit de beschikbaarheidsgroep. Alleen ondersteund op de primaire replica.

Zie Een primaire database verwijderen uit een SQL Server-voor meer informatie over aanbevolen stappen na het verwijderen van een beschikbaarheidsdatabase uit een beschikbaarheidsgroep.

REPLICA TOEVOEGEN AAN

Hiermee geeft u op van één tot acht SQL Server-exemplaren voor het hosten van secundaire replica's in een beschikbaarheidsgroep. Elke replica wordt opgegeven door het adres van het serverexemplaren, gevolgd door een WITH (...)-component.

Alleen ondersteund op de primaire replica.

U moet elke nieuwe secundaire replica toevoegen aan de beschikbaarheidsgroep. Zie de beschrijving van de join-optie verderop in deze sectie voor meer informatie.

<server_instance>

Hiermee geeft u het adres op van het exemplaar van SQL Server dat de host voor een replica is. De adresindeling is afhankelijk van of het exemplaar het standaardexemplaar of een benoemd exemplaar is en of het een zelfstandig exemplaar of een failoverclusterexemplaar (FCI) is. De syntaxis is als volgt:

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

De onderdelen van dit adres zijn als volgt:

system_name

De NetBIOS-naam van het computersysteem waarop het doelexemplaren van SQL Server zich bevinden. Deze computer moet een WSFC-knooppunt zijn.

FCI_network_name

De netwerknaam die wordt gebruikt voor toegang tot een SQL Server-failovercluster. Gebruik dit als het serverexemplaren deelneemt als een SQL Server-failoverpartner. Het uitvoeren van SELECT-@@SERVERNAME op een FCI-serverexemplaar retourneert de volledige tekenreeks 'FCI_network_name[\instance_name]' (de volledige replicanaam).

instance_name

De naam van een exemplaar van een SQL Server dat wordt gehost door system_name of FCI_network_name en waarvoor AlwaysOn is ingeschakeld. Voor een standaardserverexemplaren is instance_name optioneel. De naam van het exemplaar is niet hoofdlettergevoelig. Op een zelfstandige serverinstantie is deze waardenaam gelijk aan de waarde die wordt geretourneerd door SELECT @@SERVERNAMEuit te voeren.

\

Een scheidingsteken dat alleen wordt gebruikt bij het opgeven van instance_name, om het te scheiden van system_name of FCI_network_name.

Zie vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server)voor informatie over de vereisten voor WSFC-knooppunten en serverinstanties.

ENDPOINT_URL = 'TCP://systeemadres:poort'

Hiermee geeft u het URL-pad op voor het eindpunt voor databasespiegeling op het exemplaar van SQL Server waarop de beschikbaarheidsreplica wordt gehost die u toevoegt of wijzigt.

ENDPOINT_URL is vereist in de component ADD REPLICA ON en optioneel in de component MODIFY REPLICA ON. Zie De eindpunt-URL opgeven bij het toevoegen of wijzigen van een beschikbaarheidsreplica (SQL Server)voor meer informatie.

'TCP://systeemadres:poort'

Hiermee geeft u een URL op voor het opgeven van een eindpunt-URL of alleen-lezen routerings-URL. De URL-parameters zijn als volgt:

systeemadres

Een tekenreeks, zoals een systeemnaam, een volledig gekwalificeerde domeinnaam of een IP-adres, die het doelcomputersysteem ondubbelzinnig identificeert.

poort

Een poortnummer dat is gekoppeld aan het spiegelingseindpunt van het serverexemplaar (voor de optie ENDPOINT_URL) of het poortnummer dat wordt gebruikt door de database-engine van het serverexemplaar (voor de optie READ_ONLY_ROUTING_URL).

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Hiermee geeft u op of de primaire replica moet wachten totdat de secundaire replica de beveiliging (schrijven) van de logboekrecords naar schijf bevestigt voordat de primaire replica de transactie kan doorvoeren op een bepaalde primaire database. De transacties op verschillende databases op dezelfde primaire replica kunnen onafhankelijk worden doorgevoerd.

SYNCHRONOUS_COMMIT

Hiermee geeft u op dat de primaire replica wacht op het doorvoeren van transacties totdat deze zijn gehard op deze secundaire replica (synchrone doorvoermodus). U kunt SYNCHRONOUS_COMMIT opgeven voor maximaal drie replica's, inclusief de primaire replica.

ASYNCHRONOUS_COMMIT

Hiermee geeft u op dat de primaire replica transacties doorvoert zonder te wachten op deze secundaire replica om het logboek te beveiligen (synchrone doorvoerbeschikbaarheidsmodus). U kunt ASYNCHRONOUS_COMMIT opgeven voor maximaal vijf beschikbaarheidsreplica's, inclusief de primaire replica.

CONFIGURATION_ONLY

Hiermee geeft u op dat de configuratiemetagegevens van de primaire replica synchroon doorvoeren naar de hoofddatabase op deze replica. De replica bevat geen gebruikersgegevens. Deze optie:

Kan worden gehost op elke editie van SQL Server, inclusief Express Edition.
Vereist dat het eindpunt voor gegevensspiegeling van de CONFIGURATION_ONLY replica wordt getypt WITNESS.
Kan niet worden gewijzigd.
Is niet geldig wanneer CLUSTER_TYPE = WSFC.

Zie Alleen replica-configureren voor meer informatie.

AVAILABILITY_MODE is vereist in de component ADD REPLICA ON en optioneel in de component MODIFY REPLICA ON. Zie beschikbaarheidsmodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

FAILOVER_MODE = { AUTOMATIC | HANDMATIG }

Hiermee geeft u de failovermodus van de beschikbaarheidsreplica die u definieert.

AUTOMATISCH

Hiermee schakelt u automatische failover in. AUTOMATISCH wordt alleen ondersteund als u ook AVAILABILITY_MODE = SYNCHRONOUS_COMMIT opgeeft. U kunt AUTOMATISCH opgeven voor drie beschikbaarheidsreplica's, inclusief de primaire replica.

Notitie

Vóór SQL Server 2016 was u beperkt tot twee automatische failoverreplica's, waaronder de primaire replica.
SQL Server Failover Cluster Instances (CFA's) bieden geen ondersteuning voor automatische failover per beschikbaarheidsgroep, dus elke beschikbaarheidsreplica die wordt gehost door een FCI kan alleen worden geconfigureerd voor handmatige failover.

HANDMATIG

Hiermee schakelt u handmatige failover of geforceerde handmatige failover (geforceerde failover) in door de databasebeheerder.

FAILOVER_MODE is vereist in de component ADD REPLICA ON en optioneel in de component MODIFY REPLICA ON. Er bestaan twee typen handmatige failover, handmatige failover zonder gegevensverlies en geforceerde failover (met mogelijk gegevensverlies), die onder verschillende omstandigheden worden ondersteund. Zie failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

SEEDING_MODE = { AUTOMATIC | HANDMATIG }

Hiermee geeft u op hoe de secundaire replica in eerste instantie wordt geseed.

AUTOMATISCH

Hiermee schakelt u direct seeding in. Met deze methode wordt de secundaire replica via het netwerk gezaaid. Voor deze methode hoeft u geen back-ups te maken en een kopie van de primaire database op de replica te herstellen.

Notitie

Voor directe seeding moet u het maken van databases op elke secundaire replica toestaan door ALTER AVAILABILITY GROUP aan te roepen met de optie GRANT CREATE ANY DATABASE.

HANDMATIG

Hiermee geeft u handmatig seeding (standaard). Voor deze methode moet u een back-up van de database maken op de primaire replica en die back-up handmatig herstellen op de secundaire replica.

BACKUP_PRIORITY = n

Hiermee geeft u de prioriteit op voor het uitvoeren van back-ups op deze replica ten opzichte van de andere replica's in dezelfde beschikbaarheidsgroep. De waarde is een geheel getal in het bereik van 0,.100. Deze waarden hebben de volgende betekenissen:

1..100 geeft aan dat de beschikbaarheidsreplica kan worden gekozen voor het uitvoeren van back-ups. 1 geeft de laagste prioriteit aan en 100 geeft de hoogste prioriteit aan. Als BACKUP_PRIORITY = 1, wordt de beschikbaarheidsreplica alleen gekozen voor het uitvoeren van back-ups als er momenteel geen beschikbaarheidsreplica's met een hogere prioriteit beschikbaar zijn.
0 geeft aan dat deze beschikbaarheidsreplica nooit wordt gekozen voor het uitvoeren van back-ups. Dit is bijvoorbeeld handig voor een replica van externe beschikbaarheid waarvoor u nooit een failover wilt uitvoeren voor back-ups.

Zie Actieve secundaire databases: Back-up maken op secundaire replica's (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

SECONDARY_ROLE ( ... )

Hiermee geeft u rolspecifieke instellingen op die van kracht worden als deze beschikbaarheidsreplica momenteel eigenaar is van de secundaire rol (dat wil zeggen, wanneer het een secundaire replica is). Geef tussen haakjes een of beide opties voor secundaire rollen op. Als u beide opgeeft, gebruikt u een door komma's gescheiden lijst.

De opties voor secundaire rollen zijn als volgt:

ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }

Hiermee geeft u op of de databases van een bepaalde beschikbaarheidsreplica die de secundaire rol uitvoert (dat wil gezegd, fungeert als een secundaire replica) verbindingen van clients kan accepteren, een van de volgende:

NEE

Er zijn geen gebruikersverbindingen toegestaan voor secundaire databases van deze replica. Ze zijn niet beschikbaar voor leestoegang. Dit is het standaardgedrag.

READ_ONLY

Alleen verbindingen zijn toegestaan voor de databases in de secundaire replica waar de eigenschap Application Intent is ingesteld op ReadOnly-. Zie Trefwoorden voor verbindingsreeksen gebruiken met SQL Server Native Clientvoor meer informatie over deze eigenschap.

ALLE

Alle verbindingen zijn toegestaan voor de databases in de secundaire replica voor alleen-lezentoegang.

Zie Actieve secundaire replica's: leesbare secundaire replica's (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

READ_ONLY_ROUTING_URL = 'TCP://systeemadres:poort'

Hiermee geeft u de URL op die moet worden gebruikt voor het routeren van verbindingsaanvragen voor leesintentie naar deze beschikbaarheidsreplica. Dit is de URL waarop de SQL Server Database Engine luistert. Normaal gesproken luistert het standaardexemplaren van de SQL Server Database Engine op TCP-poort 1433.

Voor een benoemd exemplaar kunt u het poortnummer verkrijgen door een query uit te voeren op de poort- en type_desc kolommen van de sys.dm_tcp_listener_states dynamische beheerweergave. Het serverexemplaren maakt gebruik van de Transact-SQL listener (type_desc='TSQL').

Zie Berekenen van read_only_routing_url voor AlwaysOn-voor meer informatie over het berekenen van de alleen-lezen routerings-URL voor een beschikbaarheidsreplica.

Notitie

Voor een benoemd exemplaar van SQL Server moet de Transact-SQL listener worden geconfigureerd voor het gebruik van een specifieke poort. Zie Een server configureren om te luisteren op een specifieke TCP-poort (SQL Server Configuration Manager)voor meer informatie.

PRIMARY_ROLE ( ... )

Hiermee geeft u rolspecifieke instellingen op die van kracht worden als deze beschikbaarheidsreplica momenteel eigenaar is van de primaire rol (dat wil zeggen, wanneer dit de primaire replica is). Geef tussen haakjes een of beide opties voor primaire rollen op. Als u beide opgeeft, gebruikt u een door komma's gescheiden lijst.

De opties voor primaire rollen zijn als volgt:

ALLOW_CONNECTIONS = { READ_WRITE | ALL }

Hiermee geeft u het type verbinding op dat de databases van een bepaalde beschikbaarheidsreplica die de primaire rol uitvoeren (dat wil gezegd, fungeert als een primaire replica) kan accepteren van clients, een van de volgende:

READ_WRITE

Verbindingen waarbij de eigenschap Verbindingseigenschap Toepassingsintentie is ingesteld op ReadOnly- niet zijn toegestaan. Wanneer de eigenschap Toepassingsintentie is ingesteld op ReadWrite- of de eigenschap Application Intent-verbinding niet is ingesteld, is de verbinding toegestaan. Zie Trefwoorden voor verbindingsreeksen gebruiken met SQL Server Native Clientvoor meer informatie over de verbindingseigen eigenschap van de toepassingsintentie.

ALLE

Alle verbindingen zijn toegestaan voor de databases in de primaire replica. Dit is het standaardgedrag.

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

Hiermee geeft u een door komma's gescheiden lijst met serverexemplaren op die beschikbaarheidsreplica's hosten voor deze beschikbaarheidsgroep die voldoen aan de volgende vereisten bij uitvoering onder de secundaire rol:

Configureer deze optie om alle verbindingen of alleen-lezenverbindingen toe te staan (zie het argument ALLOW_CONNECTIONS van de optie SECONDARY_ROLE hierboven).
Zorg ervoor dat de url voor alleen-lezenroutering is gedefinieerd (zie het READ_ONLY_ROUTING_URL argument van de optie SECONDARY_ROLE hierboven).

De READ_ONLY_ROUTING_LIST waarden zijn als volgt:

<server_instance>

Hiermee geeft u het adres op van het exemplaar van SQL Server dat de host is voor een beschikbaarheidsreplica die een leesbare secundaire replica is wanneer deze wordt uitgevoerd onder de secundaire rol.

Gebruik een door komma's gescheiden lijst om alle serverexemplaren op te geven die een leesbare secundaire replica kunnen hosten. Alleen-lezenroutering volgt de volgorde waarin serverexemplaren worden opgegeven in de lijst. Als u het hostserverexemplaren van een replica opneemt in de lijst met alleen-lezenroutering van de replica, is het plaatsen van dit serverexemplaren aan het einde van de lijst doorgaans een goede gewoonte, zodat verbindingen met leesintentie naar een secundaire replica gaan, indien beschikbaar.

Vanaf SQL Server 2016 (13.x) kunt u aanvragen met leesintenties verdelen over leesbare secundaire replica's. U geeft dit op door de replica's in een geneste set haakjes in de lijst met alleen-lezenroutering te plaatsen. Zie Taakverdeling configureren voor alleen-lezen replica'svoor meer informatie en voorbeelden.

GEEN

Hiermee geeft u op dat wanneer deze beschikbaarheidsreplica de primaire replica is, alleen-lezenroutering niet wordt ondersteund. Dit is het standaardgedrag. Wanneer deze waarde wordt gebruikt met MODIFY REPLICA ON, wordt een bestaande lijst uitgeschakeld, indien van toepassing.

READ_WRITE_ROUTING_URL = 'TCP://systeemadres:poort'

Van toepassing op: SQL Server (vanaf SQL Server 2019 (15.x))

Hiermee geeft u serverexemplaren op die beschikbaarheidsreplica's hosten voor deze beschikbaarheidsgroep die voldoen aan de volgende vereisten bij uitvoering onder de primaire rol:

De replicaspecificatie PRIMARY_ROLE bevat READ_WRITE_ROUTING_URL.
De verbindingsreeks is ReadWrite door ApplicationIntent te definiëren als ReadWrite of door ApplicationIntent niet in te stellen en de standaardinstelling (ReadWrite) van kracht te laten worden.

Zie secundaire naar primaire replica omleiding van lees-/schrijfverbindingen (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

SESSION_TIMEOUT = seconden

Hiermee geeft u de sessietime-outperiode in seconden. Als u deze optie niet opgeeft, is de periode standaard 10 seconden. De minimumwaarde is 5 seconden.

Belangrijk

U wordt aangeraden de time-outperiode op 10 seconden of hoger te houden.

Zie Overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)voor meer informatie over de time-outperiode voor sessies.

REPLICA WIJZIGEN OP

Hiermee wijzigt u een van de replica's van de beschikbaarheidsgroep. De lijst met replica's die moeten worden gewijzigd, bevat het adres van het serverexemplaren en een WITH (...)-component voor elke replica.

Alleen ondersteund op de primaire replica.

REPLICA VERWIJDEREN OP

Hiermee verwijdert u de opgegeven secundaire replica uit de beschikbaarheidsgroep. De huidige primaire replica kan niet worden verwijderd uit een beschikbaarheidsgroep. Als de replica wordt verwijderd, ontvangt de replica geen gegevens meer. De secundaire databases worden verwijderd uit de beschikbaarheidsgroep en voeren de status HERSTELLEN in.

Alleen ondersteund op de primaire replica.

Notitie

Als u een replica verwijdert terwijl deze niet beschikbaar of mislukt is, wordt gedetecteerd dat de replica niet langer deel uitmaakt van de beschikbaarheidsgroep wanneer deze weer online is.

VERBINDEN

Zorgt ervoor dat het lokale serverexemplaren een secundaire replica hosten in de opgegeven beschikbaarheidsgroep.

Alleen ondersteund op een secundaire replica die nog niet is toegevoegd aan de beschikbaarheidsgroep.

Zie Een secundaire replica toevoegen aan een beschikbaarheidsgroep (SQL Server)voor meer informatie.

FAILOVER

Start een handmatige failover van de beschikbaarheidsgroep zonder gegevensverlies naar de secundaire replica waarmee u bent verbonden. De replica waarop de primaire replica wordt gehost, is het failoverdoel. Het failoverdoel neemt de primaire rol over en herstelt de kopie van elke database en brengt deze online als de nieuwe primaire databases. De voormalige primaire replica gaat gelijktijdig over naar de secundaire rol en de bijbehorende databases worden secundaire databases en worden onmiddellijk onderbroken. Deze rollen kunnen mogelijk heen en weer worden omgeschakeld door een reeks fouten.

Alleen ondersteund op een secundaire replica met synchrone doorvoer die momenteel wordt gesynchroniseerd met de primaire replica. Houd er rekening mee dat voor een secundaire replica die moet worden gesynchroniseerd, de primaire replica ook moet worden uitgevoerd in de modus synchrone doorvoer.

Notitie

Een failoveropdracht wordt geretourneerd zodra het failoverdoel de opdracht heeft geaccepteerd. Databaseherstel vindt echter asynchroon plaats nadat de beschikbaarheidsgroep de failover heeft voltooid.

Zie een geplande handmatige failover uitvoerenvoor informatie over de beperkingen, vereisten en aanbevelingen voor een geplande handmatige failover van een beschikbaarheidsgroep (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Voorzichtigheid

Het afdwingen van failover, waarbij gegevens verloren kunnen gaan, is strikt een methode voor herstel na noodgevallen. Daarom raden we u ten zeerste aan om failover alleen af te dwingen als de primaire replica niet meer wordt uitgevoerd, u bereid bent om gegevens te verliezen en moet u de service onmiddellijk herstellen naar de beschikbaarheidsgroep.

Alleen ondersteund op een replica waarvan de rol de status SECUNDAIR of OPLOSSEN heeft. --De replica waarop u een failoveropdracht invoert, wordt het failoverdoelgenoemd.

Dwingt failover van de beschikbaarheidsgroep, met mogelijk gegevensverlies, af naar het failoverdoel. Het failoverdoel neemt de primaire rol over en herstelt de kopie van elke database en brengt deze online als de nieuwe primaire databases. Op alle resterende secundaire replica's wordt elke secundaire database onderbroken totdat deze handmatig wordt hervat. Wanneer de voormalige primaire replica beschikbaar komt, wordt deze overgeschakeld naar de secundaire rol en worden de bijbehorende databases onderbroken secundaire databases.

Notitie

Zie Een geforceerde failover van een beschikbaarheidsgroep (SQL Server) uitvoeren voor informatie over de beperkingen, vereisten en aanbevelingen voor het afdwingen van failover en het effect van een geforceerde failover op de voormalige primaire databases in de beschikbaarheidsgroep.

LISTENER TOEVOEGEN 'dns_name'( <add_listener_option> )

Definieert een nieuwe listener voor beschikbaarheidsgroepen voor deze beschikbaarheidsgroep. Alleen ondersteund op de primaire replica.

Belangrijk

Voordat u uw eerste listener maakt, raden we u ten zeerste aan Een listener voor een beschikbaarheidsgroep (SQL Server) te maken of configurerente lezen.

Nadat u een listener voor een bepaalde beschikbaarheidsgroep hebt gemaakt, raden we u ten zeerste aan het volgende te doen:

Vraag de netwerkbeheerder om het IP-adres van de listener te reserveren voor exclusief gebruik.
Geef de DNS-hostnaam van de listener aan toepassingsontwikkelaars om te gebruiken in verbindingsreeksen bij het aanvragen van clientverbindingen met deze beschikbaarheidsgroep.

dns_name

Hiermee geeft u de DNS-hostnaam van de listener voor de beschikbaarheidsgroep op. De DNS-naam van de listener moet uniek zijn in het domein en in NetBIOS.

dns_name is een tekenreekswaarde. Deze naam mag alleen alfanumerieke tekens, streepjes (-) en afbreekstreepjes (_) bevatten in elke volgorde. DNS-hostnamen zijn niet hoofdlettergevoelig. De maximale lengte is 63 tekens.

U wordt aangeraden een zinvolle tekenreeks op te geven. Voor een beschikbaarheidsgroep met de naam AG1wordt een zinvolle DNS-hostnaam bijvoorbeeld ag1-listener.

Belangrijk

NetBIOS herkent alleen de eerste 15 tekens in de dns_name. Als u twee WSFC-clusters hebt die worden beheerd door dezelfde Active Directory en u probeert listeners voor beschikbaarheidsgroepen te maken in beide clusters met namen met meer dan 15 tekens en een identiek voorvoegsel van 15 tekens, krijgt u een foutmelding dat de resource voor de naam van het virtuele netwerk niet online kan worden gebracht. Zie Domain Names toewijzenvoor meer informatie over naamgevingsregels voor voorvoegsels voor DNS-namen.

DEELNEMEN AAN BESCHIKBAARHEIDSGROEP AAN

Wordt toegevoegd aan een gedistribueerde beschikbaarheidsgroep. Wanneer u een gedistribueerde beschikbaarheidsgroep maakt, is de beschikbaarheidsgroep in het cluster waar deze wordt gemaakt de primaire beschikbaarheidsgroep. De beschikbaarheidsgroep die deelneemt aan de gedistribueerde beschikbaarheidsgroep is de secundaire beschikbaarheidsgroep.

<ag_name>

Hiermee geeft u de naam van de beschikbaarheidsgroep op waaruit de helft van de gedistribueerde beschikbaarheidsgroep bestaat.

LISTENER = 'TCP://systeemadres:poort'

Hiermee geeft u het URL-pad op voor de listener die is gekoppeld aan de beschikbaarheidsgroep.

De LISTENER-component is vereist.

'TCP://systeemadres:poort'

Hiermee geeft u een URL op voor de listener die is gekoppeld aan de beschikbaarheidsgroep. De URL-parameters zijn als volgt:

systeemadres

Een tekenreeks, zoals een systeemnaam, een volledig gekwalificeerde domeinnaam of een IP-adres, die de listener ondubbelzinnig identificeert.

poort

Een poortnummer dat is gekoppeld aan het spiegelingseindpunt van de beschikbaarheidsgroep. Houd er rekening mee dat dit niet de poort van de listener is.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Hiermee geeft u op of de primaire replica moet wachten totdat de secundaire beschikbaarheidsgroep de beveiliging (schrijven) van de logboekrecords naar schijf moet bevestigen voordat de primaire replica de transactie op een bepaalde primaire database kan doorvoeren.

SYNCHRONOUS_COMMIT

Hiermee geeft u op dat de primaire replica wacht op het doorvoeren van transacties totdat deze zijn beperkt tot de secundaire beschikbaarheidsgroep. U kunt SYNCHRONOUS_COMMIT opgeven voor maximaal twee beschikbaarheidsgroepen, waaronder de primaire beschikbaarheidsgroep.

ASYNCHRONOUS_COMMIT

Hiermee geeft u op dat de primaire replica transacties doorvoert zonder te wachten tot deze secundaire beschikbaarheidsgroep het logboek heeft beperkt. U kunt ASYNCHRONOUS_COMMIT opgeven voor maximaal twee beschikbaarheidsgroepen, inclusief de primaire beschikbaarheidsgroep.

De AVAILABILITY_MODE-component is vereist.

FAILOVER_MODE = { MANUAL }

Hiermee geeft u de failovermodus van de gedistribueerde beschikbaarheidsgroep.

HANDMATIG

Hiermee schakelt u geplande handmatige failover of geforceerde handmatige failover in (meestal geforceerde failovergenoemd) door de databasebeheerder.

Automatische failover naar de secundaire beschikbaarheidsgroep wordt niet ondersteund.

SEEDING_MODE = { AUTOMATIC | HANDMATIG }

Hiermee geeft u op hoe de secundaire beschikbaarheidsgroep in eerste instantie wordt gezaaid.

AUTOMATISCH

Hiermee schakelt u automatische seeding in. Met deze methode wordt de secundaire beschikbaarheidsgroep via het netwerk seedd. Voor deze methode hoeft u geen back-up te maken en een kopie van de primaire database te herstellen op de replica's van de secundaire beschikbaarheidsgroep.

HANDMATIG

Hiermee geeft u handmatig seeding. Voor deze methode moet u een back-up van de database maken op de primaire replica en die back-up handmatig herstellen op de replica('s) van de secundaire beschikbaarheidsgroep.

BESCHIKBAARHEIDSGROEP WIJZIGEN AAN

Hiermee wijzigt u een van de instellingen van een beschikbaarheidsgroep van een gedistribueerde beschikbaarheidsgroep. De lijst met beschikbaarheidsgroepen die moeten worden gewijzigd, bevat de naam van de beschikbaarheidsgroep en een WITH (...)-component voor elke beschikbaarheidsgroep.

Belangrijk

Deze opdracht moet worden herhaald op zowel de primaire beschikbaarheidsgroep als de secundaire beschikbaarheidsgroepexemplaren.

EEN DATABASE MAKEN VERLENEN

Hiermee kan de beschikbaarheidsgroep databases maken namens de primaire replica, die ondersteuning biedt voor direct seeding (SEEDING_MODE = AUTOMATIC). Deze parameter moet worden uitgevoerd op elke secundaire replica die direct seeding ondersteunt nadat deze secundaire lid is van de beschikbaarheidsgroep. Hiervoor is de machtiging CREATE ANY DATABASE vereist.

EEN DATABASE MAKEN WEIGEREN

Hiermee verwijdert u de mogelijkheid van de beschikbaarheidsgroep om databases te maken namens de primaire replica.

<add_listener_option>

ADD LISTENER heeft een van de volgende opties:

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

Hiermee geeft u op dat de listener van de beschikbaarheidsgroep het DHCP (Dynamic Host Configuration Protocol) gebruikt. Gebruik eventueel de ON-component om het netwerk te identificeren waarop deze listener wordt gemaakt. DHCP is beperkt tot één subnet dat wordt gebruikt voor elke serverexemplaren die als host fungeert voor een beschikbaarheidsreplica in de beschikbaarheidsgroep.

Belangrijk

Dhcp wordt niet aanbevolen in een productieomgeving. Als er een uitvalt en de DHCP IP-lease verloopt, is extra tijd nodig om het nieuwe IP-adres van het DHCP-netwerk te registreren dat is gekoppeld aan de DNS-naam van de listener en van invloed is op de clientconnectiviteit. DHCP is echter handig voor het instellen van uw ontwikkel- en testomgeving om de basisfuncties van beschikbaarheidsgroepen te controleren en voor integratie met uw toepassingen.

Bijvoorbeeld:

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

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

Hiermee geeft u op dat de listener van de beschikbaarheidsgroep een of meer statische IP-adressen gebruikt in plaats van DHCP. Als u een beschikbaarheidsgroep wilt maken in meerdere subnetten, vereist elk subnet één statisch IP-adres in de configuratie van de listener. Voor een bepaald subnet kan het statische IP-adres een IPv4-adres of een IPv6-adres zijn. Neem contact op met de netwerkbeheerder om een statisch IP-adres op te halen voor elk subnet dat als host fungeert voor een beschikbaarheidsreplica voor de nieuwe beschikbaarheidsgroep.

Bijvoorbeeld:

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

ipv4_address

Hiermee geeft u een vierdelige IPv4-adres voor een listener voor een beschikbaarheidsgroep op. Bijvoorbeeld 10.120.19.155.

ipv4_mask

Hiermee geeft u een IPv4 vierdelige masker voor een listener voor een beschikbaarheidsgroep op. Bijvoorbeeld 255.255.254.0.

ipv6_address

Hiermee geeft u een IPv6-adres voor een listener voor een beschikbaarheidsgroep op. Bijvoorbeeld 2001::4898:23:1002:20f:1fff:feff:b3a3.

PORT = listener_port

Hiermee geeft u het poortnummer-listener_port-moet worden gebruikt door een listener van een beschikbaarheidsgroep die is opgegeven door een WITH IP-component. POORT is optioneel.

Het standaardpoortnummer, 1433, wordt ondersteund. Als u echter beveiligingsproblemen ondervindt, raden we u aan een ander poortnummer te gebruiken.

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

LISTENER wijzigen 'dns_name'( <modify_listener_option> )

Hiermee wijzigt u een bestaande listener voor beschikbaarheidsgroepen voor deze beschikbaarheidsgroep. Alleen ondersteund op de primaire replica.

<modify_listener_option>

MODIFY LISTENER heeft een van de volgende opties:

IP toevoegen { ('four_part_ipv4_address','four_part_ipv4_mask') | ('dns_nameipv6_address') }

Voegt het opgegeven IP-adres toe aan de listener van de beschikbaarheidsgroep die is opgegeven door dns_name.

PORT = listener_port

Zie de beschrijving van dit argument eerder in deze sectie.

LISTENER OPNIEUW OPSTARTEN 'dns_name'

Start de listener opnieuw op die is gekoppeld aan de opgegeven DNS-naam. Alleen ondersteund op de primaire replica.

LISTENER VERWIJDEREN 'dns_name'

Hiermee verwijdert u de listener die is gekoppeld aan de opgegeven DNS-naam. Alleen ondersteund op de primaire replica.

OFFLINE

Hiermee wordt een online beschikbaarheidsgroep offline gehaald. Er zijn geen gegevensverlies voor synchrone doorvoerdatabases.

Nadat een beschikbaarheidsgroep offline is gegaan, zijn de databases niet meer beschikbaar voor clients en kunt u de beschikbaarheidsgroep niet online brengen. Gebruik daarom de optie OFFLINE alleen tijdens een migratie tussen clusters van AlwaysOn-beschikbaarheidsgroepen bij het migreren van resources van beschikbaarheidsgroepen naar een nieuw WSFC-cluster.

Zie een offline beschikbaarheidsgroep (SQL Server)voor meer informatie.

Vereisten en beperkingen

Zie vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server)voor informatie over vereisten en beperkingen voor beschikbaarheidsreplica's en op hun hostserverexemplaren en -computers.

Zie Overzicht van Transact-SQL-instructies voor AlwaysOn-beschikbaarheidsgroepen (SQL Server) voor informatie over beperkingen voor de Transact-SQL-instructies voor beschikbaarheidsgroepen (SQL Server).

Veiligheid

Machtigingen

Hiervoor is de machtiging ALTER AVAILABILITY GROUP vereist voor de beschikbaarheidsgroep, DE machtiging BESCHIKBAARHEIDSGROEP BEHEREN, DE MACHTIGING BESCHIKBAARHEIDSGROEP WIJZIGEN of DE MACHTIGING CONTROL SERVER. Hiervoor is ook ALTER ANY DATABASE-machtiging vereist.

Voorbeelden

Een. Een secundaire replica toevoegen aan een beschikbaarheidsgroep

In het volgende voorbeeld wordt een secundaire replica gekoppeld waaraan u bent verbonden met de AccountsAG beschikbaarheidsgroep.

ALTER AVAILABILITY GROUP AccountsAG JOIN;  
GO

B. Failover van een beschikbaarheidsgroep afdwingen

In het volgende voorbeeld wordt de AccountsAG beschikbaarheidsgroep gedwongen om een failover uit te voeren naar de secundaire replica waarmee u bent verbonden.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
GO

Zie ook

CREATE AVAILABILITY GROUP (Transact-SQL)
ALTER DATABASE SET HADR (Transact-SQL)
DROP AVAILABILITY GROUP (Transact-SQL)
sys.availability_replicas (Transact-SQL)
sys.availability_groups (Transact-SQL)
problemen met configuratie van AlwaysOn-beschikbaarheidsgroepen (SQL Server) oplossen
overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)
listeners voor beschikbaarheidsgroepen, clientconnectiviteit en toepassingsfailover (SQL Server)

Delen via

ALTER AVAILABILITY GROUP (Transact-SQL)

Syntaxis

Argumenten

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECUNDAIR | GEEN }

PRIMAIR

SECONDARY_ONLY

SECUNDAIR

GEEN

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

HEALTH_CHECK_TIMEOUT = milliseconden

DB_FAILOVER = { ON | UIT }

DTC_SUPPORT = { PER_DB | GEEN }

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

ROL

DATABASE toevoegen database_name

DATABASE verwijderen database_name

REPLICA TOEVOEGEN AAN

<server_instance>

system_name

FCI_network_name

instance_name

\

ENDPOINT_URL = 'TCP://systeemadres:poort'

'TCP://systeemadres:poort'

systeemadres

poort

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

CONFIGURATION_ONLY

FAILOVER_MODE = { AUTOMATIC | HANDMATIG }

AUTOMATISCH

HANDMATIG

SEEDING_MODE = { AUTOMATIC | HANDMATIG }

AUTOMATISCH

HANDMATIG

BACKUP_PRIORITY = n

SECONDARY_ROLE ( ... )

ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }

NEE

READ_ONLY

ALLE

READ_ONLY_ROUTING_URL = 'TCP://systeemadres:poort'

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | ALL }

READ_WRITE

ALLE

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

<server_instance>

GEEN

READ_WRITE_ROUTING_URL = 'TCP://systeemadres:poort'

SESSION_TIMEOUT = seconden

REPLICA WIJZIGEN OP

REPLICA VERWIJDEREN OP

VERBINDEN

FAILOVER

FORCE_FAILOVER_ALLOW_DATA_LOSS

LISTENER TOEVOEGEN 'dns_name'( <add_listener_option> )

dns_name

DEELNEMEN AAN BESCHIKBAARHEIDSGROEP AAN

<ag_name>

LISTENER = 'TCP://systeemadres:poort'

'TCP://systeemadres:poort'

systeemadres

poort

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUAL }

HANDMATIG

SEEDING_MODE = { AUTOMATIC | HANDMATIG }

AUTOMATISCH

HANDMATIG

BESCHIKBAARHEIDSGROEP WIJZIGEN AAN

EEN DATABASE MAKEN VERLENEN

EEN DATABASE MAKEN WEIGEREN

<add_listener_option>

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

IP toevoegen { ('four_part_ipv4_address','four_part_ipv4_mask') | ('dns_nameipv6_address') }