Delen via

Wat is een AlwaysOn-beschikbaarheidsgroep?

  • Artikel

van toepassing op:SQL Server-

In dit artikel worden de concepten van AlwaysOn-beschikbaarheidsgroepen geïntroduceerd die centraal staan voor het configureren en beheren van een of meer beschikbaarheidsgroepen in de Enterprise-editie van SQL Server. Voor de Standard editie, raadpleeg Basic Always On-beschikbaarheidsgroepen voor één database.

De functie AlwaysOn-beschikbaarheidsgroepen is een oplossing voor hoge beschikbaarheid en herstel na noodgevallen die een alternatief op ondernemingsniveau biedt voor databasespiegeling. AlwaysOn-beschikbaarheidsgroepen maximaliseren de beschikbaarheid van een set gebruikersdatabases voor een onderneming. Een beschikbaarheidsgroep ondersteunt een failover-omgeving voor een discrete set gebruikersdatabases, ook wel beschikbaarheidsdatabasesgenoemd, die samen een failover uitvoeren. Een beschikbaarheidsgroep ondersteunt een set primaire databases voor lezen/schrijven en één tot acht sets met bijbehorende secundaire databases. Optioneel kunnen secundaire databases beschikbaar worden gesteld voor alleen-lezentoegang en/of sommige back-upbewerkingen.

Als SQL Server is ingeschakeld door Azure Arc, kunt u beschikbaarheidsgroepen weergeven in Azure Portal.

Overzicht

Een beschikbaarheidsgroep ondersteunt een gerepliceerde omgeving voor een discrete set gebruikersdatabases, ook wel beschikbaarheidsdatabasesgenoemd. U kunt een beschikbaarheidsgroep maken voor hoge beschikbaarheid (HA) of voor leesschaal. Een beschikbaarheidsgroep met hoge beschikbaarheid is een groep databases die een failover-overschakeling uitvoeren. Een leesschaal-beschikbaarheidsgroep is een groep databases die worden gekopieerd naar andere SQL Server-exemplaren voor een alleen-lezen werkbelasting. Een beschikbaarheidsgroep ondersteunt één set primaire databases en één tot acht sets met bijbehorende secundaire databases. Secundaire databases zijn geen back-ups. Ga regelmatig door met het maken van back-ups van uw databases en hun transactielogboeken.

Fooi

U kunt elk type back-up van een primaire database maken. U kunt ook logboekback-ups maken en alleen volledige back-ups van secundaire databases kopiëren. Voor meer informatie, zie Het offloaden van ondersteunde back-ups naar secundaire replica's van een beschikbaarheidsgroep.

Elke set van beschikbaarheidsdatabases wordt gehost door een beschikbaarheidsreplica. Er bestaan twee typen beschikbaarheidsreplica's: één primaire replica, die als host fungeert voor de primaire databases en één tot acht secundaire replica's, die elk als host fungeert voor een set secundaire databases en fungeert als mogelijke failoverdoelen voor de beschikbaarheidsgroep. Een failover van een beschikbaarheidsgroep op het niveau van een beschikbaarheidsreplica. Een beschikbaarheidsreplica biedt alleen redundantie op databaseniveau voor de set databases in één beschikbaarheidsgroep. Failovers worden niet veroorzaakt door databaseproblemen, zoals een database die verdacht wordt als gevolg van een verlies van een gegevensbestand of beschadiging van een transactielogboek.

De primaire replica maakt de primaire databases beschikbaar voor lees-/schrijfverbindingen van clients. De primaire replica verzendt transactielogboekrecords van elke primaire database naar elke secundaire database. Dit proces, ook wel bekend als gegevenssynchronisatie, vindt plaats op databaseniveau. Elke secundaire replica slaat de transactielogboekrecords op (verankert het logboek) en past deze vervolgens toe op de bijbehorende secundaire database. Gegevenssynchronisatie vindt plaats tussen de primaire database en elke verbonden secundaire database, onafhankelijk van de andere databases. Daarom kan een secundaire database worden onderbroken of mislukt zonder dat dit van invloed is op andere secundaire databases en kan een primaire database worden onderbroken of mislukt zonder dat dit van invloed is op andere primaire databases.

U kunt desgewenst een of meer secundaire replica's configureren ter ondersteuning van alleen-lezentoegang tot secundaire databases en u kunt elke secundaire replica configureren om back-ups op secundaire databases toe te staan.

