Wat is een Always On beschikbaarheidsgroep?

• 04/29/2020
• 14 minuten om te lezen
• • c
  • M
  • D
  • B
  • v
  • +13

Geldt voor: SQL Server (alle ondersteunde versies)

Dit onderwerp introduceert de Always On beschikbaarheidsgroepen concepten die centraal staan voor het configureren en beheren van een of meer beschikbaarheidsgroepen in SQL Server. Voor een overzicht van de voordelen van beschikbaarheidsgroepen en een overzicht van de terminologie voor Always On-beschikbaarheidsgroepen, raadpleegt u Always On Availability Groups (SQL Server).

Een beschikbaarheidsgroep ondersteunt een gerepliceerde omgeving voor een afzonderlijke set gebruikersdatabases, bekend als beschikbaarheidsdatabases. U kunt een beschikbaarheidsgroep maken voor hoge beschikbaarheid (HA) of voor read-scale. Een HA-beschikbaarheidsgroep is een groep databases die samen fail-over gaan. Een beschikbaarheidsgroep voor read-scale is een groep databases die worden gekopieerd naar andere instanties van SQL Server voor een alleen-lezen werkbelasting. Een beschikbaarheidsgroep ondersteunt één set primaire databases en één tot acht sets van corresponderende secundaire databases. Secundaire databases zijn geen back-ups. Blijf regelmatig back-ups maken van uw databases en hun transactielogboeken.

Elke set van beschikbaarheidsdatabases wordt gehost door een beschikbaarheidsreplica. Er bestaan twee soorten beschikbaarheidsreplica’s: een enkele primaire replica, die de primaire databases host, en een tot acht secundaire replica’s, die elk een set secundaire databases hosten en dienen als een potentieel failover-doel voor de beschikbaarheidsgroep. Een beschikbaarheidsgroep failovert op het niveau van een beschikbaarheidsreplica. Een beschikbaarheidsreplica biedt alleen redundantie op databaseniveau voor de set van databases in één beschikbaarheidsgroep. Failovers worden niet veroorzaakt door databaseproblemen, zoals een database die verdacht wordt door het verlies van een gegevensbestand of corruptie van een transactielog.

De primaire replica maakt de primaire databases beschikbaar voor read-write-verbindingen van clients. De primaire replica stuurt transactielogboekrecords van elke primaire database naar elke secundaire database. Dit proces – bekend als datasynchronisatie – vindt plaats op databaseniveau. Elke secundaire replica slaat de transactielogboekrecords op (hardt het logboek) en past ze vervolgens toe op zijn corresponderende secundaire database. Gegevenssynchronisatie vindt plaats tussen de primaire database en elke aangesloten secundaire database, onafhankelijk van de andere databases. Daarom kan een secundaire database worden opgeschort of uitvallen zonder dat dit gevolgen heeft voor andere secundaire databases, en kan een primaire database worden opgeschort of uitvallen zonder dat dit gevolgen heeft voor andere primaire databases.

Optioneel kunt u een of meer secundaire replica’s configureren om alleen-lezen toegang tot secundaire databases te ondersteunen, en u kunt elke secundaire replica configureren om back-ups op secundaire databases toe te staan.

SQL Server 2017 introduceert twee verschillende architecturen voor beschikbaarheidsgroepen. Always On beschikbaarheidsgroepen bieden hoge beschikbaarheid, disaster recovery, en read-scale balancing. Deze beschikbaarheidsgroepen vereisen een clustermanager. In Windows zorgt failover clustering voor de clustermanager. In Linux kunt u Pacemaker gebruiken. De andere architectuur is een read-scale beschikbaarheidsgroep. Een read-scale availability group levert replica’s voor read-only workloads, maar geen hoge beschikbaarheid. In een read-scale beschikbaarheidsgroep is er geen clustermanager.

