SQL Server Always On-beschikbaarheidsgroepen: complete handleiding [2026]

1. Inzicht in Always On-beschikbaarheidsgroepen

1.1 Wat het is en hoe het werkt

Always On Availability Groups (AG) is een SQL Server Enterprise hoge beschikbaarheid Een oplossing voor noodherstel die op databaseniveau werkt. Een beschikbaarheidsgroep groepeert een of meer gebruikersdatabases in één failover-eenheid en repliceert deze naar maximaal acht secundaire replica's via continue transactielogboekverzending. Wanneer de primaire replica uitvalt, neemt een aangewezen synchrone secundaire replica automatisch de taken over, waardoor de toegang binnen enkele seconden wordt hersteld zonder gedeelde opslag of handmatige tussenkomst.

1.2 Altijd beschikbare beschikbaarheidsgroepen versus failover-clusterinstanties

SQL Server Always On omvat twee afzonderlijke technologieën: beschikbaarheidsgroepen (AG) en failoverclusterinstanties (FCI):

	Altijd aan-beschikbaarheidsgroepen	Altijd actieve failover-clusterinstanties
Failoverbereik	Databaseniveau	Op instantieniveau (alle databases schakelen tegelijkertijd over naar een andere database bij een storing)
Gegevensreplicatie	Logboekgebaseerde replicatie naar elke secundaire server	Geen — alle knooppunten delen dezelfde opslag.
Gedeelde opslag	Niet verplicht	Vereist (Storage Area Network (SAN), iSCSI, S2D of SMB)
Leesbare secundaire gegevens	Ja	Nee
ramp herstel	Ingebouwd (asynchrone replica's over verschillende locaties)	Niet standaard ingebouwd zonder koppeling met AG

Wanneer moet u welk middel gebruiken: Gebruik FCI wanneer u failover op instantieniveau nodig hebt en al een gedeelde opslaginfrastructuur hebt. Gebruik AG wanneer u granulariteit op databaseniveau, leesbare secundaire servers of noodherstel nodig hebt. Voor de most Voor volledige bescherming kunt u beide combineren: laat elke replica als een FCI-node draaien en verbind ze in een AG.

1.3 Voordelen en beperkingen

Voordelen:

• Automatische failover met een bijna nul hersteltijd (RTO) voor synchrone replica's;
• geen gegevensverlies (Recovery Point Objective (RPO) = 0) in de synchrone commit-modus;
• Geen gedeelde opslag nodig — elke replica gebruikt onafhankelijke lokale opslag;
• Leesbare secundaire servers ontlasten de primaire server van de rapportage- en back-uptaken;
• Ondersteunt zowel lokale hoge beschikbaarheid (HA) als noodherstel over meerdere locaties (DR) binnen één enkele configuratie.

Beperkingen:

• Vereist Windows Server Failover Clustering op alle replica's;
• Enterprise-editie voor alle functies (Standard-editie ondersteunt Basic AG met aanzienlijke beperkingen);
• De synchrone commit-modus voegt latentie toe aan schrijfbewerkingen, evenredig met de round-trip time van het netwerk;
• Aanmeldingen, SQL Agent-taken en gekoppelde servers worden niet automatisch gesynchroniseerd. SQL Server 2019 en eerder (opgelost in SQL Server 2022 bevatte beschikbaarheidsgroepen).

2. Architectuur van Always On Availability Groups

2.1 Kerncomponenten en -concepten

2.1.1 Beschikbaarheidsdatabases

Beschikbaarheidsdatabases zijn de gebruikersdatabases die deelnemen aan een beschikbaarheidsgroep. Deze databases moeten aan specifieke vereisten voldoen: ze moeten het volledige herstelmodel gebruiken, een volledige back-up hebben en op de primaire replica aanwezig zijn voordat ze aan een beschikbaarheidsgroep kunnen worden toegevoegd.

Wanneer een database zich aansluit bij een beschikbaarheidsgroep, wordt deze onderdeel van een gesynchroniseerde set die als één geheel overschakelt naar een andere locatie bij een storing. Alle databases in een beschikbaarheidsgroep delen dezelfde failover-status. Dit betekent dat als de primaire replica uitvalt, alle databases gelijktijdig overschakelen naar dezelfde secundaire replica. Dit garandeert consistentie voor applicaties die afhankelijk zijn van meerdere gerelateerde databases.

2.1.2 Beschikbaarheid van replica's

Beschikbaarheidsreplica's zijn SQL Server gevallen waarin host kopieën van beschikbaarheidsdatabases. Elke replica heeft een eigen fysieke kopie van de databases, die gesynchroniseerd wordt via het verzenden van transactielogboekrecords. Een beschikbaarheidsgroep kan maximaal negen replica's bevatten: één primaire replica en maximaal acht secundaire replica's.

2.1.3 Primaire replica

De primaire replica hostDe primaire replica is een lees-schrijfkopie van de beschikbaarheidsdatabases. Alle gegevenswijzigingen (INSERT, UPDATE, DELETE) vinden plaats op de primaire replica. Clienttoepassingen maken verbinding met de primaire replica voor alle schrijfbewerkingen en, standaard, ook voor leesbewerkingen.

2.1.4 Secundaire replica's

Secundaire replica's host Alleen-lezen kopieën van de beschikbaarheidsdatabases worden bijgehouden door continue toepassing van transactielogboekrecords die van de primaire replica worden ontvangen. Elke secundaire replica ontvangt, versleutelt en past logboekrecords toe om de databasekopieën gesynchroniseerd te houden met de primaire replica.

2.2 Beschikbaarheidsmodi

2.2.1 Synchrone commitmodus

De synchrone commitmodus biedt bescherming tegen gegevensverlies doordat de primaire replica moet wachten op bevestiging dat de transactielogboekrecords op de secundaire replica zijn opgeslagen voordat transacties worden vastgelegd. Deze modus is essentieel voor configuraties met hoge beschikbaarheid waar gegevensverlies onaanvaardbaar is.

2.2.2 Asynchrone commitmodus

De asynchrone commit-modus geeft prioriteit aan de prestaties van de primaire replica door transacties te laten vastleggen zonder te wachten op de bevestiging van de logboekverharding door de secundaire replica's. Deze modus is geschikt voor replica's voor noodherstel of wanneer netwerklatentie synchrone commit onpraktisch maakt.

De keerzijde is het potentiële gegevensverlies tijdens failover. Als de primaire replica uitvalt, bereiken sommige vastgelegde transacties mogelijk de secundaire replica niet. De omvang van het potentiële gegevensverlies hangt af van de netwerkbandbreedte, de prestaties van de secundaire replica en het tijdstip van de storing. Organisaties moeten dit risico accepteren bij gebruik van de asynchrone modus.

2.3 Failovertypen

2.3.1 Automatische failover

Automatische failover zorgt ervoor dat de beschikbaarheidsgroep een storing in de primaire replica detecteert en automatisch een secundaire replica tot primaire replica promoveert zonder tussenkomst van de beheerder. Deze functionaliteit minimaliseert de RTO (Recovery Time Objective) doordat handmatige reacties op storingen overbodig worden.

Automatische failover vereist de modus 'synchrone commit' om gegevensverlies te voorkomen. Wanneer deze modus is ingeschakeld, bewaakt de beschikbaarheidsgroep continu de status van de primaire replica. Als de primaire replica niet meer reageert of uitvalt, start het Windows Server Failover Cluster een automatische failover naar een aangewezen secundaire replica.

2.3.2 Handmatige failover

Handmatige failover stelt beheerders in staat om de rol van primaire replica opzettelijk over te dragen aan een secundaire replica, meestal voor gepland onderhoud of testdoeleinden. In tegenstelling tot automatische failover vereist handmatige failover expliciete actie van de beheerder om te worden gestart.

Handmatige failover zonder gegevensverlies is beschikbaar voor synchrone commit-replica's. De beheerder initieert de failover via SQL Server Management Studio, Transact-SQL of PowerShell. De primaire replica verwerkt de huidige transacties en stuurt alle resterende logboekrecords naar de primaire replica. tarkrijgt de secundaire rol toegewezen en wacht op bevestiging voordat de primaire rol wordt overgedragen.

Handmatige failover is ook mogelijk bij replica's met asynchrone commits, maar dit vereist een geforceerde failover met potentieel gegevensverlies. Beheerders dienen geforceerde handmatige failover alleen te gebruiken in daadwerkelijke rampscenario's, wanneer de primaire replica niet beschikbaar is en gegevensverlies acceptabel is in vergelijking met langdurige downtime.

2.3.3 Geforceerde failover

Geforceerde failover maakt failover mogelijk naar een asynchrone secundaire replica of naar een secundaire replica die niet volledig gesynchroniseerd is, met de expliciete erkenning van mogelijk gegevensverlies. Deze optie dient als laatste redmiddel wanneer de primaire replica niet beschikbaar is en er geen gesynchroniseerde secundaire replica bestaat.

2.4 Gegevenssynchronisatie

2.4.1 Hoe gegevenssynchronisatie werkt

Gegevenssynchronisatie in Always On Availability Groups vindt plaats door middel van continue verzending van transactielogboekrecords van de primaire replica naar alle secundaire replica's. Deze op logboeken gebaseerde synchronisatie zorgt voor consistentie en maakt tegelijkertijd onafhankelijke opslag voor elke replica mogelijk.

2.4.2 Transactielogboekrecords en beveiliging

Het beveiligen van transactielogboeken is een cruciale stap waarbij logboekrecords worden weggeschreven naar duurzame opslag op secundaire replica's. Beveiliging zorgt ervoor dat logboekrecords een storing van de secundaire replica overleven en tijdens het herstelproces opnieuw kunnen worden afgespeeld.

2.5 Leesbare schaal en leesbare secundaire replica's

2.5.1 Het ontlasten van alleen-lezen workloads

Leesbare secundaire replica's stellen organisaties in staat om leesintensieve workloads van de primaire replica over te hevelen, waardoor de algehele systeemprestaties en het resourcegebruik verbeteren. Deze mogelijkheid tot schaalbaarheid van leesbewerkingen is een van de belangrijkste voordelen van beschikbaarheidsgroepen ten opzichte van oudere oplossingen voor hoge beschikbaarheid.

Organisaties moeten bij het ontwerpen van beschikbaarheidsgroepconfiguraties rekening houden met de vereisten voor alleen-lezen workloads. Meerdere leesbare secundaire servers kunnen de rapportagelast over meerdere servers verdelen. Alleen-lezen routeringslijsten bepalen de volgorde waarin secundaire servers verbindingen met leesintentie ontvangen, waardoor strategieën voor taakverdeling mogelijk worden.

2.5.2 Back-upbewerkingen op secundaire replica's

Door back-ups op secundaire replica's uit te voeren, wordt de input/output (I/O) en de belasting van de centrale verwerkingseenheid (CPU) op de primaire replica verminderd, waardoor deze zich kan concentreren op transactionele taken. Deze mogelijkheid helpt organisaties om aan hun back-upvereisten te voldoen zonder de prestaties in de productieomgeving te beïnvloeden.

SQL Server Het systeem ondersteunt volledige databasebackups, differentiële back-ups en transactielogbackups op secundaire replica's. Back-upvoorkeuren kunnen worden geconfigureerd om de voorkeur te geven aan secundaire replica's, de primaire replica, alleen secundaire replica's of elke replica. Het back-upsysteem selecteert automatisch een geschikte replica op basis van deze voorkeuren en de huidige beschikbaarheid.

Voor meer details over SQL Server back-up, zie onze uitgebreide gids.

2.6 Beschikbaarheidsgroep-luisteraars

2.6.1 Wat is een luisteraar?

Een beschikbaarheidsgroeplistener is een virtuele netwerknaam (VNN) en een IP-adres die clienttoepassingen gebruiken om verbinding te maken met databases van de beschikbaarheidsgroep. De listener stuurt verbindingen automatisch door naar de huidige primaire replica, waardoor toepassingen niet hoeven bij te houden welke server momenteel primair is.

2.6.2 Clientverbindingsroutering

Clientverbindingen worden via de listener gerouteerd, waarbij zowel lees-schrijf- als alleen-lezen-verbindingsintenties worden ondersteund. De listener onderzoekt het verbindingsverzoek en routeert het naar de juiste replica op basis van de intentie van de applicatie.

3. Voorwaarden en vereisten

3.1 Failoverclustering van Windows Server voor beschikbaarheidsgroepen

3.1.1 Basisprincipes van failoverclustering in Windows Server

Windows Server Failover Clustering (WSFC) vormt de basis voor Always On Availability Groups door het beheer van clusterlidmaatschap, statusbewaking en failover-orkestratie. In tegenstelling tot Failover Cluster Instances gebruiken beschikbaarheidsgroepen WSFC alleen voor clustercoördinatie, niet voor het beheer van gedeelde opslag.

Elke SQL Server Een instantie die deelneemt aan een beschikbaarheidsgroep moet een knooppunt in een WSFC-cluster zijn. Het cluster beheert quorumstemming, detectie van de status van knooppunten en de resourcestatus van de beschikbaarheidsgroep. Wanneer de primaire replica uitvalt, coördineert WSFC het failoverproces en werkt de clusterresources bij om de nieuwe primaire replica weer te geven.

3.1.2 Clusterquorumconfiguratie

Het clusterquorum bepaalt welke knooppunten kunnen blijven functioneren wanneer er problemen met de netwerkverbinding optreden. Dit voorkomt split-brain-scenario's waarbij meerdere knooppunten onafhankelijk van elkaar beweren de primaire te zijn. De quorumconfiguratie definieert wat een meerderheidsstem inhoudt voor beslissingen binnen het cluster.

Er zijn verschillende quorummodi beschikbaar voor beschikbaarheidsgroepen:

• Node Majority gebruikt alleen stemmen van clusterknooppunten en werkt goed voor clusters met een oneven aantal knooppunten.
• Node and File Share Majority voegt een stemrecht voor bestandsdeling toe, geschikt voor clusters met een even aantal knooppunten.
• Bij Node and Disk Majority wordt een schijfgetuige gebruikt, maar dit is minder gebruikelijk voor beschikbaarheidsgroepen omdat gedeelde opslag niet nodig is.

3.1.3 Clustering met meerdere subnetten

Multi-subnet clustering maakt het mogelijk dat replica's van beschikbaarheidsgroepen zich over verschillende netwerksubnetten uitstrekken, waardoor geografisch gedistribueerde implementaties over datacenters mogelijk zijn. Deze mogelijkheid is essentieel voor disaster recovery-configuraties waarbij replica's zich op verschillende locaties bevinden.

3.2 SQL Server Editievereisten

3.2.1 Functies van de Enterprise-editie

SQL Server De Enterprise Edition biedt de volledige functionaliteit van beschikbaarheidsgroepen zonder beperkingen. De Enterprise Edition ondersteunt tot acht secundaire replica's, leesbare secundaire servers, automatische seeding, gedistribueerde beschikbaarheidsgroepen en alle geavanceerde functies.

3.2.2 Functies van de standaardeditie (basisbeschikbaarheidsgroepen)

SQL Server De Standard-editie van 2016 en latere versies ondersteunen Basic Availability Groups, maar met aanzienlijke beperkingen. Basic Availability Groups bieden essentiële functionaliteit voor hoge beschikbaarheid tegen een lagere prijs.ost, geschikt voor organisaties met eenvoudigere behoeften.

4. Altijd-aan-beschikbaarheidsgroepen configureren

4.1 De omgeving voorbereiden

Voordat een beschikbaarheidsgroep kan worden aangemaakt, moet de omgeving correct zijn voorbereid met Active Directory-accounts, serverconfiguraties en netwerkinfrastructuur.

4.1.1 Configuratie van de domeincontroller

De Active Directory-domeincontroller moet geconfigureerd zijn om het beschikbaarheidsgroepcluster te ondersteunen. SQL Server serviceaccounts.

1. Meld u aan bij de domeincontroller met de inloggegevens van de domeinbeheerder.
2. Openen server Manager en navigeer naar Tools -> Active Directory-gebruikers en computers.
3. Creëer een organisatie-eenheid voor SQL Server objecten als er geen bestaat.
4. Controleer of de computerobjecten voor alle clusterknooppunten in Active Directory aanwezig zijn.
5. Zorg ervoor dat de Domain Name System (DNS)-services correct zijn geconfigureerd en dat alle servernamen correct worden opgelost.

4.1.2 Serviceaccounts aanmaken

Maak speciale Active Directory-serviceaccounts aan voor SQL Server services op elk knooppunt.

1. Openen Active Directory-gebruikers en computers op de domeincontroller.
2. Klik met de rechtermuisknop op de betreffende organisatie-eenheid en selecteer Nieuwe -> Gebruiker.
3. Voer de naam van het serviceaccount in (bijvoorbeeld svc_SQLServer) en stel de Gebruikersnaam voor aanmelden.
4. Klik op het tabblad Volgende en voer een sterk wachtwoord in.
5. Kies Gebruiker kan wachtwoord niet veranderen en Wachtwoord verloopt nooit.
6. Klik op het tabblad Volgende en Voltooien om het account aan te maken.
7. Herhaal dit voor alle extra serviceaccounts die u nodig heeft (SQL Server Agent, SSRS, enz.).

4.1.3 Beheerdersrechten configureren

Serviceaccounts en de accounts die worden gebruikt voor configuratie SQL Server Alle clusterknooppunten moeten over de juiste machtigingen beschikken.

1. Meld u aan bij elke clusterknooppuntserver.
2. Openen Computerbeheer aan de hand van de Start menu of Serverbeheer.
3. Uitvouwen Lokale gebruikers en groepen en selecteer Groepen.
4. Klik met de rechtermuisknop beheerders en selecteer Aanbod.
5. Klik op het tabblad Toevoegen en voer de serviceaccountnaam in.
6. Klik op het tabblad Controleer namen om het account te valideren en vervolgens te klikken OK.
7. Klik op het tabblad OK Om het dialoogvenster Beheerderseigenschappen te sluiten.
8. Herhaal dit op alle clusterknooppunten.

4.2 WSFC installeren en configureren

Voordat Always On Availability Groups kunnen worden ingeschakeld, moet Windows Server Failover Clustering op alle knooppunten zijn geïnstalleerd en geconfigureerd.

4.2.1 De failover-clusteringfunctie installeren

Installeer de failoverclusteringfunctie op elke server die deel zal uitmaken van de beschikbaarheidsgroep.

1. Openen server Manager op het eerste clusterknooppunt.
2. Klik op het tabblad Beheren -> Rollen en functies toevoegen.
3. Klik op het tabblad Volgende via de introductieschermen.
4. Kies Op rollen gebaseerde of functiegebaseerde installatie en klik op Volgende.
5. Selecteer de lokale server en klik Volgende.
6. Sla het scherm 'Rollen' over en klik. Volgende.
7. Selecteer op het scherm Functies de optie Failover-clustering.
8. Klik op het tabblad Functies toevoegen wanneer daarom gevraagd wordt om beheertools toe te voegen.
9. Klik op het tabblad Volgende en Install.
10. Wacht tot de installatie is voltooid en klik. Sluiten.
11. Herhaal dit op alle servers die deel uitmaken van het cluster.

4.2.2 Het failovercluster creëren

Nadat u de failover-clusteringfunctie op alle knooppunten hebt geïnstalleerd, maakt u het cluster aan vanuit één knooppunt.

1. Openen Failoverclusterbeheer vanaf server Manager -> Tools.
2. Klik op het tabblad Cluster maken in het deelvenster Acties.
3. Klik op het tabblad Volgende op de pagina 'Voordat je begint'.
4. Klik op het tabblad Blader en voeg alle servers toe die clusterknooppunten zullen zijn.
5. Klik op het tabblad Volgende na het toevoegen van alle knooppunten.
6. Verlof Voer alle tests uit (aanbevolen) selecteer en klik Volgende.
7. Bekijk de resultaten van de validatietests en los eventuele fouten of waarschuwingen op.
8. Klik op het tabblad Voltooien nadat de validatie succesvol is afgerond.
9. Voer een naam en IP-adres in voor het cluster.
10. Haal het vinkje weg Voeg alle geschikte opslag toe aan het cluster aangezien gedeelde opslag niet nodig is.
11. Klik op het tabblad Volgende en controleer de bevestiging.
12. Klik op het tabblad Voltooien om het cluster te maken.

4.2.3 Validatie van de clusterconfiguratie

Valideer de clusterconfiguratie om ervoor te zorgen dat alle knooppunten correct met elkaar kunnen communiceren en dat de cluster naar behoren functioneert.

1. In FailoverclusterbeheerKlik met de rechtermuisknop op de clusternaam.
2. Kies Cluster valideren in het menu.
3. Klik op het tabblad Volgende op de pagina 'Voordat je begint'.
4. Kies Voer alle tests uit (aanbevolen) en klik op Volgende.
5. Klik op het tabblad Volgende om te beginnen met validatietests.
6. Bekijk het validatierapport zodra de tests zijn afgerond.
7. Verhelp alle tekortkomingen of waarschuwingen die in het rapport worden vermeld.
8. Klik op het tabblad Voltooien om de wizard te sluiten.

4.3 Installeren SQL Server voor beschikbaarheidsgroepen

Install SQL Server op elk knooppunt dat deel zal uitmaken van de beschikbaarheidsgroep met behulp van de standalone installatieoptie.

1. Voer de ... uit SQL Server Installatiemedia op het eerste knooppunt.
2. Kies Nieuwe SQL Server zelfstandige installatie.
3. Voer de productcode in of selecteer de evaluatieversie.
4. Accepteer de licentievoorwaarden en klik Volgende.
5. Voer alle vereiste controles uit en los eventuele problemen op.
6. Selecteer op de pagina Functieselectie de optie Database Engine-services.
7. Configureer de instantienaam (gebruik dezelfde instantienaam op alle knooppunten).
8. Geef op de pagina Serverconfiguratie de inloggegevens van het serviceaccount op.
9. Configureer servicestartup-typen als Automatisch.
10. Selecteer de authenticatiemodus op de pagina 'Database Engine Configuration'.
11. Beheerdersaccounts toevoegen.
12. Configureer gegevensmappen met consistente paden op alle knooppunten.
13. Voltooi de installatie en controleer of alles naar behoren werkt.
14. Herhaal de installatie op alle andere clusterknooppunten met identieke instellingen.

4.4 De functie 'Altijd ingeschakelde beschikbaarheidsgroepen' inschakelen

Na het installeren van SQL Server Schakel op alle knooppunten de functie 'Always On Availability Groups' in voor elke instantie.

4.4.1 Inschakelen via SQL Server Configuratiebeheer

Gebruik SQL Server Met Configuration Manager kunt u Always On Availability Groups inschakelen via de grafische interface.

1. Openen SQL Server Configuratiebeheer op het eerste knooppunt.
2. Uitvouwen SQL Server Services in het linkerdeelvenster.
3. Klik met de rechtermuisknop op de SQL Server instantie en selecteren Aanbod.
4. Klik op de knop Altijd hoge beschikbaarheid .
5. Check Schakel AlwaysOn-beschikbaarheidsgroepen in..
6. Controleer of de naam van het Windows-failovercluster correct is.
7. Klik op het tabblad OK om de wijzigingen op te slaan.
8. Klik op het tabblad OK op de waarschuwing dat de dienst opnieuw moet worden ingesteldtarted.
9. Klik met de rechtermuisknop op de SQL Server service en selecteer Restart.
10. Wacht tot de service is hersteldtarsuccesvol.
11. Herhaal dit op alle clusterknooppunten.

4.4.2 Inschakelen via PowerShell

PowerShell biedt een scriptmethode om Always On Availability Groups in te schakelen voor meerdere knooppunten.

1. Open PowerShell als beheerder op het eerste knooppunt.
2. Importeer de SQL Server PowerShell-module:

   Import-Module SQLPS -DisableNameChecking

3. Altijd beschikbare beschikbaarheidsgroepen inschakelen:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. De service wordt automatisch opnieuw opgestart.tart bij gebruik van de parameter Kracht.
5. Controleer of de functie is ingeschakeld:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Herhaal dit voor elk clusterknooppunt en vervang de server- en instantienamen door de juiste namen.

4.4.3 Controleren of de functie is ingeschakeld

Controleer of Always On Availability Groups is ingeschakeld op alle instanties voordat u verdergaat met de configuratie.

1. Verbind met elkaar SQL Server exemplaar gebruikt SQL Server Beheer Studio.
2. Open een nieuw queryvenster en voer de volgende opdracht uit:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Controleer of het resultaat 1 is (ingeschakeld).
4. Controleer of de SQL Server Het exemplaar verschijnt in Failover Cluster Manager onder clusterrollen.
5. Controleer of het beschikbaarheidsgroep-eindpunt bestaat door het volgende uit te voeren:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Als het eindpunt niet bestaat, wordt het aangemaakt tijdens het aanmaken van de beschikbaarheidsgroep.

4.5 Databases voorbereiden voor beschikbaarheidsgroepen

Databases moeten aan specifieke vereisten voldoen voordat ze aan een beschikbaarheidsgroep kunnen worden toegevoegd.

4.5.1 Vereisten voor het databaseherstelmodel

Wijzig het databaseherstelmodel naar FULL op de primaire replica voordat u deze toevoegt aan een beschikbaarheidsgroep.

1. Maak verbinding met de primaire replica via SQL Server Beheer Studio.
2. Klik met de rechtermuisknop op de database en selecteer Aanbod.
3. Selecteer het tabblad opties pagina.
4. Veranderen Herstelmodel naar Vol.
5. Klik op het tabblad OK om de wijziging op te slaan.
6. Als alternatief kunt u Transact-SQL gebruiken:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Volledige databaseback-ups maken

Maak een volledige back-up van de database om de back-upketen te creëren die nodig is voor beschikbaarheidsgroepen.

1. In SQL Server Open Management Studio en klik met de rechtermuisknop op de database.
2. Kies Taken -> Een back-up.
3. Controleren Type back-up is ingesteld op Vol.
4. Selecteer een back-upbestemming of voeg een nieuwe bestemming toe.
5. Klik op het tabblad OK om de back-up uit te voeren.
6. Als alternatief kunt u Transact-SQL gebruiken:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Het maken van back-ups van transactielogboeken

Maak een back-up van het transactielogboek om ervoor te zorgen dat de logboekketen tot stand is gebracht en om de initialisatietijd te minimaliseren.

1. In SQL Server Open Management Studio en klik met de rechtermuisknop op de database.
2. Kies Taken -> Een back-up.
3. Veranderen Type back-up naar Transactielogboek.
4. Selecteer een back-upbestemming.
5. Klik op het tabblad OK om de back-up uit te voeren.
6. Als alternatief kunt u Transact-SQL gebruiken:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 De beschikbaarheidsgroep maken

Maak de beschikbaarheidsgroep aan met behulp van een van de beschikbare methoden, afhankelijk van uw voorkeuren en automatiseringsvereisten.

4.6.1 De wizard voor het maken van een nieuwe beschikbaarheidsgroep gebruiken

De wizard Nieuwe beschikbaarheidsgroep biedt een grafische interface voor het aanmaken van beschikbaarheidsgroepen.

1. In SQL Server Maak in Management Studio verbinding met het exemplaar dat u wilt gebruiken.ost de primaire replica.
2. Uitvouwen Altijd hoge beschikbaarheid in Objectverkenner.
3. Klik met de rechtermuisknop Beschikbaarheidsgroepen en selecteer Wizard Nieuwe beschikbaarheidsgroep.
   
4. Klik op het tabblad Volgende op de introductiepagina.
5. Voer een naam in voor de beschikbaarheidsgroep en klik. Volgende.
6. Selecteer op de pagina 'Databases selecteren' de databases die u wilt opnemen.
7. Controleer of de databases aan alle vereisten voldoen en klik. Volgende.
8. Klik op de pagina 'Replica's specificeren' op Replica toevoegen.
9. Maak verbinding met elke secundaire replica-instantie.
10. Configureer de replica-eigenschappen voor elke instantie (beschikbaarheidsmodus, failovermodus).
11. Klik op de knop Eindpunten Tabblad en controleer de eindpuntconfiguratie.
12. Klik op de knop Back-upvoorkeuren Tabblad en configureer de back-upprioriteiten.
13. Klik op de knop Luisteraar tab en maak eventueel een listener aan.
14. Klik op het tabblad Volgende en selecteer de methode voor gegevenssynchronisatie.
15. Bekijk de validatieresultaten en los eventuele problemen op.
16. Klik op het tabblad Volgende en bekijk de samenvatting.
17. Klik op het tabblad Voltooien om de beschikbaarheidsgroep te creëren.
18. Volg de voortgang en controleer of de creatie succesvol is verlopen.

4.6.2 Transact-SQL gebruiken

Maak beschikbaarheidsgroepen aan met Transact-SQL voor scriptbare, herhaalbare implementaties.

1. Maak de beschikbaarheidsgroep aan op de primaire replica:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Voeg de secundaire replica toe aan de beschikbaarheidsgroep:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Voeg je toe aan de secundaire database:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 PowerShell gebruiken

PowerShell biedt scriptmogelijkheden voor het aanmaken en beheren van beschikbaarheidsgroepen.

1. Maak het beschikbaarheidsgroepobject aan:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Databases toevoegen:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Configureer replica's met de gewenste eigenschappen met behulp van de cmdlet New-SqlAvailabilityReplica.
4. Voeg secundaire replica's samen met behulp van de cmdlet Join-SqlAvailabilityGroup.

4.7 Replica's toevoegen aan de beschikbaarheidsgroep

Configureer replica-specifieke eigenschappen die bepalen hoe elk exemplaar deelneemt aan de beschikbaarheidsgroep.

4.7.1 Replica-eigenschappen configureren

Stel eigenschappen in voor elke replica om de rol en mogelijkheden ervan binnen de beschikbaarheidsgroep te definiëren.

1. In SQL Server Management Studio, uitbreiden Altijd hoge beschikbaarheid -> Beschikbaarheidsgroepen.
2. Breid de beschikbaarheidsgroep uit en breid deze vervolgens uit. Beschikbaarheid Replica's.
   
3. Klik met de rechtermuisknop op een replica en selecteer Aanbod.
4. Controleer en wijzig de verbindingsinstellingen voor de primaire en secundaire rollen.
5. Configureer indien nodig de time-outwaarden voor de sessie.
6. Klik op het tabblad OK om wijzigingen op te slaan.

4.7.2 Beschikbaarheidsmodi instellen

Configureer de beschikbaarheidsmodus om het synchronisatiegedrag tussen replica's te beheren.

1. Klik met de rechtermuisknop op de beschikbaarheidsgroep en selecteer Aanbod.
2. Zoek in de map Algemeen pagina, ga naar de Beschikbaarheid Replica's pagina.
3. Selecteer voor elke replica Synchrone commit or Asynchrone commit in de vervolgkeuzelijst.
4. Gebruik synchrone commit voor lokale replica's met hoge beschikbaarheid.
5. Gebruik asynchrone commits voor geografisch ver verwijderde replica's voor noodherstel.
6. Klik op het tabblad OK om de configuratie op te slaan.

4.7.3 Failover-modi instellen

Configureer de failovermodus om te bepalen hoe failover voor elke replica plaatsvindt.

1. Klik met de rechtermuisknop op de beschikbaarheidsgroep en selecteer Aanbod.
2. Zoek in de map Algemeen pagina, ga naar de Beschikbaarheid Replica's pagina.
3. Selecteer voor synchrone commit-replica's de optie Automatisch or Handleiding failover-modus.
4. Automatische failover vereist de synchrone commit-modus en maakt failover zonder tussenkomst van de gebruiker mogelijk.
5. Voor asynchrone commit-replica's is alleen handmatige failover beschikbaar.
6. Configureer maximaal drie replica's voor automatische failover (één primaire en twee secundaire).
7. Klik op het tabblad OK om de instellingen toe te passen.

4.7.4 Back-upvoorkeuren configureren

Stel back-upvoorkeuren in om te bepalen waar back-upbewerkingen moeten plaatsvinden.

1. Klik met de rechtermuisknop op de beschikbaarheidsgroep en selecteer Aanbod.
2. Kies Back-upvoorkeuren in het linkerdeelvenster.
3. Kies een van de back-upvoorkeuren:
   • Geef de voorkeur aan secundair: Backups worden op de secundaire schijf opgeslagen indien beschikbaar, anders op de primaire schijf.
   • Alleen secundair: Backups worden alleen op secundaire replica's gemaakt
   • Primair: Back-ups worden alleen op de primaire replica gemaakt
   • Elke replica: Back-ups op elke beschikbare replica
4. Stel voor elke replica een prioriteitswaarde voor de back-up in (0-100).
5. Hogere prioriteitswaarden geven de voorkeur aan als back-up. tarkrijgt.
6. Klik op het tabblad OK om de voorkeuren op te slaan.

4.8 De beschikbaarheidsgroeplistener configureren

Maak een listener aan om één verbindingspunt te bieden dat automatisch doorverwijst naar de huidige primaire replica.

4.8.1 De luisteraar maken

Voeg een listener toe aan de beschikbaarheidsgroep voor het beheer van clientverbindingen.

1. In SQL Server Management Studio, breid de beschikbaarheidsgroep uit.
2. Klik met de rechtermuisknop Beschikbaarheidsgroep Luisteraars en selecteer Luisteraar toevoegen.
   
3. Voer een DNS-naam in voor de listener (bijvoorbeeld AG_Listener).
4. Voer het poortnummer in (standaard is 1433).
5. Kies Static IP voor de netwerkmodus.
6. Klik op het tabblad Toevoegen om voor elk subnet een IP-adres toe te voegen.
7. Voer het IP-adres in en selecteer het subnet.
8. Klik op het tabblad OK om de luisteraar te creëren.
9. Controleer of de listener in Object Explorer wordt weergegeven en online is.

4.8.2 DNS- en IP-instellingen configureren

Controleer de DNS-registratie en netwerkconfiguratie voor de listener.

1. Open DNS Manager op de domeincontroller.
2. Controleer of de luisternaam is geregistreerd bij alle IP-adressen.
3. Test de DNS-resolutie vanaf clientcomputers:

   nslookup ListenerName

4. Controleer of alle geconfigureerde IP-adressen worden geretourneerd.
5. Vouw in Failover Cluster Manager het volgende uit: rollen en selecteer de beschikbaarheidsgroep.
6. Controleer of de bronnen op het IP-adres online zijn.
7. Controleer of de netwerknaamresource online is.
   

4.8.3 Testen van de luisteraarverbinding

Controleer of clienttoepassingen verbinding kunnen maken via de listener.

1. Openen vanaf een clientcomputer SQL Server Beheer Studio.
2. Maak verbinding via de naam van de luisteraar in plaats van de servernaam.
3. Voer een query uit om de verbinding met de huidige primaire replica te controleren:

   SELECT @@SERVERNAME;

4. Test de routering op basis van leesintentie door ApplicationIntent=ReadOnly toe te voegen aan de verbindingsreeks.
5. Controleer of de verbinding wordt omgeleid naar een leesbare secundaire replica.
6. Test de failover door handmatig de beschikbaarheidsgroep over te schakelen en de herverbinding te controleren.

4.9 Methoden voor gegevenssynchronisatie

Kies een methode voor gegevenssynchronisatie om secundaire replica's te initialiseren met kopieën van de database.

4.9.1 Automatisch zaaien

Automatisch seeden zorgt ervoor dat databasegegevens via het netwerk worden overgedragen zonder dat handmatige back-ups en herstelbewerkingen nodig zijn.

1. Selecteer tijdens het aanmaken van een beschikbaarheidsgroep de optie Automatisch zaaien als synchronisatiemethode.
   
2. Zorg voor netwerkverbinding en voldoende bandbreedte tussen de replica's.
3. De primaire replica streamt automatisch databasegegevens naar secundaire replica's.
4. Volg de voortgang van het seedproces via het dashboard van de beschikbaarheidsgroep of via DMV's.
5. Automatisch zaaien vereist SQL Server 2016 of hoger.
6. Bij grote databases moet rekening worden gehouden met de impact op het netwerk en moet de planning plaatsvinden tijdens perioden met weinig gebruik.

4.9.2 Handmatig seeden (back-up en herstel)

Handmatig seeden houdt in dat er back-ups worden gemaakt op de primaire server en dat deze worden hersteld op de secundaire replica's.

1. Maak op de primaire replica een volledige back-up:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Maak een back-up van het transactielogboek:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Herstel op elke secundaire replica de volledige back-up:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Herstel de logback-up:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Voeg de database toe aan de beschikbaarheidsgroep:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Controleer of de synchronisatie start en de database de status 'SYNCHRONIZED' bereikt.

4.9.3 Databasesnapshotbestanden

Gebruik databasesnapshotbestanden om secundaire replica's te initialiseren vanuit bestaande databasebestanden.

1. Ontkoppel de database op de primaire replica of maak er een back-up van.
2. Kopieer de databasebestanden naar elke secundaire replica met behulp van dezelfde bestandspaden.
3. Op secundaire replica's kunt u de database koppelen of herstellen zonder herstel.
4. Zorg ervoor dat de database de status 'HERSTELLEN' heeft.
5. Voeg de database toe aan de beschikbaarheidsgroep.
6. Deze methode is handig voor zeer grote databases waarbij netwerkoverdracht onpraktisch zou zijn.

5. FAQ

5.1 Algemene vragen

V: Wat is het verschil tussen Always On FCI en Always On AG?

A: Always On Failover Cluster Instances bieden hoge beschikbaarheid op instantieniveau met behulp van gedeelde opslag, terwijl Always On Availability Groups hoge beschikbaarheid op databaseniveau bieden zonder gedeelde opslag. AG biedt leesbare secundaire servers en een flexibelere geografische spreiding.

V: Kan ik Always On Availability Groups gebruiken met SQL Server Standaardeditie?

A: Ja, SQL Server De Standard Edition 2016 en latere versies ondersteunen Basic Availability Groups, maar met beperkingen zoals één database per AG, maximaal twee replica's en geen ondersteuning voor leesbare secundaire databases.

V: Heb ik gedeelde opslag nodig voor Always On Availability Groups?

A: Nee, beschikbaarheidsgroepen vereisen geen gedeelde opslag. Elke replica bewaart onafhankelijke kopieën van databases op lokale opslag, gesynchroniseerd via transaction log shipping.

V: Wat is het maximale aantal replica's in een beschikbaarheidsgroep?

A: SQL Server Enterprise Edition ondersteunt maximaal negen replica's (één primaire en acht secundaire). Gedistribueerde beschikbaarheidsgroepen kunnen in totaal maximaal 18 replica's ondersteunen, verdeeld over twee beschikbaarheidsgroepen.

5.2 Configuratievragen

V: Hoe kies ik tussen synchrone en asynchrone commit-modi?

A: Gebruik synchrone commit voor situaties waarin geen gegevensverlies mag optreden binnen hetzelfde datacenter of in netwerken met lage latentie. Gebruik asynchrone commit voor externe replica's voor noodherstel, waar synchrone commit de prestaties zou beïnvloeden.

V: Kan ik synchrone en asynchrone replica's in dezelfde beschikbaarheidsgroep combineren?

A: Ja, beschikbaarheidsgroepen ondersteunen gemengde configuraties met zowel synchrone als asynchrone replica's. Dit maakt lokale hoge beschikbaarheid mogelijk met synchrone replica's en herstel op afstand na een ramp met asynchrone replica's.

V: Wat gebeurt er met mijn verbindingen tijdens een failover?

A: Bestaande verbindingen worden verbroken wanneer failover optreedt. Applicaties met logica voor het opnieuw proberen van verbindingen maken automatisch opnieuw verbinding met de nieuwe primaire server via de listener. Het failoverproces is doorgaans binnen enkele seconden tot minuten voltooid.

V: Moet ik aanmeldingen en taken synchroniseren tussen replica's?

EEN: Binnen SQL Server Voor 2019 en eerder: ja, aanmeldingen, SQL Agent-taken en gekoppelde servers moeten handmatig worden gesynchroniseerd. SQL Server In 2022 worden ingesloten beschikbaarheidsgroepen geïntroduceerd die deze objecten automatisch bevatten.

5.3 Managementvragen

V: Kan ik back-ups uitvoeren op secundaire replica's?

A: Ja, secundaire replica's ondersteunen volledige, differentiële en transactielogboekback-ups. Configureer de back-upvoorkeuren om back-ups van de primaire replica over te nemen en het resourcegebruik ervan te verminderen.

V: Hoe patch ik? SQL Server met minimale uitvaltijd?

A: Gebruik rolling upgrades door eerst de secundaire replica's te patchen, vervolgens een handmatige failover uit te voeren naar een gepatchte secundaire replica en tot slot de voormalige primaire replica te patchen. Dit minimaliseert de downtime tot de duur van de failover.

V: Kan ik databases toevoegen aan een bestaande beschikbaarheidsgroep?

A: Ja, databases kunnen worden toegevoegd aan actieve beschikbaarheidsgroepen. De database moet in het volledige herstelmodel staan ​​met een volledige back-up, en secundaire replica's moeten worden gevuld met behulp van automatische vulling of handmatige back-up en herstel.

V: Wat is automatisch zaaien en moet ik het gebruiken?

A: Automatisch seeden draagt ​​databasegegevens via het netwerk over om secundaire replica's te initialiseren zonder handmatige back-ups. Gebruik dit voor kleinere databases of wanneer de netwerkbandbreedte voldoende is. Voor zeer grote databases kan handmatig seeden sneller zijn.

V: Waar in een beschikbaarheidsgroep moet ik DBCC CHECKDB uitvoeren?

A: U moet DBCC CHECKDB uitvoeren op secundaire replica's om de belasting van de primaire replica te verminderen. Databaseconsistentiecontroles kunnen worden uitgevoerd op secundaire databases zonder de prestaties van de primaire replica te beïnvloeden.

Voor meer informatie over DBCC CHECKDB, zie onze uitgebreide gids.

5.4 Problemen oplossen

V: Waarom heeft mijn database de status 'NIET SYNCHRONISEREN'?

A: Veelvoorkomende oorzaken zijn onder andere problemen met de netwerkverbinding, onderbroken gegevensoverdracht, onvoldoende schijfruimte op secundaire replica's of problemen met het eindpunt. Controleer de beschrijving van de synchronisatiestatus en SQL Server Raadpleeg de foutenlogboeken voor specifieke details. Als de secundaire database een fout heeft ingevoerd, hersteltoestand of toont herstel in afwachtingRaadpleeg de gekoppelde handleidingen voor tarOplossingen zijn gevonden.

V: Hoe forceer ik failover wanneer de primaire server niet beschikbaar is?

A: Maak verbinding met een secundaire replica en voer ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS uit. Hiermee wordt potentieel gegevensverlies bevestigd en wordt de secundaire replica onmiddellijk gepromoveerd tot primaire replica.

V: Waarom kunnen clients geen verbinding maken met mijn listener?

A: Controleer of de listener online is in Failover Cluster Manager, of de DNS-registratie is geslaagd, of alle IP-adressen van de listener bereikbaar zijn vanaf clients en of de firewallregels verkeer naar de listenerpoort toestaan.

V: Wat betekent een grote redo-wachtrij?

A: Een grote redo-wachtrij geeft aan dat de secundaire replica de logrecords niet zo snel kan verwerken als ze binnenkomen. Dit kan duiden op knelpunten in de schijf-I/O, beperkingen van de CPU of blokkeringen door alleen-lezen query's op de secundaire replica.

V: Wat moet ik doen als een ramp alle replica's treft en mijn back-ups ook beschadigd raken?

A: Dit worstcasescenario, hoewel extreem rarDit kan gebeuren als gevolg van ransomware-aanvallen, wijdverspreide opslagstoringen of escalerende rampen. Uw belangrijkste verdediging is preventie: onderhoud geografisch verspreide replica's, sla back-ups op verschillende locaties op en
Test uw procedures voor noodherstel regelmatig. Als alle standaard herstelopties falen, moet een gespecialiseerd systeem worden ingeschakeld. SQL-gegevenshersteltool Als laatste redmiddel kan geprobeerd worden gegevens uit beschadigde MDF-bestanden te extraheren.

5.5 Licenties en Cost Contact

V: Hoe worden Always On Availability Groups gelicentieerd?

A: SQL Server De licentie is afhankelijk van de editie en het implementatiemodel. Beschikbaarheidsgroepen van de Enterprise-editie vereisen Enterprise-licenties op alle replica's. Passieve secundaire replica's komen onder bepaalde voorwaarden mogelijk in aanmerking voor een gratis licentie.

Vraag: Kan ik gebruiken? SQL Server Ontwikkelaarseditie voor beschikbaarheidsgroepen?

A: Ja, de Developer Edition bevat alle functies van de Enterprise Edition, inclusief volledige ondersteuning voor beschikbaarheidsgroepen. De licentie is echter alleen bedoeld voor ontwikkeling en testen, niet voor productiegebruik.

V: Zijn er extra licenties nodig voor leesbare secundaire documenten?

A: De licentievereisten zijn afhankelijk van het scenario. Passieve secundaire servers voor noodherstel vereisen doorgaans geen licentie. Actieve secundaire servers die alleen leesbewerkingen uitvoeren, vereisen over het algemeen wel een licentie, hoewel de specifieke voorwaarden kunnen variëren.

V: Is er een gratis manier om hoge beschikbaarheid te verkrijgen met SQL Server?

A: SQL Server Express Edition biedt geen ondersteuning voor beschikbaarheidsgroepen. SQL Server De standaardeditie ondersteunt basisbeschikbaarheidsgroepen.tarting met SQL Server 2016, met basis hoge beschikbaarheid bij Standard Edition-licenties costs.

V: Wat zijn gedistribueerde beschikbaarheidsgroepen?

A: Gedistribueerde beschikbaarheidsgroepen zijn een speciaal type beschikbaarheidsgroep dat twee afzonderlijke beschikbaarheidsgroepen omvat, waardoor scenario's mogelijk worden die de mogelijkheden van traditionele beschikbaarheidsgroepen overstijgen. Geïntroduceerd in SQL Server In 2016 werden gedistribueerde beschikbaarheidsgroepen ingezet om te voldoen aan de eisen op het gebied van schaalbaarheid en geografische spreiding.

6. Conclusie

6.1 Samenvatting van de belangrijkste punten

SQL Server Always On Availability Groups (AIG's) vertegenwoordigen Microsofts belangrijkste oplossing voor hoge beschikbaarheid en noodherstel voor bedrijfskritieke databases. Ze bieden failover op databaseniveau zonder gedeelde opslag, leesbare secundaire replica's voor het ontlasten van workloads en flexibele geografische distributie voor uitgebreide gegevensbescherming. Voor organisaties die nog steeds oplossingen gebruiken zoals houttransport or kopiërenBeschikbaarheidsgroepen bieden een robuuster en operationeel eenvoudiger upgradepad.

6.2 Wanneer Always On-beschikbaarheidsgroepen te gebruiken

Kies beschikbaarheidsgroepen wanneer u hoge beschikbaarheid op databaseniveau met automatische failovermogelijkheden nodig hebt. Organisaties die bescherming tegen dataverlies voor kritieke databases nodig hebben, profiteren van synchrone commit-replica's met automatische failover. Applicaties die schaalbare leesmogelijkheden vereisen, maken gebruik van leesbare secundaire replica's om queryworkloads te verdelen.

6.3 Het verkrijgen van Started met Uw Implementatie

Begin met de planning van beschikbaarheidsgroepen door de bedrijfsvereisten te beoordelen, inclusief RTO, RPO en budgetbeperkingen. Documenteer de huidige database-infrastructuur, applicatieafhankelijkheden en hiaten in de hoge beschikbaarheid. Ontwerp een architectuur voor beschikbaarheidsgroepen die aan de vereisten voldoet en tegelijkertijd binnen de beschikbare resources blijft.

Referenties

• Officieel Microsoft-document: Wat is een Always On-beschikbaarheidsgroep?
• Officieel Microsoft-document: S krijgentarted met Always On Availability Groups
• Officieel Microsoft-document: Gedistribueerde beschikbaarheidsgroepen

---

Over de auteur

Yuan Sheng is een senior databasebeheerder (DBA) met meer dan 10 jaar ervaring in SQL Server omgevingen en enterprise databasebeheer. Hij heeft honderden databaseherstelscenario's succesvol opgelost in financiële dienstverlening, gezondheidszorg en productiebedrijven.

Yuan is gespecialiseerd in SQL Server Databaseherstel, oplossingen voor hoge beschikbaarheid en prestatieoptimalisatie. Zijn uitgebreide praktijkervaring omvat het beheer van multi-terabyte databases, de implementatie van Always-On Availability Groups en de ontwikkeling van geautomatiseerde back-up- en herstelstrategieën voor bedrijfskritische bedrijfssystemen.

Met zijn technische expertise en praktische aanpak richt Yuan zich op het creëren van uitgebreide handleidingen die databasebeheerders en IT-professionals helpen complexe problemen op te lossen. SQL Server uitdagingen efficiënt. Hij blijft op de hoogte van de nieuwste SQL Server releases en de evoluerende databasetechnologieën van Microsoft, waarbij hij regelmatig herstelscenario's test om ervoor te zorgen dat zijn aanbevelingen overeenkomen met de beste praktijken in de praktijk.

Heb vragen over SQL Server herstel of heeft u aanvullende begeleiding nodig bij het oplossen van databaseproblemen? Yuan verwelkomt feedback en suggesties om deze technische middelen te verbeteren.