SQL Server 2017 heeft twee verschillende architecturen geïntroduceerd voor beschikbaarheidsgroepen. AlwaysOn-beschikbaarheidsgroepen zorgen voor hoge beschikbaarheid, herstel na noodgevallen en taakverdeling met leesschaal. Voor deze beschikbaarheidsgroepen is een clusterbeheer vereist. In Windows biedt de functie failoverclustering de clusterbeheerder. In Linux kunt u Pacemaker gebruiken. De andere architectuur is een beschikbaarheidsgroep met leesschaal. Een beschikbaarheidsgroep voor het uitbreiden van leesactiviteiten biedt replica's voor alleen-lezen taken, maar heeft echter geen hoge beschikbaarheid. In een read-scale beschikbaarheidsgroep is er geen clusterbeheer, omdat failover niet automatisch plaatsvindt.

Voor het implementeren van AlwaysOn-beschikbaarheidsgroepen voor hoge beschikbaarheid in Windows is een Windows Server-failovercluster (WSFC) vereist. Elke beschikbaarheidsreplica van een bepaalde beschikbaarheidsgroep moet zich op een ander knooppunt van dezelfde WSFC bevinden. De enige uitzondering hierop is dat een beschikbaarheidsgroep tijdens de migratie naar een ander WSFC-cluster tijdelijk twee clusters kan verwisselen.

Notitie

Zie Beschikbaarheidsgroepen voor SQL Server op Linuxvoor informatie over beschikbaarheidsgroepen in Linux.

In een HA-configuratie wordt een clusterrol gemaakt voor elke beschikbaarheidsgroep die u maakt. Het WSFC-cluster bewaakt deze rol om de status van de primaire replica te evalueren. Het quorum voor AlwaysOn-beschikbaarheidsgroepen is gebaseerd op alle knooppunten in het WSFC-cluster, ongeacht of een bepaald clusterknooppunt als host fungeert voor beschikbaarheidsreplica's. In tegenstelling tot databasespiegeling is er geen witness-rol in AlwaysOn-beschikbaarheidsgroepen.

Notitie

Zie Windows Server Failover Clustering met SQL Server-voor informatie over de relatie van SQL Server AlwaysOn-onderdelen met het WSFC-cluster.

In de volgende afbeelding ziet u een beschikbaarheidsgroep die één primaire replica en vier secundaire replica's bevat. Maximaal acht secundaire replica's worden ondersteund, inclusief één primaire replica en vier secundaire replica's met synchrone commit.

diagram van een beschikbaarheidsgroep met vijf replica's.

Termen en definities

Term Beschrijving
beschikbaarheidsgroep Een container voor een set databases, beschikbaarheidsdatabases, die samen een failover uitvoeren.
beschikbaarheidsdatabank Een database die deel uitmaakt van een beschikbaarheidsgroep. Voor elke beschikbaarheidsdatabase onderhoudt de beschikbaarheidsgroep één exemplaar voor lezen/schrijven (de primaire database) en één tot acht alleen-lezen kopieën (secundaire databases).
primaire database De lees-/schrijfkopie van een beschikbaarheidsdatabase.
secundaire database Een alleen-lezen kopie van een beschikbaarheidsdatabase.
beschikbaarheidsreplica Een instantiëring van een beschikbaarheidsgroep die wordt gehost door een specifiek exemplaar van SQL Server en een lokale kopie onderhoudt van elke beschikbaarheidsdatabase die deel uitmaakt van de beschikbaarheidsgroep. Er bestaan twee typen beschikbaarheidsreplica's: één primaire replica en één tot acht secundaire replica's.
primaire replica De beschikbaarheidsreplica die de primaire databases beschikbaar maakt voor lees-/schrijfverbindingen van clients en verzendt transactielogboekrecords voor elke primaire database naar elke secundaire replica.
secundaire replica Een beschikbaarheidsreplica die een secundaire kopie van elke beschikbaarheidsdatabase onderhoudt en fungeert als een mogelijk failoverdoel voor de beschikbaarheidsgroep. Optioneel kan een secundaire replica alleen-lezentoegang tot secundaire databases ondersteunen en het maken van back-ups op secundaire databases mogelijk maken.
listener voor beschikbaarheidsgroep Een servernaam waarmee clients verbinding kunnen maken om toegang te krijgen tot een database in een primaire of secundaire replica van een beschikbaarheidsgroep. Listeners van beschikbaarheidsgroepen leiden binnenkomende verbindingen naar de primaire replica of naar een alleen-lezen secundaire replica.

Beschikbaarheidsdatabases