Het uitrollen van Always On beschikbaarheidsgroepen voor HA op Windows vereist een Windows Server Failover Cluster (WSFC). Elke beschikbaarheidsreplica van een bepaalde beschikbaarheidsgroep moet zich op een andere node van dezelfde WSFC bevinden. De enige uitzondering is dat een beschikbaarheidsgroep tijdens een migratie naar een ander WSFC-cluster tijdelijk tussen twee clusters mag zweven.

In een HA-configuratie wordt een clusterrol gemaakt voor elke beschikbaarheidsgroep die u maakt. Het WSFC-cluster bewaakt deze rol om de gezondheid van de primaire replica te evalueren. Het quorum voor Always On beschikbaarheidsgroepen is gebaseerd op alle nodes in het WSFC-cluster, ongeacht of een bepaalde clusterknooppunt beschikbaarheidsreplica’s host. In tegenstelling tot databasespiegeling is er geen getuige-rol in Always On-beschikbaarheidsgroepen.

De volgende illustratie toont een beschikbaarheidsgroep die één primaire replica en vier secundaire replica’s bevat. Er worden maximaal acht secundaire replica’s ondersteund, waaronder één primaire replica en twee synchrone secundaire replica’s.

Beschikbaarheidsdatabases

Om een database aan een beschikbaarheidsgroep toe te voegen, moet de database een online, lees-schrijf-database zijn die bestaat op de serverinstantie die de primaire replica huisvest. Als u een database toevoegt, wordt deze toegevoegd aan de beschikbaarheidsgroep als een primaire database, terwijl deze beschikbaar blijft voor clients. Er bestaat geen overeenkomstige secundaire database totdat back-ups van de nieuwe primaire database zijn teruggezet op de serverinstantie waarop de secundaire replica staat (met RESTORE WITH NORECOVERY). De nieuwe secundaire database bevindt zich in de status RESTORING totdat deze wordt toegevoegd aan de beschikbaarheidsgroep. Zie Dataverplaatsing starten op een Altijd-aan secundaire database (SQL Server) voor meer informatie.

Door te koppelen komt de secundaire database in de status ONLINE en wordt de gegevenssynchronisatie met de bijbehorende primaire database gestart. Gegevenssynchronisatie is het proces waarbij wijzigingen in een primaire database worden gereproduceerd in een secundaire database. Gegevenssynchronisatie houdt in dat de primaire database transactielogboekrecords naar de secundaire database stuurt.

Beschikbaarheidsreplica’s

Elke beschikbaarheidsgroep definieert een set van twee of meer failover-partners die bekend staan als beschikbaarheidsreplica’s. Beschikbaarheidsreplica’s zijn onderdelen van de beschikbaarheidsgroep. Elke beschikbaarheidsreplica bevat een kopie van de beschikbaarheidsdatabases in de beschikbaarheidsgroep. Voor een bepaalde beschikbaarheidsgroep moeten de beschikbaarheidsreplica’s worden gehost door afzonderlijke instances van SQL Server die zich op verschillende knooppunten van een WSFC-cluster bevinden. Elk van deze serverinstanties moet zijn ingeschakeld voor Always On.

Een instantie kan slechts één beschikbaarheidsreplica per beschikbaarheidsgroep hosten. Elke instance kan echter voor veel beschikbaarheidsgroepen worden gebruikt. Een bepaalde instance kan een stand-alone instance of een SQL Server failover cluster instance (FCI) zijn. Als u redundantie op serverniveau nodig hebt, gebruikt u Failover Cluster Instances.

Elke beschikbaarheidsreplica krijgt een initiële rol toegewezen – de primaire rol of de secundaire rol, die wordt geërfd door de beschikbaarheidsdatabases van die replica. De rol van een bepaalde replica bepaalt of het read-write databases of read-only databases host. Eén replica, bekend als de primaire replica, krijgt de primaire rol toebedeeld en host read-write databases, die bekend staan als primaire databases. Ten minste één andere replica, bekend als een secundaire replica, krijgt de secundaire rol toegewezen. Een secundaire replica host alleen-lezen databases, die bekend staan als secundaire databases.

Beschikbaarheidsmodi

