BESCHIKBAARHEIDSGROEP MAKEN (Transact-SQL)
van toepassing op:SQL Server-
Hiermee maakt u een nieuwe beschikbaarheidsgroep als het exemplaar van SQL Server is ingeschakeld voor de functie AlwaysOn-beschikbaarheidsgroepen.
Belangrijk
Voer CREATE AVAILABILITY GROUP uit op het exemplaar van SQL Server dat u wilt gebruiken als de eerste primaire replica van uw nieuwe beschikbaarheidsgroep. Dit serverexemplaren moeten zich bevinden op een WSFC-knooppunt (Windows Server Failover Clustering).
Transact-SQL syntaxisconventies
Syntaxis
CREATE AVAILABILITY GROUP group_name
WITH (<with_option_spec> [ ,...n ] )
FOR [ DATABASE database_name [ ,...n ] ]
REPLICA ON <add_replica_spec> [ ,...n ]
AVAILABILITY GROUP ON <add_availability_group_spec> [ ,...2 ]
[ LISTENER 'dns_name' ( <listener_option> ) ]
[ ; ]
<with_option_spec>::=
AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
| FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }
| HEALTH_CHECK_TIMEOUT = milliseconds
| DB_FAILOVER = { ON | OFF }
| DTC_SUPPORT = { PER_DB | NONE }
| [ BASIC | DISTRIBUTED | CONTAINED [ REUSE_SYSTEM_DATABASES ] ]
| REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
| CLUSTER_TYPE = { WSFC | EXTERNAL | NONE }
<add_replica_spec>::=
<server_instance> WITH
(
ENDPOINT_URL = 'TCP://system-address:port',
AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY },
FAILOVER_MODE = { AUTOMATIC | MANUAL | EXTERNAL }
[ , <add_replica_option> [ ,...n ] ]
)
<add_replica_option>::=
SEEDING_MODE = { AUTOMATIC | MANUAL }
| BACKUP_PRIORITY = n
| SECONDARY_ROLE ( {
[ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]
[,] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]
} )
| PRIMARY_ROLE ( {
[ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]
[,] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | NONE } ]
[,] [ READ_WRITE_ROUTING_URL = 'TCP://system-address:port' ]
} )
| SESSION_TIMEOUT = integer
<add_availability_group_spec>::=
<ag_name> WITH
(
LISTENER_URL = 'TCP://system-address:port',
AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT },
FAILOVER_MODE = MANUAL,
SEEDING_MODE = { AUTOMATIC | MANUAL }
)
<listener_option> ::=
{
WITH DHCP [ ON ( <network_subnet_option> ) ]
| WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
}
<network_subnet_option> ::=
'ip4_address', 'four_part_ipv4_mask'
<ip_address_option> ::=
{
'ip4_address', 'pv4_mask'
| 'ipv6_address'
}
Argumenten
group_name
Hiermee geeft u de naam van de nieuwe beschikbaarheidsgroep.
group_name moet een geldige SQL Serveridzijn en moet uniek zijn voor alle beschikbaarheidsgroepen in het WSFC-cluster. De maximale lengte voor een naam van een beschikbaarheidsgroep is 128 tekens voor cluster_type = WSFC
en 64 tekens voor cluster_type = NONE
en EXTERNAL
.
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.
De ondersteunde 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 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 worden 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.
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 worker-threads. -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 serverstatusinformatie 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 15.000 milliseconden (15 seconden) en de maximumwaarde is 4.294.967.295 milliseconden.
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 }
van toepassing op: SQL Server (vanaf SQL Server 2016 (13.x))
Hiermee geeft u op of transacties tussen databases worden ondersteund via de gedistribueerde transactiecoördinator (DTC). Transacties tussen databases worden alleen ondersteund vanaf SQL Server 2016 (13.x). PER_DB maakt de beschikbaarheidsgroep met ondersteuning voor deze transacties. Zie Cross-Database Transactions and Distributed Transactions for AlwaysOn availability groups and Database Mirroring (SQL Server)voor meer informatie.
BASISCH
van toepassing op: SQL Server (vanaf SQL Server 2016 (13.x))
Wordt gebruikt om een eenvoudige beschikbaarheidsgroep te maken. Basis beschikbaarheidsgroepen zijn beperkt tot één database en twee replica's: een primaire replica en één secundaire replica. Deze optie is een vervanging voor de afgeschafte functie voor databasespiegeling in SQL Server Standard Edition. Zie Basic-beschikbaarheidsgroepen (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie. Basis beschikbaarheidsgroepen worden ondersteund vanaf SQL Server 2016 (13.x).
GEDISTRIBUEERD
van toepassing op: SQL Server (vanaf SQL Server 2016 (13.x))
Wordt gebruikt om een gedistribueerde beschikbaarheidsgroep te maken. Deze optie wordt gebruikt met de parameter AVAILABILITY GROUP ON om twee beschikbaarheidsgroepen in afzonderlijke Windows Server-failoverclusters te verbinden. Zie Gedistribueerde beschikbaarheidsgroepen (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie. Gedistribueerde beschikbaarheidsgroepen worden ondersteund vanaf SQL Server 2016 (13.x).
INGESLOTEN [REUSE_SYSTEM_DATABASES]
Geïntroduceerd in SQL Server 2022 (16.x).
Maak een ingesloten beschikbaarheidsgroep. Deze optie wordt gebruikt om een beschikbaarheidsgroep te maken met een eigen master
en msdb
databases, die gesynchroniseerd blijven voor de set replica's in de beschikbaarheidsgroep.
De optie REUSE_SYSTEM_DATABASES zorgt ervoor dat de ingesloten master
en msdb
databases van een eerdere versie van de beschikbaarheidsgroep worden gebruikt bij het maken van deze nieuwe beschikbaarheidsgroep. Zie Overzicht van ingesloten beschikbaarheidsgroepen (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie over ingesloten beschikbaarheidsgroepen.
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
van toepassing op: SQL Server (vanaf SQL Server 2017 (14.x))
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.
Niet ondersteund voor CREATE AVAILABILITY GROUP. Vanaf SQL Server 2022 (16.x) kunt u ALTER AVAILABILITY GROUP gebruiken om REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in te stellen op een gedistribueerde beschikbaarheidsgroep. Zie ALTER AVAILABILITY GROUP (Transact-SQL).
CLUSTER_TYPE
van toepassing op: SQL Server (vanaf SQL Server 2017 (14.x)).
Wordt gebruikt om te bepalen of de beschikbaarheidsgroep zich op een Windows Server-failovercluster (WSFC) bevindt. Ingesteld op WSFC wanneer de beschikbaarheidsgroep zich op een exemplaar van een failovercluster in een Windows Server-failovercluster bevindt. Ingesteld op EXTERNAL wanneer het cluster wordt beheerd door een clusterbeheerder die geen Windows Server-failovercluster is, zoals Linux Pacemaker. Ingesteld op NONE wanneer beschikbaarheidsgroep geen WSFC gebruikt voor clustercoördinatie. Bijvoorbeeld wanneer een beschikbaarheidsgroep Linux-servers bevat zonder clusterbeheer.
DATABASE-database_name
Hiermee geeft u een lijst op van een of meer gebruikersdatabases op het lokale SQL Server-exemplaar (dat wil gezegd het serverexemplaren waarop u de beschikbaarheidsgroep maakt). 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.
De DATABASE-component is optioneel. Als u deze weglaat, is de nieuwe beschikbaarheidsgroep leeg.
Nadat u de beschikbaarheidsgroep hebt gemaakt, maakt u verbinding met elk serverexemplaren waarop een secundaire replica wordt gehost en bereidt u vervolgens elke secundaire database voor en voegt u deze toe aan de beschikbaarheidsgroep. Zie Gegevensverplaatsing starten op een AlwaysOn Secondary Database (SQL Server)voor meer informatie.
Notitie
Later kunt u in aanmerking komende databases toevoegen aan het serverexemplaren waarop de huidige primaire replica wordt gehost voor een beschikbaarheidsgroep. U kunt ook een database verwijderen uit een beschikbaarheidsgroep. Zie ALTER AVAILABILITY GROUP (Transact-SQL)voor meer informatie.
REPLICA INGESCHAKELD
Hiermee geeft u op van één tot vijf SQL Server-exemplaren voor het hosten van beschikbaarheidsreplica's in de nieuwe beschikbaarheidsgroep. Elke replica wordt opgegeven door het adres van het serverexemplaren, gevolgd door een WITH (...)-component. U moet minimaal het lokale serverexemplaren opgeven. Dit wordt de eerste primaire replica. U kunt desgewenst ook maximaal vier secundaire replica's opgeven.
U moet elke secundaire replica toevoegen aan de beschikbaarheidsgroep. Zie ALTER AVAILABILITY GROUP (Transact-SQL)voor meer informatie.
Notitie
Als u minder dan vier secundaire replica's opgeeft wanneer u een beschikbaarheidsgroep maakt, kunt u op elk gewenst moment een extra secundaire replica opgeven met behulp van de instructie ALTER AVAILABILITY GROUPTransact-SQL instructie. U kunt deze instructie ook gebruiken om een secundaire replica uit een bestaande beschikbaarheidsgroep te verwijderen.
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, als volgt:
{ '*system_name*[\\*instance_name*]' | '*FCI_network_name*[\\*instance_name*]' }
De onderdelen van dit adres zijn als volgt:
system_name
Is de NetBIOS-naam van het computersysteem waarop het doelexemplaren van SQL Server zich bevinden. Deze computer moet een WSFC-knooppunt zijn.
FCI_network_name
Is 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
Is de naam van een exemplaar van een SQL Server dat wordt gehost door system_name of FCI_network_name en waarvoor de HADR-service is ingeschakeld. Voor een standaardserverexemplaren is instance_name optioneel. De naam van het exemplaar is niet hoofdlettergevoelig. Op een benoemd exemplaar is deze waardenaam hetzelfde als de waarde die wordt geretourneerd door select ServerProperty(N'InstanceName');
uit te voeren.
\
Is een scheidingsteken dat alleen wordt gebruikt bij het opgeven van instance_name, om deze te scheiden van system_name of FCI_network_name.
Zie vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server) voor meer informatie over de vereisten voor WSFC-knooppunten en serverexemplaren.
ENDPOINT_URL ='TCP://systeemadres:poort'
Hiermee geeft u het URL-pad op voor het eindpunt voor databasespiegeling op het exemplaar van SQL Server dat als host fungeert voor de beschikbaarheidsreplica die u in de huidige REPLICA ON-component definieert.
De ENDPOINT_URL-component is vereist. 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
Is een tekenreeks, zoals een systeemnaam, een volledig gekwalificeerde domeinnaam of een IP-adres, die het doelcomputersysteem ondubbelzinnig identificeert.
haven
Is een poortnummer dat is gekoppeld aan het spiegelingseindpunt van het partnerserverexemplaar (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 }
SYNCHRONOUS_COMMIT of ASYNCHRONOUS_COMMIT geeft aan of de primaire replica moet wachten totdat de secundaire replica de beveiliging (schrijven) van de logboekrecords op 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. SQL Server 2017 (14.x) CU1 introduceert CONFIGURATION_ONLY. CONFIGURATION_ONLY replica is alleen van toepassing op beschikbaarheidsgroepen met CLUSTER_TYPE = EXTERNAL
of CLUSTER_TYPE = NONE
.
SYNCHRONOUS_COMMIT
Hiermee geeft u op dat de primaire replica wacht op het doorvoeren van transacties totdat ze zijn beperkt 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
.De opties
failover_mode
enseeding_mode
worden niet ondersteund wanneeravailability_mode
is ingesteld opconfiguration_only
voor een replica. Hier wordt een voorbeeld weergegeven .Zie Alleen replica-configureren voor meer informatie.
De AVAILABILITY_MODE-component is vereist. 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. Deze optie wordt alleen ondersteund als u ook AVAILABILITY_MODE = SYNCHRONOUS_COMMIT opgeeft. U kunt AUTOMATISCH opgeven voor twee beschikbaarheidsreplica's, inclusief de primaire replica.
Notitie
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 geplande handmatige failover of geforceerde handmatige failover in (meestal geforceerde failovergenoemd) door de databasebeheerder.
De FAILOVER_MODE-component is vereist. De twee typen handmatige failover, handmatige failover zonder gegevensverlies en geforceerde failover (met mogelijk gegevensverlies), worden ondersteund onder verschillende omstandigheden. 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 gezaaid.
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-up 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 niet geschikt is 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-ups maken van 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 Verbindingsreekstrefwoorden 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 database-engine luistert. Normaal gesproken luistert het standaardexemplaren van de SQL Server 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 replica.
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 Verbindingsreekstrefwoorden 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).
Laat hun alleen-lezen routerings-URL gedefinieerd (zie het READ_ONLY_ROUTING_URL argument van de optie SECONDARY_ROLE).
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 replica 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.
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 = geheel getal
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 sessietime-outperiode.
BESCHIKBAARHEIDSGROEP INGESCHAKELD
Hiermee geeft u twee beschikbaarheidsgroepen op die een gedistribueerde beschikbaarheidsgroep vormen. Elke beschikbaarheidsgroep maakt deel uit van een eigen Windows Server Failover Cluster (WSFC). Wanneer u een gedistribueerde beschikbaarheidsgroep maakt, wordt de beschikbaarheidsgroep op het huidige SQL Server-exemplaar de primaire beschikbaarheidsgroep. De tweede beschikbaarheidsgroep wordt de secundaire beschikbaarheidsgroep.
U moet de secundaire beschikbaarheidsgroep toevoegen aan de gedistribueerde beschikbaarheidsgroep. Zie ALTER AVAILABILITY GROUP (Transact-SQL)voor meer informatie.
ag_name
Hiermee geeft u de naam van de beschikbaarheidsgroep op waaruit de helft van de gedistribueerde beschikbaarheidsgroep bestaat.
LISTENER_URL ='TCP://systeemadres:poort'
Hiermee geeft u het URL-pad op voor de listener die is gekoppeld aan de beschikbaarheidsgroep.
De LISTENER_URL-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
Is een tekenreeks, zoals een systeemnaam, een volledig gekwalificeerde domeinnaam of een IP-adres, die de listener ondubbelzinnig identificeert.
poort
Is 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 | CONFIGURATION_ONLY }
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.
De FAILOVER_MODE-component is vereist en de enige optie is HANDMATIG. 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 seeded.
AUTOMATISCH
Hiermee schakelt u direct seeding in. Met deze methode wordt de secundaire beschikbaarheidsgroep via het netwerk gezaaid. 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 (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 replica('s) van de secundaire beschikbaarheidsgroep.
LISTENER 'dns_name'( listener_option )
Definieert een nieuwe listener voor beschikbaarheidsgroepen voor deze beschikbaarheidsgroep. LISTENER is een optioneel argument.
Belangrijk
Voordat u uw eerste listener maakt, raden we u ten zeerste aan een listener voor een beschikbaarheidsgroep (SQL Server) te maken of configureren.
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 AG1
wordt 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, wordt er een foutbericht weergegeven 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.
listener_option
LISTENER heeft een van de volgende <listener_option> opties:
MET DHCP [ ON { ('four_part_ipv4_address','four_part_ipv4_mask') } ]
Hiermee geeft u op dat de listener van de beschikbaarheidsgroep gebruikmaakt van het Dynamic Host Configuration Protocol (DHCP). Gebruik eventueel de ON-component om het netwerk te identificeren waarop deze listener is gemaakt. DHCP is beperkt tot één subnet dat wordt gebruikt voor elke serverexemplaren die als host fungeert voor een replica 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 replica voor de nieuwe beschikbaarheidsgroep.
Bijvoorbeeld:
WITH IP ( ('10.120.19.155','255.255.254.0') )
ip4_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
Vereisten en beperkingen
Zie vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server)voor informatie over de vereisten voor het maken van een beschikbaarheidsgroep.
Veiligheid
Machtigingen
Vereist lidmaatschap van de vaste serverfunctie sysadmin en create AVAILABILITY GROUP server permission, ALTER ANY AVAILABILITY GROUP permission of CONTROL SERVER permission.
Voorbeelden
Een. Back-up configureren op secundaire replica's, flexibel failoverbeleid en verbindingstoegang
In het volgende voorbeeld wordt een beschikbaarheidsgroep met de naam MyAg
gemaakt voor twee gebruikersdatabases, ThisDatabase
en ThatDatabase
. De volgende tabel bevat een overzicht van de waarden die zijn opgegeven voor de opties die zijn ingesteld voor de beschikbaarheidsgroep als geheel.
Groepsoptie | Montuur | Beschrijving |
---|---|---|
AUTOMATED_BACKUP_PREFERENCE | SECUNDAIR | Deze automatische back-upvoorkeur geeft aan dat back-ups moeten worden uitgevoerd op een secundaire replica, behalve wanneer de primaire replica de enige replica online is (dit is het standaardgedrag). Voordat de AUTOMATED_BACKUP_PREFERENCE instelling effect heeft, moet u back-uptaken uitvoeren op de beschikbaarheidsdatabases om rekening te houden met de automatische back-upvoorkeur. |
FAILURE_CONDITION_LEVEL | 3 | Deze instelling voor foutvoorwaardeniveau geeft aan dat een automatische failover moet worden gestart op kritieke interne SQL Server-fouten, zoals zwevende spinlocks, ernstige schendingen van schrijftoegang of te veel dumping. |
HEALTH_CHECK_TIMEOUT | 600000 | Deze time-outwaarde voor statuscontrole, 60 seconden, geeft aan dat het WSFC-cluster 60000 milliseconden wacht voor de sp_server_diagnostics systeem opgeslagen procedure om serverstatusgegevens te retourneren over een serverexemplaren die als host fungeert voor een synchrone doorvoerreplica met automatisch voordat het cluster ervan uitgaat dat het hostserverexemplaren traag of niet reageert. (De standaardwaarde is 30000 milliseconden). |
Er moeten drie beschikbaarheidsreplica's worden gehost door de standaardserverexemplaren op computers met de naam COMPUTER01
, COMPUTER02
en COMPUTER03
. De volgende tabel bevat een overzicht van de waarden die zijn opgegeven voor de replicaopties van elke replica.
Optie replica | Instellen op COMPUTER01 |
Instellen op COMPUTER02 |
Instellen op COMPUTER03 |
Beschrijving |
---|---|---|---|---|
ENDPOINT_URL | TCP://COMPUTER01:5022 | TCP://COMPUTER02:5022 | TCP://COMPUTER03:5022 | In dit voorbeeld zijn de systemen hetzelfde domein, zodat de eindpunt-URL's de naam van het computersysteem als het systeemadres kunnen gebruiken. |
AVAILABILITY_MODE | SYNCHRONOUS_COMMIT | SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | Twee van de replica's maken gebruik van de synchrone doorvoermodus. Wanneer ze worden gesynchroniseerd, ondersteunen ze failover zonder gegevensverlies. De derde replica, die gebruikmaakt van de beschikbaarheidsmodus asynchroon doorvoeren. |
FAILOVER_MODE | AUTOMATISCH | AUTOMATISCH | HANDMATIG | De synchrone doorvoerreplica's ondersteunen automatische failover en geplande handmatige failover. De replica van de synchrone doorvoerbeschikbaarheidsmodus ondersteunt alleen geforceerde handmatige failover. |
BACKUP_PRIORITY | 30 | 30 | 90 | Een hogere prioriteit, 90, wordt toegewezen aan de asynchrone doorvoerreplica dan aan de synchrone doorvoerreplica's. Back-ups worden meestal uitgevoerd op het serverexemplaren waarop de asynchrone doorvoerreplica wordt gehost. |
SECONDARY_ROLE | ( ALLOW_CONNECTIONS = NEE, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01:1433' ) |
( ALLOW_CONNECTIONS = NEE, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02:1433' ) |
( ALLOW_CONNECTIONS = READ_ONLY, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03:1433' ) |
Alleen de asynchrone doorvoerreplica fungeert als een leesbare secundaire replica. Hiermee geeft u de computernaam en het standaardpoortnummer van de database-engine (1433). Dit argument is optioneel. |
PRIMARY_ROLE | ( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (COMPUTER03) |
( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (COMPUTER03) |
( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = GEEN ) |
In de primaire rol weigeren alle replica's verbindingspogingen met leesintentie. Verbindingsaanvragen voor leesintenties worden doorgestuurd naar COMPUTER03 als de lokale replica wordt uitgevoerd onder de secundaire rol. Wanneer deze replica wordt uitgevoerd onder de primaire rol, wordt alleen-lezenroutering uitgeschakeld. Dit argument is optioneel. |
SESSION_TIMEOUT | 10 | 10 | 10 | In dit voorbeeld wordt de standaardwaarde voor sessietime-out (10) opgegeven. Dit argument is optioneel. |
Ten slotte geeft het voorbeeld de optionele LISTENER-component op om een listener voor een beschikbaarheidsgroep te maken voor de nieuwe beschikbaarheidsgroep. Er wordt een unieke DNS-naam, MyAgListenerIvP6
, opgegeven voor deze listener. De twee replica's bevinden zich op verschillende subnetten, dus de listener moet statische IP-adressen gebruiken. Voor elk van de twee beschikbaarheidsreplica's geeft de WITH IP-component een statisch IP-adres op, 2001:4898:f0:f00f::cf3c
en 2001:4898:e0:f213::4ce2
, die de IPv6-indeling gebruiken. In dit voorbeeld wordt ook het optionele argument PORT gebruikt om poort-60173
op te geven als de listenerpoort.
CREATE AVAILABILITY GROUP MyAg
WITH (
AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
FAILURE_CONDITION_LEVEL = 3,
HEALTH_CHECK_TIMEOUT = 600000
)
FOR
DATABASE ThisDatabase, ThatDatabase
REPLICA ON
'COMPUTER01' WITH
(
ENDPOINT_URL = 'TCP://COMPUTER01:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = AUTOMATIC,
BACKUP_PRIORITY = 30,
SECONDARY_ROLE (ALLOW_CONNECTIONS = NO,
READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01:1433' ),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,
READ_ONLY_ROUTING_LIST = (COMPUTER03) ),
SESSION_TIMEOUT = 10
),
'COMPUTER02' WITH
(
ENDPOINT_URL = 'TCP://COMPUTER02:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = AUTOMATIC,
BACKUP_PRIORITY = 30,
SECONDARY_ROLE (ALLOW_CONNECTIONS = NO,
READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02:1433' ),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,
READ_ONLY_ROUTING_LIST = (COMPUTER03) ),
SESSION_TIMEOUT = 10
),
'COMPUTER03' WITH
(
ENDPOINT_URL = 'TCP://COMPUTER03:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
BACKUP_PRIORITY = 90,
SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY,
READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03:1433' ),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,
READ_ONLY_ROUTING_LIST = NONE ),
SESSION_TIMEOUT = 10
);
GO
ALTER AVAILABILITY GROUP [MyAg]
ADD LISTENER 'MyAgListenerIvP6' ( WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , PORT = 60173 );
GO
Gerelateerde taken
De wizard beschikbaarheidsgroep (SQL Server Management Studio) gebruiken
Het dialoogvenster Nieuwe beschikbaarheidsgroep (SQL Server Management Studio) gebruiken
De wizard beschikbaarheidsgroep (SQL Server Management Studio) gebruiken
Zie ook
ALTER AVAILABILITY GROUP (Transact-SQL)
ALTER DATABASE SET HADR (Transact-SQL)
DROP AVAILABILITY GROUP (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)