Als u een database wilt toevoegen aan een beschikbaarheidsgroep, moet de database een online database met lees-/schrijfbewerkingen zijn die aanwezig is op het serverexemplaren waarop de primaire replica wordt gehost. Wanneer u een database toevoegt, wordt de beschikbaarheidsgroep toegevoegd als een primaire database, terwijl deze beschikbaar blijft voor clients. Er bestaat geen bijbehorende secundaire database totdat back-ups van de nieuwe primaire database worden hersteld naar het serverexemplaren waarop de secundaire replica wordt gehost (met BEHULP van RESTORE WITH NORECOVERY). De nieuwe secundaire database heeft de status HERSTELLEN totdat deze is opgenomen in de beschikbaarheidsgroep. Zie Gegevensverplaatsing starten op een AlwaysOn Secondary Database (SQL Server)voor meer informatie.

Het samenvoegen plaatst de secundaire database in de ONLINE-status en start de gegevenssynchronisatie met de bijbehorende primaire database. gegevenssynchronisatie is het proces waarmee wijzigingen in een primaire database worden gereproduceerd op een secundaire database. Gegevenssynchronisatie omvat de primaire database die transactielogboekrecords naar de secundaire database verzendt.

Belangrijk

Een beschikbaarheidsdatabase wordt in Transact-SQL, PowerShell en SQL Server Management Objects soms een databasereplica genoemd. De term 'databasereplica' wordt bijvoorbeeld gebruikt in de namen van de dynamische beheerweergaven van AlwaysOn die informatie retourneren over beschikbaarheidsdatabases: sys.dm_hadr_database_replica_states en sys.dm_hadr_database_replica_cluster_states. In SQL Server Books Online verwijst de term 'replica' echter meestal naar beschikbaarheidsreplica's. Bijvoorbeeld: 'primaire replica' en 'secundaire replica' verwijzen altijd naar beschikbaarheidsreplica's.

Beschikbaarheidsreplica's

Elke beschikbaarheidsgroep definieert een set van twee of meer failoverpartners, ook wel beschikbaarheidsreplica's genoemd. beschikbaarheidsreplica's zijn onderdelen van de beschikbaarheidsgroep. Elke beschikbaarheidsreplica fungeert als host voor een kopie van de beschikbaarheidsdatabases in de beschikbaarheidsgroep. Voor een bepaalde beschikbaarheidsgroep moeten de beschikbaarheidsreplica's worden gehost door afzonderlijke exemplaren van SQL Server die zich op verschillende knooppunten van een WSFC-cluster bevinden. Elk van deze serverexemplaren moet zijn ingeschakeld voor AlwaysOn.

SQL Server 2019 (15.x) verhoogt het maximum aantal synchrone replica's naar 5, tot 3 in SQL Server 2017 (14.x). U kunt deze groep van vijf replica's configureren voor automatische failover binnen de groep. Er is één primaire replica, plus vier synchrone secundaire replica's.

Een bepaald exemplaar kan slechts één beschikbaarheidsreplica per beschikbaarheidsgroep hosten. Elk exemplaar kan echter worden gebruikt voor veel beschikbaarheidsgroepen. Een bepaald exemplaar kan een zelfstandig exemplaar of een exemplaar van een SQL Server-failovercluster (FCI) zijn. Als u redundantie op serverniveau nodig hebt, gebruikt u failoverclusterexemplaren.

Aan elke beschikbaarheidsreplica wordt een initiële rol toegewezen: de primaire rol of de secundaire rol, die wordt overgenomen door de beschikbaarheidsdatabases van die replica. De rol van een bepaalde replica bepaalt of er lees-schrijfdatabases of alleen-lezendatabases worden gehost. Aan één replica, ook wel de primaire replicagenoemd, wordt de primaire rol toegewezen en worden databases voor lezen/schrijven gehost, die primaire databasesworden genoemd. Ten minste één andere replica, ook wel een secundaire replicagenoemd, wordt de secundaire rol toegewezen. Een secundaire replica host alleen-lezen-databases, die secundaire databases worden genoemd.

Notitie

Wanneer de rol van een beschikbaarheidsreplica onbepaald is, zoals tijdens een failover, bevinden de databases zich tijdelijk in de status NIET SYNCHRONISEREN. De rol wordt ingesteld op OPLOSSEN TOTdat de rol van de beschikbaarheidsreplica is opgelost. Als een beschikbaarheidsreplica de primaire rol aanneemt, worden de bijbehorende databases de primaire databases. Als een beschikbaarheidsreplica aan de secundaire rol wordt toegewezen, worden de bijbehorende databases secundair.