De beschikbaarheidsmodus is een eigenschap van elke beschikbaarheidsreplica. De beschikbaarheidsmodus bepaalt of de primaire replica wacht met het vastleggen van transacties op een database totdat een bepaalde secundaire replica de transactielogboekrecords naar schijf heeft geschreven (hardened the log). Always On beschikbaarheidsgroepen ondersteunt twee beschikbaarheidsmodi – asynchrone-commit modus en synchrone-commit modus.

• Asynchrone-commit modus

  Een beschikbaarheidsreplica die deze beschikbaarheidsmodus gebruikt, staat bekend als een asynchrone-commit replica. In de asynchrone-commit modus committeert de primaire replica transacties zonder te wachten op een bevestiging dat een asynchrone-commit secundaire replica het logboek heeft gehard. Asynchrone-commit modus minimaliseert transactie latency op de secundaire databases, maar staat hen toe om achter te lopen op de primaire databases, waardoor enig gegevensverlies mogelijk is.

• Synchrone-commit modus

  Een beschikbaarheidsreplica die deze beschikbaarheidsmodus gebruikt, staat bekend als een synchrone-commit replica. Onder synchrone-commit modus wacht een synchrone-commit primaire replica, voordat hij transacties committeert, op een synchrone-commit secundaire replica om te bevestigen dat hij klaar is met het harden van het logboek. Synchrone-commitmodus zorgt ervoor dat zodra een bepaalde secundaire database is gesynchroniseerd met de primaire database, vastgelegde transacties volledig zijn beschermd. Deze bescherming gaat ten koste van een verhoogde transactie latency.

Voor meer informatie, zie Beschikbaarheid Modes (Altijd Aan Beschikbaarheid Groepen).

Soorten failover

In de context van een sessie tussen de primaire replica en een secundaire replica, zijn de primaire en secundaire rollen potentieel uitwisselbaar in een proces dat failover wordt genoemd. Tijdens een failover gaat de target secundaire replica over naar de primaire rol, en wordt de nieuwe primaire replica. De nieuwe primaire replica brengt zijn databases online als de primaire databases, en client applicaties kunnen er verbinding mee maken. Wanneer de voormalige primaire replica beschikbaar is, gaat deze over naar de secundaire rol, en wordt zo een secundaire replica. De voormalige primaire databases worden secundaire databases en de gegevenssynchronisatie wordt hervat.

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 wordt ondersteund, hangt af van zijn beschikbaarheidsmodus, en, voor de modus synchroon-commit, van de failover-modus op de primaire replica en de secundaire doel-replica, als volgt.

• Synchrone-commit-modus ondersteunt twee vormen van failover-geplande handmatige failover en automatische failover, als de secundaire doel-replica momenteel is gesynchroniseerd met de primaire replica. De ondersteuning voor deze vormen van failover hangt af van de instelling van de failover mode eigenschap op de failover partners. Als failover mode is ingesteld op “manual” op ofwel de primaire of secundaire replica, dan wordt alleen handmatige failover ondersteund voor die secundaire replica. Als de failover-modus is ingesteld op “automatisch” op zowel de primaire als de secundaire replica’s, wordt zowel automatische als handmatige failover ondersteund op die secundaire replica.

  • Geplande handmatige failover (zonder gegevensverlies)

    Een handmatige failover treedt op nadat een databasebeheerder een failover-opdracht geeft en ervoor zorgt dat een gesynchroniseerde secundaire replica overgaat naar de primaire rol (met gegarandeerde gegevensbescherming) en dat de primaire replica overgaat naar de secundaire rol. Een handmatige failover vereist dat zowel de primaire replica als de secundaire doel-replica onder de modus synchroon-commit draaien, en de secundaire replica moet al zijn gesynchroniseerd.

  • Automatische failover (zonder gegevensverlies)

    Een automatische failover treedt op als reactie op een storing die ervoor zorgt dat een gesynchroniseerde secundaire replica naar de primaire rol overgaat (met gegarandeerde gegevensbescherming). Wanneer de voormalige primaire replica beschikbaar komt, gaat deze over naar de secundaire rol. Automatische failover vereist dat zowel de primaire replica als de secundaire doel-replica draaien onder synchrone-commit modus met de failover modus ingesteld op “Automatisch”. Daarnaast moet de secundaire replica al gesynchroniseerd zijn, WSFC quorum hebben, en voldoen aan de voorwaarden die zijn gespecificeerd door de flexibele failover policy van de beschikbaarheidsgroep.

    Belangrijk

    SQL Server Failover Cluster Instances (FCI’s) ondersteunen geen automatische failover door beschikbaarheidsgroepen, dus elke beschikbaarheidsreplica die wordt gehost door een FCI kan alleen worden geconfigureerd voor handmatige failover.

  Note

  Note dat als u een geforceerde failover-opdracht uitvoert op een gesynchroniseerde secundaire replica, de secundaire replica zich hetzelfde gedraagt als bij een geplande handmatige failover.

