Delen via

Wat is een AlwaysOn-beschikbaarheidsgroep?

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.

TLS 1.3-versleuteling configureren

SQL Server 2025 (17.x) Preview introduceert ondersteuning voor Tabellaire gegevensstroom 8.0 , waarmee u TLS 1.3-versleuteling kunt afdwingen voor communicatie tussen het Windows Server-failovercluster en uw AlwaysOn-beschikbaarheidsgroepreplica's. Raadpleeg Verbinding maken met strikte versleuteling om aan de slag te gaan.

Termen en definities

Termijn 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 instantie van een beschikbaarheidsgroep die een specifiek exemplaar van SQL Server host 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 u back-ups van de nieuwe primaire database herstelt naar het serverexemplaren waarop de secundaire replica wordt gehost (met 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 afzonderlijke exemplaren van SQL Server die zich op verschillende knooppunten van een WSFC-cluster bevinden, de beschikbaarheidsreplica's hosten. 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. U kunt echter elk exemplaar voor veel beschikbaarheidsgroepen gebruiken. 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 de beschikbaarheidsdatabases van die replica overnemen. 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 RESOLVEREN 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

Een beschikbaarheidsreplica heeft een eigenschap die de beschikbaarheidsmodus aangeeft. De beschikbaarheidsmodus bepaalt of de primaire replica wacht op het doorvoeren van transacties op een database totdat een bepaalde secundaire replica de transactielogboekrecords naar de schijf schrijft (het logboek wordt beperkt). 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 commit, voordat transacties worden doorgevoerd, wacht een primaire replica met synchrone commit totdat een secundaire replica met synchrone commit bevestigt dat het het logboek heeft gehard. 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 kunnen de primaire en secundaire rollen schakelen in een proces dat failover wordt genoemd. Tijdens een failover verandert de doelsecundaire replica naar de primaire rol en wordt 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, verandert deze in de secundaire rol en wordt deze een secundaire replica. De voormalige primaire databases worden secundaire databases en gegevenssynchronisatie wordt hervat.

Een failover van een beschikbaarheidsgroep op het niveau van een beschikbaarheidsreplica. Failovers treden niet op vanwege databaseproblemen zoals een database die verdacht wordt als gevolg van verlies van een gegevensbestand, verwijdering van een database of beschadiging van een transactielogboek.

Er bestaan drie vormen van failover: 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. Voor de synchrone doorvoermodus is deze ook afhankelijk van de failovermodus van de primaire replica en de secundaire doelreplica, als volgt.

  • De synchrone doorvoermodus ondersteunt twee vormen van failover: geplande handmatige failover en automatische failover, als de secundaire doelreplica momenteel wordt gesynchroniseerd met de primaire replica. De instelling van de eigenschap failovermodus voor de failoverpartners bepaalt ondersteuning voor deze vormen van failover. Als u de failovermodus instelt op handmatig op de primaire of secundaire replica, ondersteunt de secundaire replica alleen handmatige failover. Als u de failovermodus instelt op automatisch op zowel de primaire als secundaire replica's, ondersteunt de secundaire replica zowel automatische als handmatige failover.

    • geplande handmatige failover (zonder gegevensverlies)

    Een handmatige failover vindt plaats nadat een databasebeheerder een failoveropdracht heeft uitgevoerd. Hierdoor wordt een gesynchroniseerde secundaire replica naar de primaire rol gepromoveerd (met gegarandeerde gegevensbeveiliging) en verandert de primaire replica 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)

    Er wordt een automatische failover uitgevoerd als reactie op een fout. Hierdoor wordt een gesynchroniseerde secundaire replica overgezet naar de primaire rol (met gegarandeerde gegevensbescherming). Wanneer de voormalige primaire replica beschikbaar komt, verandert deze naar de secundaire rol. Voor automatische failover moeten zowel de primaire replica als de secundaire doelreplica worden uitgevoerd in de modus synchrone doorvoer, 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 is een vorm van handmatige failover, omdat u deze handmatig moet initiëren. 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 u kunt alleen handmatige failover configureren voor een beschikbaarheidsreplica die een FCI host.
  • 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.

Als een beschikbaarheidsgroep slechts twee beschikbaarheidsreplica's heeft 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 verbindingsreeks voor databasespiegeling. Deze benadering kan tijdelijk nuttig zijn nadat u een database hebt gemigreerd van databasespiegeling naar AlwaysOn-beschikbaarheidsgroepen. Voordat u 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.

Notitie

SQL Server 2025 (17.x) Preview introduceert TDS 8.0-ondersteuning, waardoor strikte TLS 1.3-versleuteling wordt afgedwongen voor verbindingen met uw AlwaysOn-beschikbaarheidsgroepreplica's en listener. Raadpleeg Verbinding maken met strikte versleuteling om aan de slag te gaan.

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 SQL Server de voorkeur niet afdwingt, 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 back-ups naar secundaire replica's van een beschikbaarheidsgroep.

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

    U kunt elke secundaire beschikbaarheidsreplica zo configureren dat alleen-lezentoegang tot de lokale databases is toegestaan, hoewel sommige bewerkingen niet volledig worden ondersteund. Met deze configuratie 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. Deze configuratie voorkomt dat er alleen-lezen-verbindingen naar de primaire replica worden gemaakt. Voor meer informatie, zie de read-only workload offloaden naar de secundaire replica van een Always On-beschikbaarheidsgroep.

    Als een beschikbaarheidsgroep momenteel een listener voor beschikbaarheidsgroepen en een of meer leesbare secundaire replica's heeft, kan SQL Server aanvragen voor leesintentieverbindingen naar een van deze aanvragen routeren (alleen-lezenroutering). Zie Verbinding maken met een AlwaysOn-listener voor beschikbaarheidsgroepenvoor meer informatie.

Sessietime-outduur

De sessie-timeout periode is een eigenschap van een beschikbaarheidsreplica die bepaalt hoelang een 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 sessie-time-outperiode, raakt de replica in een time-out. De verbinding wordt gesloten en de getime-outte replica gaat naar de status VERBONDEN 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. U kunt deze waarde configureren met een minimum van 5 seconden. Over het algemeen houdt u de time-outperiode op 10 seconden of hoger. 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.

Voor meer informatie, zie Automatische paginareparatie (Beschikbaarheidsgroepen: Databasespiegeling).

Interoperabiliteit en co-existentie met andere database-enginefuncties

AlwaysOn-beschikbaarheidsgroepen werken met de volgende functies of onderdelen van SQL Server:

Volgende stap

Aan de slag met AlwaysOn-beschikbaarheidsgroepen