Beschikbaarheidsmodi

De beschikbaarheidsmodus is een eigenschap van elke beschikbaarheidsreplica. De beschikbaarheidsmodus bepaalt of de primaire replica wacht op het doorvoeren van transacties in een database, totdat een bepaalde secundaire replica de transactielogboekrecords naar de schijf heeft geschreven (het logboek is gehard). AlwaysOn-beschikbaarheidsgroepen ondersteunen twee beschikbaarheidsmodi: asynchrone doorvoermodus en synchrone doorvoermodus.

  • Asynchrone doorvoermodus

    Een beschikbaarheidsreplica die gebruikmaakt van deze beschikbaarheidsmodus wordt een asynchrone doorvoerreplicagenoemd. Onder de asynchrone doorvoermodus worden transacties door de primaire replica doorgevoerd zonder te wachten op bevestiging van secundaire replica's met asynchrone doorvoer om hun transactielogboeken te beveiligen. De Asynchrone doorvoermodus minimaliseert de transactielatentie op de secundaire databases, maar stelt ze in staat om achter te blijven bij de primaire databases, waardoor gegevensverlies mogelijk is.

  • synchrone doorvoermodus

    Een beschikbaarheidsreplica die gebruikmaakt van deze beschikbaarheidsmodus wordt een synchrone commit-replicagenoemd. In de modus synchrone doorvoer, voordat transacties worden doorgevoerd, wacht een synchrone doorvoer primaire replica op een secundaire replica met synchrone doorvoer om te bevestigen dat deze klaar is met het beveiligen van het logboek. Synchroon doorvoeren zorgt ervoor dat wanneer een bepaalde secundaire database is gesynchroniseerd met de primaire database, vastgelegde transacties volledig zijn beveiligd. Deze beveiliging komt ten koste van een verhoogde transactielatentie. Optioneel heeft SQL Server 2017 een vereiste gesynchroniseerde secundaire secundaire bestanden geïntroduceerd functie om de veiligheid tegen de latentiekosten verder te verhogen wanneer dat gewenst is. De functie REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT kan worden ingeschakeld om een opgegeven aantal synchrone replica's te vereisen om een transactie door te voeren voordat een primaire replica mag worden doorgevoerd.

Zie Verschillen tussen beschikbaarheidsmodi voor een AlwaysOn-beschikbaarheidsgroepvoor meer informatie.

Typen van failover

Binnen de context van een sessie tussen de primaire replica en een secundaire replica zijn de primaire en secundaire rollen mogelijk uitwisselbaar in een proces dat bekend staat als failover. Tijdens een failover gaat de secundaire doelreplica over naar de primaire rol en wordt deze de nieuwe primaire replica. De nieuwe primaire replica brengt de databases online als de primaire databases en clienttoepassingen kunnen er verbinding mee maken. Wanneer de voormalige primaire replica beschikbaar is, wordt deze overgezet naar de secundaire rol en wordt deze een secundaire replica. De voormalige primaire databases worden secundaire databases en gegevenssynchronisatie wordt hervat.

Een beschikbaarheidsgroep voert een failover uit op het niveau van een beschikbaarheidsreplica. Failovers worden niet veroorzaakt door databaseproblemen, zoals een database die verdacht wordt als gevolg van een verlies van een gegevensbestand, het verwijderen van een database of beschadiging van een transactielogboek.