• In de asynchrone-commit-modus is de enige vorm van failover een geforceerde handmatige failover (met mogelijk gegevensverlies), die gewoonlijk geforceerde failover wordt genoemd. Geforceerde failover wordt beschouwd als een vorm van handmatige failover omdat deze alleen handmatig kan worden geïnitieerd. Geforceerde failover is een optie voor disaster recovery. Het is de enige vorm van failover die mogelijk is wanneer de secundaire doel-replica niet is gesynchroniseerd met de primaire replica.

Voor meer informatie, zie Failover en Failover Modes (Always On Availability Groups).

Clientverbindingen

U kunt clientconnectiviteit bieden aan de primaire replica van een bepaalde availability group door een availability group listener te maken. Een availability group listener biedt een set resources die is gekoppeld aan een bepaalde availability group om clientverbindingen naar de juiste availability replica te leiden.

Een availability group listener is gekoppeld aan een unieke DNS-naam die dient als een virtuele netwerknaam (VNN), een of meer virtuele IP-adressen (VIP’s), en een TCP-poortnummer. Zie voor meer informatie Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Actieve secundaire replica’s

Always On beschikbaarheidsgroepen ondersteunt actieve secundaire replica’s. Actieve secundaire mogelijkheden omvatten ondersteuning voor:

• Het uitvoeren van back-upbewerkingen op secundaire replica’s

  De secundaire replica’s ondersteunen het uitvoeren van logback-ups en back-ups met alleen kopieën van een volledige database, bestand of bestandsgroep. U kunt de beschikbaarheidsgroep configureren om een voorkeur op te geven voor de plaats waar back-ups moeten worden uitgevoerd. Het is belangrijk te begrijpen dat de voorkeur niet wordt afgedwongen door SQL Server, dus het heeft geen invloed op ad-hoc back-ups. De interpretatie van deze voorkeur is afhankelijk van de logica, indien aanwezig, die u script in uw back jobs voor elk van de databases in een bepaalde beschikbaarheidsgroep. Voor een individuele 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. Zie Actieve secundaire systemen voor meer informatie: Backup on Secondary Replicas (Always On Availability Groups).

• Read-only toegang tot een of meer secundaire replica’s (leesbare secundaire replica’s)

  Elke secundaire beschikbaarheidsreplica kan worden geconfigureerd om alleen read-only toegang tot zijn lokale databases toe te staan, hoewel sommige operaties niet volledig worden ondersteund. Dit voorkomt lees-schrijf verbindingspogingen naar de secundaire replica. Het is ook mogelijk om read-only workloads op de primaire replica te voorkomen door alleen read-write toegang toe te staan. Dit zal voorkomen dat alleen-lezen verbindingen worden gemaakt naar de primaire replica. Voor meer informatie, zie Actieve Secondaries: Readable Secondary Replicas (Always On Availability Groups).

  Als een availability group momenteel een availability group listener en een of meer readable secondary replica’s bezit, kan SQL Server read-intent verbindingsverzoeken naar een van hen routeren (read-only routing). Zie voor meer informatie Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Session-timeout period

De session-timeout period is een availability-replica eigenschap die bepaalt hoe lang de verbinding met een andere availability replica inactief kan blijven voordat de verbinding wordt gesloten. De primaire en secundaire replica’s pingen elkaar om aan te geven dat ze nog steeds actief zijn. Het ontvangen van een ping van de andere replica tijdens de time-out periode geeft aan dat de verbinding nog steeds open is en dat de serverinstanties met elkaar communiceren. Bij het ontvangen van een ping, reset een beschikbaarheids replica zijn sessie-timeout teller op die verbinding.

De sessie-timeout periode voorkomt dat een van beide replica’s oneindig kan wachten op het ontvangen van een ping van de andere replica. Als er geen ping wordt ontvangen van de andere replica binnen de sessie-timeout periode, gaat de replica time-out. De verbinding wordt gesloten, en de replica met de time-out gaat naar de status DISCONNECTED. Zelfs als een gedisconnecte replica is geconfigureerd voor synchroon-commit modus, zullen transacties niet wachten op die replica om opnieuw verbinding te maken en te synchroniseren.

De standaard sessie-time-out periode voor elke beschikbaarheidsreplica is 10 seconden. Deze waarde is door de gebruiker te configureren, met een minimum van 5 seconden. Over het algemeen raden wij u aan om de time-out periode op 10 seconden of hoger te houden. Het instellen van de waarde op minder dan 10 seconden creëert de mogelijkheid dat een zwaar belast systeem een valse mislukking verklaart.

Automatisch paginaherstel

Elke beschikbaarheidsreplica probeert automatisch te herstellen van beschadigde pagina’s op een lokale database door bepaalde soorten fouten op te lossen die het lezen van een gegevenspagina verhinderen. Als een secundaire replica een pagina niet kan lezen, vraagt de replica een verse kopie van de pagina aan bij de primaire replica. Als de primaire replica een pagina niet kan lezen, zendt de replica een verzoek om een verse kopie naar alle secundaire replica’s en krijgt de pagina van de eerste die reageert. Als dit verzoek slaagt, wordt de onleesbare pagina vervangen door de kopie, waardoor de fout meestal wordt opgelost.

Voor meer informatie, zie Automatisch paginaherstel (Availability Groups: Database Mirroring).

Verwante taken

• Getting Started with Always On Availability Groups (SQL Server)

Verwante inhoud

• Blogs:

  Always On – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases

  SQL Server Always On Team Blogs: De officiële SQL Server Always On Team Blog

  CSS SQL Server Engineers Blogs

• Videos:

  Microsoft SQL Server Code-Named “Denali” Always On Series,Deel 1: Introducing the Next Generation High Availability Solution

  Microsoft SQL Server Code-Named “Denali” Always On Series,Deel 2: Building a Mission-Critical High Availability Solution Using Always On

• Whitepapers:

  Microsoft SQL Server Always On Solutions Guide for High Availability and Disaster Recovery

  Microsoft White Papers voor SQL Server 2012

  SQL Server Customer Advisory Team Whitepapers

Zie ook

Beschikbaarheidsmodi (Always On Availability Groups)
Failover en Failover Modes (Always On Availability Groups)
Overzicht van Transact-SQL Statements voor Altijd Aan Beschikbaarheid Groepen (SQL Server)
Overzicht van PowerShell Cmdlets voor Altijd Aan Beschikbaarheid Groepen (SQL Server)
Hoge Beschikbaarheid Ondersteuning voor In-Memory OLTP databases
Vereisten, Beperkingen en Aanbevelingen voor Altijd Aan Beschikbaarheid Groepen (SQL Server)
Creatie en Configuratie van Beschikbaarheid Groepen (SQL Server)
Actieve Secondaries: Leesbare secundaire replica’s (Altijd Aan Beschikbaarheid Groepen)
Actieve secundairen: Back-up op secundaire replica’s (Altijd Aan Beschikbaarheid Groepen)
Luisteraars van beschikbaarheidsgroepen, client connectiviteit en failover van applicaties (SQL Server)