Drie vormen van failover bestaan automatisch, handmatig en geforceerd (met mogelijk gegevensverlies). De vorm of vormen van failover die door een bepaalde secundaire replica worden ondersteund, zijn afhankelijk van de beschikbaarheidsmodus en, voor synchronous-commitmodus, van de failovermodus van de primaire replica en de doel secundaire replica als volgt.

  • Synchrone commit-modus ondersteunt twee vormen van failover:geplande handmatige failover en automatische failover, als de secundaire doelreplica momenteel gesynchroniseerd is met de primaire replica. De ondersteuning voor deze vormen van failover is afhankelijk van de instelling van de failovermodus eigenschap bij de failoverpartners. Als de failovermodus is ingesteld op 'handmatig' op de primaire of secundaire replica, wordt alleen handmatige failover ondersteund voor die secundaire replica. Als de failovermodus is ingesteld op 'automatisch' op zowel de primaire als de secundaire replica, worden zowel automatische als handmatige failover ondersteund op die secundaire replica.

    • geplande handmatige failover (zonder gegevensverlies)

      Een handmatige failover treedt op nadat een databasebeheerder een failoveropdracht heeft uitgevoerd en ervoor zorgt dat een gesynchroniseerde secundaire replica overgaat naar de primaire rol (met gegarandeerde gegevensbeveiliging) en de primaire replica om over te stappen naar de secundaire rol. Een handmatige failover vereist dat zowel de primaire replica als de secundaire doelreplica worden uitgevoerd in de modus synchrone doorvoer en dat de secundaire replica al moet worden gesynchroniseerd.

    • Automatische failover (zonder gegevensverlies)

      Een automatische failover treedt op als reactie op een fout waardoor een gesynchroniseerde secundaire replica wordt overgezet naar de primaire rol (met gegarandeerde gegevensbeveiliging). Wanneer de voormalige primaire replica beschikbaar wordt, wordt deze overgezet naar de secundaire rol. Automatische failover vereist dat zowel de primaire replica als de secundaire doelreplica draaien in de synchrone-commit-modus, waarbij de failovermodus is ingesteld op Automatisch. Bovendien moet de secundaire replica al worden gesynchroniseerd, WSFC-quorum hebben en voldoen aan de voorwaarden die zijn opgegeven door het flexibele failoverbeleid van de beschikbaarheidsgroep.

  • Onder de asynchrone commit-modus is de enige vorm van failover een gedwongen handmatige failover (met mogelijk gegevensverlies), die meestal gedwongen failoverwordt genoemd. Geforceerde failover wordt beschouwd als een vorm van handmatige failover, omdat deze alleen handmatig kan worden gestart. Geforceerde failover is een optie voor herstel na noodgevallen. Dit is de enige vorm van failover die mogelijk is wanneer de secundaire doelreplica niet wordt gesynchroniseerd met de primaire replica.

Zie failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

Belangrijk

  • 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.
  • Als u een opdracht voor geforceerde failover op een gesynchroniseerde secundaire replica uitvoert, gedraagt de secundaire replica zich hetzelfde als voor een geplande handmatige failover.

Voordelen

AlwaysOn-beschikbaarheidsgroepen bieden een uitgebreide set opties waarmee de beschikbaarheid van databases wordt verbeterd en het resourcegebruik wordt verbeterd. De belangrijkste onderdelen zijn als volgt:

Clientverbindingen

U kunt clientconnectiviteit tot stand brengen met de primaire replica van een bepaalde beschikbaarheidsgroep door een beschikbaarheidsgroepluisteraar te maken. Een listener voor beschikbaarheidsgroepen biedt een set resources die is gekoppeld aan een bepaalde beschikbaarheidsgroep om clientverbindingen naar de juiste beschikbaarheidsreplica te leiden.

Een listener voor beschikbaarheidsgroepen is gekoppeld aan een unieke DNS-naam die fungeert als een naam van een virtueel netwerk (VNN), een of meer virtuele IP-adressen (VIP's) en een TCP-poortnummer. Zie Verbinding maken met een AlwaysOn-listener voor beschikbaarheidsgroepenvoor meer informatie.

Tip

Als een beschikbaarheidsgroep slechts twee beschikbaarheidsreplica's bezit en niet is geconfigureerd om leestoegang tot de secundaire replica toe te staan, kunnen clients verbinding maken met de primaire replica met behulp van een databasespiegelingsreeks. Deze benadering kan tijdelijk nuttig zijn nadat u een database hebt gemigreerd van databasespiegeling naar AlwaysOn-beschikbaarheidsgroepen. Voordat u extra secundaire replica's toevoegt, moet u een listener voor beschikbaarheidsgroepen maken voor de beschikbaarheidsgroep en uw toepassingen bijwerken om de netwerknaam van de listener te gebruiken.

Actieve secundaire replica's

AlwaysOn-beschikbaarheidsgroepen ondersteunen actieve secundaire replica's. Actieve secundaire mogelijkheden omvatten ondersteuning voor:

  • Back-up operaties uitvoeren op secundaire replica's

    De secundaire replica's ondersteunen het uitvoeren van logboekback-ups en alleen-kopiëren back-ups van een volledige database, bestand of bestandsgroep. U kunt de beschikbaarheidsgroep configureren om een voorkeur op te geven voor waar back-ups moeten worden uitgevoerd. Het is belangrijk om te begrijpen dat de voorkeur niet wordt afgedwongen door SQL Server, dus dit heeft geen effect op ad-hocback-ups. De interpretatie van deze voorkeur is afhankelijk van de logica, indien aanwezig, die u scriptt in uw back-uptaken voor elk van de databases in een bepaalde beschikbaarheidsgroep. Voor een afzonderlijke beschikbaarheidsreplica kunt u uw prioriteit opgeven voor het uitvoeren van back-ups op deze replica ten opzichte van de andere replica's in dezelfde beschikbaarheidsgroep. Voor meer informatie, zie het offloaden van ondersteunde kopieën naar secundaire replica's van een beschikbaarheidsgroep.

  • alleen-lezentoegang tot een of meer secundaire replica's (leesbare secundaire replica's)

    Elke secundaire beschikbaarheidsreplica kan worden geconfigureerd om alleen-lezentoegang tot de lokale databases toe te staan, hoewel sommige bewerkingen niet volledig worden ondersteund. Hiermee voorkomt u pogingen om lees-/schrijfverbindingen naar de secundaire replica uit te proberen. Het is ook mogelijk om alleen-lezenworkloads op de primaire replica te voorkomen door alleen lees-/schrijftoegang toe te staan. Hiermee voorkomt u dat alleen-lezenverbindingen naar de primaire replica worden gemaakt. Zie voor meer informatie over het verplaatsen van een alleen-lezen workload naar een secundaire replica van een Always On-beschikbaarheidsgroep.

    Als een beschikbaarheidsgroep momenteel een listener voor een beschikbaarheidsgroep en een of meer leesbare secundaire replica's bezit, kan SQL Server verbindingsaanvragen met leesintensies routeren naar een van deze replica's (alleen-lezen routering). Zie Verbinding maken met een AlwaysOn-listener voor beschikbaarheidsgroepenvoor meer informatie.

Sessietime-outduur

De sessietime-outperiode is een eigenschap van de beschikbaarheidsreplica die bepaalt hoelang de verbinding met een andere beschikbaarheidsreplica inactief kan blijven voordat de verbinding wordt gesloten. De primaire en secundaire replica's pingen elkaar om aan te geven dat ze nog actief zijn. Het ontvangen van een ping van de andere replica tijdens de time-outperiode geeft aan dat de verbinding nog steeds is geopend en dat de serverexemplaren communiceren. Bij het ontvangen van een ping stelt een beschikbaarheidsreplica de sessietime-outteller voor die verbinding opnieuw in.

De time-outperiode van de sessie voorkomt dat een van beide replica's voor onbepaalde tijd wacht om een ping van de andere replica te ontvangen. Als er geen ping wordt ontvangen van de andere replica binnen de time-outperiode van de sessie, treedt er een time-out op voor de replica. De verbinding is gesloten en de time-outreplica krijgt de status VERBROKEN. Zelfs als een niet-verbonden replica is geconfigureerd voor de synchrone doorvoermodus, wachten transacties niet totdat die replica opnieuw verbinding maakt en opnieuw synchroniseert.

De standaardperiode voor sessietime-outs voor elke beschikbaarheidsreplica is 10 seconden. Deze waarde kan door de gebruiker worden geconfigureerd, met minimaal 5 seconden. Over het algemeen raden we u aan om de time-outperiode op 10 seconden of hoger te houden. Als u de waarde instelt op minder dan 10 seconden, bestaat er een kans dat een zwaar belaste systeem onterecht een fout zou verklaren.

Notitie

In de oplossingsrol is de time-outperiode van de sessie niet van toepassing omdat pingen niet plaatsvindt.

Automatisch paginaherstel

Elke beschikbaarheidsreplica probeert automatisch te herstellen van beschadigde pagina's in een lokale database door bepaalde typen fouten op te lossen die voorkomen dat een gegevenspagina wordt gelezen. Als een secundaire replica een pagina niet kan lezen, vraagt de replica om een nieuwe kopie van de pagina van de primaire replica. Als de primaire replica een pagina niet kan lezen, verzendt de primaire replica een verzoek voor een nieuwe kopie naar alle secundaire replica's en wordt de pagina opgehaald van de eerste die reageert. Als deze aanvraag slaagt, wordt de onleesbare pagina vervangen door de kopie, waardoor de fout meestal wordt opgelost.

Zie Automatische paginaherstel (beschikbaarheidsgroepen: databasespiegeling)voor meer informatie.

Interoperabiliteit en co-existentie met andere database-enginefuncties

AlwaysOn-beschikbaarheidsgroepen kunnen worden gebruikt met de volgende functies of onderdelen van SQL Server:

Volgende stap

Aan de slag met AlwaysOn-beschikbaarheidsgroepen