SQL Server Altid aktiverede tilgængelighedsgrupper: Komplet guide [2026]

1. Forståelse af altid tilgædige grupper

1.1 Hvad det er, og hvordan det fungerer

Altid til rådighedsgrupper (AG) er en SQL Server Enterprise høj tilgængelighed og en katastrofeberedskabsløsning, der fungerer på databaseniveau. En tilgængelighedsgruppe grupperer en eller flere brugerdatabaser i en enkelt failover-enhed og replikerer dem til op til otte sekundære replikaer via kontinuerlig transaktionslogforsendelse. Når den primære replika fejler, overtager en udpeget synkron sekundær automatisk og gendanner adgangen på få sekunder uden delt lager eller manuel indgriben.

1.2 Always On-tilgængelighedsgrupper vs. Failover-klyngeinstanser

SQL Server Always On omfatter to forskellige teknologier: Tilgængelighedsgrupper (AG) og Failover Cluster Instances (FCI):

	Altid på tilgængelighedsgrupper	Always On Failover Cluster-instanser
Failover-omfang	Databaseniveau	Instansniveau (alle databaser failoveres samtidig)
Datareplikering	Logbaseret replikering til hver sekundær	Ingen — alle noder deler den samme lagerplads
Delt opbevaring	Ikke påkrævet	Påkrævet (Storage Area Network (SAN), iSCSI, S2D eller SMB)
Læsbare sekundærer	Ja	Ingen
opsving Disaster	Indbygget (asynkrone replikaer på tværs af websteder)	Ikke indbygget uden parring med AG

Hvornår skal hver enkelt bruges: Brug FCI, når du har brug for failover på instansniveau og allerede har delt lagerinfrastruktur. Brug AG, når du har brug for granularitet på databaseniveau, læsbare sekundære filer eller disaster recovery. For den mest komplette beskyttelse skal du kombinere begge dele: kør hver replika som en FCI-node og link dem i en AG.

1.3 Fordele og begrænsninger

Fordele:

• Automatisk failover med næsten nul Recovery Time Objective (RTO) for synkrone replikaer;
• nul datatab (Recovery Point Objective (RPO) = 0) i synkron commit-tilstand;
• ingen delt lagring kræves — hver replika bruger uafhængig lokal lagring;
• læsbare sekundære enheder aflaster rapportering og backup-arbejdsbelastninger fra primære enheder;
• understøtter både lokal høj tilgængelighed (HA) og cross-site disaster recovery (DR) i en enkelt konfiguration.

Begrænsninger:

• Kræver Windows Server Failover Clustering på alle replikaer;
• Enterprise Edition til det fulde funktionssæt (Standard Edition understøtter Basic AG med betydelige begrænsninger);
• synkron commit-tilstand tilføjer latenstid til skriveoperationer proportionalt med netværkets rundturstid;
• logins, SQL Agent-job og linkede servere synkroniseres ikke automatisk i SQL Server 2019 og tidligere (løst i SQL Server 2022 indeholdt tilgængelighedsgrupper).

2. Arkitektur for altid aktive tilgængelighedsgrupper

2.1 Kernekomponenter og koncepter

2.1.1 Tilgængelighedsdatabaser

Tilgængelighedsdatabaser er de brugerdatabaser, der deltager i en tilgængelighedsgruppe. Disse databaser skal opfylde specifikke krav: de skal bruge den fulde gendannelsesmodel, have en fuld sikkerhedskopi og findes på den primære replika, før de føjes til en tilgængelighedsgruppe.

Når en database tilslutter sig en tilgængelighedsgruppe, bliver den en del af et synkroniseret sæt, der failoverer som en enhed. Alle databaser i en tilgængelighedsgruppe deler den samme failover-tilstand, hvilket betyder, at hvis den primære replika fejler, failoverer alle databaser til den samme sekundære replika samtidigt. Dette sikrer konsistens for applikationer, der er afhængige af flere relaterede databaser.

2.1.2 Tilgængelighedsreplikaer

Tilgængelighedsreplikaer er SQL Server instanser, der er vært for kopier af tilgængelighedsdatabaser. Hver replika vedligeholder sin egen fysiske kopi af databaserne, synkroniseret via forsendelse af transaktionslogposter. En tilgængelighedsgruppe kan indeholde op til ni replikaer: én primær replika og op til otte sekundære replikaer.

2.1.3 Primær replika

Den primære replika er vært for læse-skrive-kopien af ​​tilgængelighedsdatabaserne. Alle dataændringer (INSERT, UPDATE, DELETE) sker på den primære replika. Klientprogrammer opretter forbindelse til den primære replika for alle skrivehandlinger og som standard også for læsehandlinger.

2.1.4 Sekundære replikaer

Sekundære replikaer er vært for skrivebeskyttede kopier af tilgængelighedsdatabaserne, der vedligeholdes gennem kontinuerlig anvendelse af transaktionslogposter modtaget fra den primære replika. Hver sekundær replika modtager, forstærker og anvender logposter for at holde dens databasekopier synkroniseret med den primære.

2.2 Tilgængelighedstilstande

2.2.1 Synkron commit-tilstand

Synkron commit-tilstand giver nul beskyttelse mod datatab ved at kræve, at den primære replika venter på bekræftelse af, at transaktionslogposter er blevet hærdet på den sekundære replika, før transaktioner committes. Denne tilstand er afgørende for konfigurationer med høj tilgængelighed, hvor datatab er uacceptabelt.

2.2.2 Asynkron commit-tilstand

Asynkron commit-tilstand prioriterer den primære replikas ydeevne ved at tillade transaktioner at committe uden at vente på, at sekundære replikaer bekræfter loghærdning. Denne tilstand er passende til replikaer efter nedbrud, eller når netværkslatens gør synkron commit upraktisk.

Afvejningen er potentielt datatab under failover. Hvis den primære replika fejler, er nogle committede transaktioner muligvis ikke nået frem til den sekundære replika. Omfanget af potentielt datatab afhænger af netværksbåndbredde, den sekundære replikas ydeevne og tidspunktet for fejlen. Organisationer skal acceptere denne risiko, når de bruger asynkron tilstand.

2.3 Failover-typer

2.3.1 Automatisk failover

Automatisk failover gør det muligt for tilgængelighedsgruppen at registrere fejl i den primære replika og automatisk forfremme en sekundær replika til primær uden administratorindgriben. Denne funktion minimerer RTO ved at eliminere behovet for manuel reaktion på fejl.

Automatisk failover kræver synkron commit-tilstand for at sikre nul datatab. Når tilgængelighedsgruppen er aktiveret, overvåger den løbende den primære replikas tilstand. Hvis den primære replika ikke reagerer eller fejler, starter Windows Server Failover Cluster automatisk failover til en udpeget sekundær replika.

2.3.2 Manuel failover

Manuel failover giver administratorer mulighed for bevidst at skifte den primære replikarolle til en sekundær replika, typisk til planlagt vedligeholdelse eller testformål. I modsætning til automatisk failover kræver manuel failover eksplicit administratorhandling for at starte.

Manuel failover uden datatab er tilgængelig for synkrone commit-replikaer. Administratoren initierer failoveren via SQL Server Management Studio, Transact-SQL eller PowerShell. Den primære replika afslutter behandlingen af ​​aktuelle transaktioner, sender alle resterende logposter til den sekundære destination og venter på bekræftelse, før den primære rolle overføres.

Manuel failover kan også forekomme med asynkrone commit-replikaer, men dette kræver tvungen failover med potentielt datatab. Administratorer bør kun bruge tvungen manuel failover under faktiske katastrofescenarier, når den primære replika ikke er tilgængelig, og datatab er acceptabelt sammenlignet med forlænget nedetid.

2.3.3 Tvungen failover

Tvungen failover tillader failover til en asynkron sekundær replika eller til en sekundær, der ikke er fuldt synkroniseret, med den eksplicitte anerkendelse af potentielt datatab. Denne mulighed fungerer som en sidste udvej, når den primære replika ikke er tilgængelig, og der ikke findes nogen synkroniseret sekundær.

2.4 Datasynkronisering

2.4.1 Sådan fungerer datasynkronisering

Datasynkronisering i Always On Availability Groups sker via kontinuerlig forsendelse af transaktionslogposter fra den primære replika til alle sekundære replikaer. Denne logbaserede synkronisering sikrer konsistens, samtidig med at den tillader uafhængig lagring for hver replika.

2.4.2 Transaktionslogfiler og hærdning

Hærdning af transaktionslogfiler er det kritiske trin, hvor logposter skrives til varigt lager på sekundære replikaer. Hærdning sikrer, at logposter overlever fejl i sekundære replikaer og kan afspilles igen under gendannelse.

2.5 Læseskala og læsbare sekundære replikaer

2.5.1 Aflastning af skrivebeskyttede arbejdsbelastninger

Læsbare sekundære replikaer gør det muligt for organisationer at aflaste læseintensive arbejdsbyrder fra den primære replika, hvilket forbedrer den samlede systemydelse og ressourceudnyttelse. Denne læseskalafunktion er en af ​​de vigtigste fordele ved tilgængelighedsgrupper i forhold til ældre løsninger med høj tilgængelighed.

Organisationer bør overveje krav til skrivebeskyttet arbejdsbelastning, når de designer konfigurationer af tilgængelighedsgrupper. Flere læsbare sekundære servere kan fordele rapporteringsbelastningen på tværs af flere servere. Skrivebeskyttede routinglister definerer den rækkefølge, hvori sekundære servere modtager læseintention-forbindelser, hvilket muliggør strategier for belastningsbalancering.

2.5.2 Sikkerhedskopieringshandlinger på sekundære replikaer

Kørsel af sikkerhedskopier på sekundære replikaer reducerer input/output (I/O) og CPU-belastningen på den primære replika, hvilket giver den mulighed for at fokusere på transaktionelle arbejdsbyrder. Denne funktion hjælper organisationer med at opfylde sikkerhedskopieringskrav uden at påvirke produktionsydelsen.

SQL Server understøtter fulde databasebackups, differentielle backups og transaktionslogbackups på sekundære replikaer. Backuppræferencer kan konfigureres til at foretrække sekundære replikaer, primær, kun sekundær eller enhver replika. Backupsystemet vælger automatisk en passende replika baseret på disse præferencer og aktuel tilgængelighed.

For flere detaljer om SQL Server sikkerhedskopiering, se vores omfattende vejledning.

2.6 Lyttere i tilgængelighedsgruppen

2.6.1 Hvad er en lytter?

En tilgængelighedsgruppelytter er et virtuelt netværksnavn (VNN) og en IP-adresse, som klientprogrammer bruger til at oprette forbindelse til tilgængelighedsgruppedatabaser. Lytteren omdirigerer automatisk forbindelser til den aktuelle primære replika, hvilket eliminerer behovet for, at programmer sporer, hvilken server der i øjeblikket er primær.

2.6.2 Klientforbindelsesrouting

Klientforbindelsesrouting gennem lytteren understøtter både læse-skrive- og skrivebeskyttede forbindelsesintentioner. Lytteren undersøger forbindelsesanmodningen og routerer den til den relevante replika baseret på applikationens intention.

3. Forudsætninger og krav

3.1 Windows Server Failover-klynger til tilgængelighedsgrupper

3.1.1 Grundlæggende om Windows Server Failover Clustering

Windows Server Failover Clustering (WSFC) danner grundlaget for Always On Availability Groups ved at administrere klyngemedlemskab, tilstandsovervågning og failover-orkestrering. I modsætning til Failover Cluster Instances bruger tilgængelighedsgrupper kun WSFC til klyngekoordinering, ikke til administration af delt lager.

Hver SQL Server En instans, der deltager i en tilgængelighedsgruppe, skal være en node i en WSFC-klynge. Klyngen administrerer quorumafstemning, nodetilstandsdetektion og tilgængelighedsgruppens ressourcetilstand. Når den primære replika fejler, koordinerer WSFC failover-processen og opdaterer klyngeressourcer for at afspejle den nye primære replika.

3.1.2 Konfiguration af klyngequorum

Klyngequorum bestemmer, hvilke noder der kan fungere, når der opstår problemer med netværksforbindelsen, hvilket forhindrer split-brain-scenarier, hvor flere noder uafhængigt af hinanden hævder at være primære. Quorumkonfigurationen definerer, hvad der udgør et flertal af stemmer for klyngebeslutninger.

Der er flere kvorumtilstande tilgængelige for tilgængelighedsgrupper:

• Node Majority bruger kun klyngenodestemmer og fungerer godt for klynger med et ulige antal noder.
• Node- og fildelingsflertal tilføjer en vidneafstemning for fildeling, der er egnet til nodeklynger med lige nummer.
• Node- og diskmajoritet bruger et diskvidne, men er mindre almindeligt for tilgængelighedsgrupper, da delt lagring ikke er påkrævet.

3.1.3 Klyngedannelse med flere undernet

Multi-subnet clustering gør det muligt for replikaer af tilgængelighedsgrupper at spænde over forskellige netværkssubnet, hvilket understøtter geografisk distribuerede implementeringer på tværs af datacentre. Denne funktion er afgørende for konfigurationer af nødberedskab, hvor replikaer findes på separate placeringer.

3.2 SQL Server Udgavekrav

3.2.1 Funktioner i Enterprise Edition

SQL Server Enterprise Edition tilbyder fuld funktionalitet for tilgængelighedsgrupper uden begrænsninger. Enterprise Edition understøtter op til otte sekundære replikaer, læsbare sekundære filer, automatisk seeding, distribuerede tilgængelighedsgrupper og alle avancerede funktioner.

3.2.2 Funktioner i standardudgaven (grundlæggende tilgængelighedsgrupper)

SQL Server Standardudgaven fra 2016 og nyere understøtter grundlæggende tilgængelighedsgrupper med betydelige begrænsninger. Grundlæggende tilgængelighedsgrupper leverer kernefunktionalitet med høj tilgængelighed til en lavere pris, hvilket er egnet til organisationer med enklere krav.

4. Konfiguration af altid tilgædige grupper

4.1 Forberedelse af miljøet

Før en tilgængelighedsgruppe oprettes, skal miljøet være korrekt forberedt med Active Directory-konti, serverkonfigurationer og netværksinfrastruktur på plads.

4.1.1 Opsætning af domænecontroller

Active Directory-domænecontrolleren skal konfigureres til at understøtte tilgængelighedsgruppeklyngen og SQL Server servicekonti.

1. Log ind på domænecontrolleren med domæneadministratoroplysninger.
2. Åbne Server manager og navigere til Værktøjer -> Active Directory-brugere og -computere.
3. Opret en organisatorisk enhed for SQL Server objekter, hvis et sådant ikke findes.
4. Bekræft, at computerobjekter for alle klyngenoder findes i Active Directory.
5. Sørg for, at DNS-tjenester (Domain Name System) er korrekt konfigureret, og at alle servernavne fortolkes korrekt.

4.1.2 Oprettelse af servicekonti

Opret dedikerede Active Directory-tjenestekonti til SQL Server tjenester på hver node.

1. Åbne Active Directory-brugere og -computere på domænecontrolleren.
2. Højreklik på den relevante organisationsenhed, og vælg Ny -> Bruger.
3. Indtast servicekontonavnet (f.eks. svc_SQLServer), og angiv Brugerens logonnavn.
4. Klik Næste og indtast en stærk adgangskode.
5. Type Brugeren kan ikke ændre kodeord og Adgangskoden udløber aldrig.
6. Klik Næste og så Finish for at oprette kontoen.
7. Gentag for eventuelle yderligere nødvendige servicekonti (SQL Server Agent, SSRS osv.).

4.1.3 Konfiguration af administratorrettigheder

Servicekonti og de konti, der bruges til at konfigurere SQL Server skal have de nødvendige tilladelser på alle klyngenoder.

1. Log ind på hver klyngenodeserver.
2. Åbne computer Management fra Starten menu eller Serveradministrator.
3. Udvid Lokale brugere og grupper og vælg Grupper.
4. Højreklik Administratorer og vælg Ejendomme.
5. Klik Tilføj og indtast navnet på servicekontoen.
6. Klik Tjek navne for at validere kontoen, og klik derefter på OK.
7. Klik OK for at lukke dialogboksen Administratoregenskaber.
8. Gentag på alle klyngenoder.

4.2 Installation og konfiguration af WSFC

Windows Server Failover Clustering skal installeres og konfigureres på alle noder, før Always On Availability Groups aktiveres.

4.2.1 Installation af failover-klyngefunktion

Installer funktionen Failover Clustering på hver server, der skal deltage i tilgængelighedsgruppen.

1. Åbne Server manager på den første klyngenode.
2. Klik Administrer -> Tilføj roller og funktioner.
3. Klik Næste gennem introduktionsskærmene.
4. Type Rollebaseret eller funktionsbaseret installation og klik Næste.
5. Vælg den lokale server og klik på Næste.
6. Spring over skærmbilledet Roller, og klik på Næste.
7. På skærmen Funktioner skal du vælge Fejling af klynger.
8. Klik Tilføj funktioner når du bliver bedt om at inkludere administrationsværktøjer.
9. Klik Næste og så Installer.
10. Vent på, at installationen er færdig, og klik på Luk.
11. Gentag på alle servere, der skal deltage i klyngen.

4.2.2 Oprettelse af failover-klyngen

Når du har installeret funktionen Failover Clustering på alle noder, skal du oprette klyngen fra én node.

1. Åbne Failover Cluster Manager fra Server manager -> Værktøjer.
2. Klik Opret klynge i handlingsruden.
3. Klik Næste på siden Før du starter.
4. Klik Gennemse og tilføj alle servere, der vil være klyngenoder.
5. Klik Næste efter at have tilføjet alle noder.
6. Forlad Kør alle tests (anbefales) valgt og klik Næste.
7. Gennemgå resultaterne af valideringstesten, og ret eventuelle fejl eller advarsler.
8. Klik Finish efter at valideringen er gennemført.
9. Indtast et navn til klyngen og en IP-adresse.
10. Fravælg Føj al kvalificeret lagerplads til klyngen da delt lagerplads ikke er påkrævet.
11. Klik Næste og gennemgå bekræftelsen.
12. Klik Finish at oprette klyngen.

4.2.3 Validering af klyngekonfigurationen

Valider klyngekonfigurationen for at sikre, at alle noder kan kommunikere korrekt, og at klyngen fungerer korrekt.

1. In Failover Cluster Managerskal du højreklikke på klyngenavnet.
2. Type Valider klynge fra menuen.
3. Klik Næste på siden Før du starter.
4. Type Kør alle tests (anbefales) og klik Næste.
5. Klik Næste at starte valideringstests.
6. Gennemgå valideringsrapporten, når testene er færdige.
7. Håndter eventuelle fejl eller advarsler, der er identificeret i rapporten.
8. Klik Finish for at lukke guiden.

4.3 Installation SQL Server for tilgængelighedsgrupper

Installer SQL Server på hver node, der deltager i tilgængelighedsgruppen ved hjælp af den separate installationsmulighed.

1. Kør SQL Server installationsmedie på den første node.
2. Type Ny SQL Server fritstående installation.
3. Indtast produktnøglen, eller vælg evalueringsudgaven.
4. Accepter licensbetingelserne og klik Næste.
5. Færdiggør forudsætningstjek og håndter eventuelle problemer.
6. På siden Funktionsvalg skal du vælge Database Engine Services.
7. Konfigurer instansnavn (brug det samme instansnavn på alle noder).
8. Angiv legitimationsoplysningerne til servicekontoen på siden Serverkonfiguration.
9. Konfigurer serviceopstartstyper som Automatisk Ur.
10. På konfigurationssiden for databaseprogrammet skal du vælge godkendelsestilstand.
11. Tilføj administratorkonti.
12. Konfigurer datamapper ved hjælp af ensartede stier på tværs af alle noder.
13. Færdiggør installationen, og bekræft, at den er vellykket.
14. Gentag installationen på alle andre klyngenoder med identiske indstillinger.

4.4 Aktivering af funktionen Altid aktiveret tilgængelighedsgrupper

Efter installation SQL Server Aktiver funktionen Always On Availability Groups på alle noder på hver instans.

4.4.1 Aktivering via SQL Server konfigurationsmanager

Brug SQL Server Konfigurationsadministrator til at aktivere Always On-tilgængelighedsgrupper via den grafiske brugerflade.

1. Åbne SQL Server konfigurationsmanager på den første node.
2. Udvid SQL Server Det vi er gode til i venstre rude.
3. Højreklik på SQL Server eksempel og vælg Ejendomme.
4. Klik på knappen AlwaysOn Høj Tilgængelighed fane.
5. Check (Skak) Aktivér AlwaysOn-tilgængelighedsgrupper.
6. Bekræft, at navnet på Windows-failover-klyngen er korrekt.
7. Klik OK for at gemme ændringerne.
8. Klik OK på advarslen om, at tjenesten skal genstartes.
9. Højreklik på SQL Server service og vælg Genstart.
10. Vent på, at tjenesten genstarter.
11. Gentag på alle klyngenoder.

4.4.2 Aktivering via PowerShell

PowerShell leverer en scriptet metode til at aktivere Always On Availability Groups på tværs af flere noder.

1. Åbn PowerShell som administrator på den første node.
2. Importer SQL Server PowerShell-modul:

   Import-Module SQLPS -DisableNameChecking

3. Aktivér altid-tilgængelighedsgrupper:

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

4. Tjenesten genstartes automatisk, når Force-parameteren bruges.
5. Bekræft at funktionen er aktiveret:

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

6. Gentag for hver klyngenode, og erstat med de relevante server- og instansnavne.

4.4.3 Bekræftelse af, at funktionen er aktiveret

Bekræft, at Always On Availability Groups er aktiveret på alle instanser, før du fortsætter med konfigurationen.

1. Forbind til hver SQL Server eksempel ved hjælp af SQL Server ManagementStudio.
2. Åbn et nyt forespørgselsvindue og udfør:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Bekræft at resultatet er 1 (aktiveret).
4. Kontrollér, at SQL Server instansen vises i Failover Cluster Manager under klyngeroller.
5. Bekræft tilgængelighedsgruppens slutpunkt eksisterer ved at udføre:

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

6. Hvis slutpunktet ikke findes, oprettes det under oprettelsen af ​​tilgængelighedsgruppen.

4.5 Klargøring af databaser til tilgængelighedsgrupper

Databaser skal opfylde specifikke krav, før de kan føjes til en tilgængelighedsgruppe.

4.5.1 Krav til databasegendannelsesmodel

Skift databasegendannelsesmodellen til FULD på den primære replika, før du føjer den til en tilgængelighedsgruppe.

1. Opret forbindelse til den primære replika ved hjælp af SQL Server ManagementStudio.
2. Højreklik på databasen og vælg Ejendomme.
3. Vælg Indstillinger .
4. Skift Genopretningsmodel til Fuld.
5. Klik OK for at gemme ændringen.
6. Alternativt kan du bruge Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Tage fulde sikkerhedskopier af databasen

Tag en fuld databasebackup for at etablere den backupkæde, der kræves for tilgængelighedsgrupper.

1. In SQL Server Management Studio, højreklik på databasen.
2. Type Opgaver -> Back Up.
3. Bekræft Sikkerhedskopieringstype er sat til Fuld.
4. Vælg en backupdestination, eller tilføj en ny destination.
5. Klik OK at udføre sikkerhedskopieringen.
6. Alternativt kan du bruge Transact-SQL:

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

4.5.3 Sikkerhedskopiering af transaktionslogge

Tag en sikkerhedskopi af transaktionsloggen for at sikre, at logkæden er etableret og minimere initialiseringstiden.

1. In SQL Server Management Studio, højreklik på databasen.
2. Type Opgaver -> Back Up.
3. Skift Sikkerhedskopieringstype til Transaktionslog.
4. Vælg en backupdestination.
5. Klik OK at udføre sikkerhedskopieringen.
6. Alternativt kan du bruge Transact-SQL:

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

4.6 Oprettelse af tilgængelighedsgruppen

Opret tilgængelighedsgruppen ved hjælp af en af ​​flere tilgængelige metoder afhængigt af dine præferencer og automatiseringskrav.

4.6.1 Brug af guiden Ny tilgængelighedsgruppe

Guiden Ny tilgængelighedsgruppe indeholder en grafisk brugerflade til oprettelse af tilgængelighedsgrupper.

1. In SQL Server Management Studio, opret forbindelse til den instans, der skal være vært for den primære replika.
2. Udvid AlwaysOn Høj Tilgængelighed i Objekt Explorer.
3. Højreklik Tilgængelighedsgrupper og vælg Ny tilgængelighedsgruppeguide.
   
4. Klik Næste på introduktionssiden.
5. Indtast et navn til tilgængelighedsgruppen, og klik på Næste.
6. På siden Vælg databaser skal du vælge de databaser, der skal medtages.
7. Bekræft, at databaserne opfylder alle krav, og klik på Næste.
8. På siden Angiv replikaer skal du klikke på Tilføj replika.
9. Opret forbindelse til hver sekundær replikaforekomst.
10. Konfigurer replikaegenskaber for hver instans (tilgængelighedstilstand, failover-tilstand).
11. Klik på knappen Endpoints fanen og gennemgå slutpunktskonfigurationen.
12. Klik på knappen Sikkerhedskopieringsindstillinger fanen og konfigurer backupprioriteter.
13. Klik på knappen Lytter fanen og eventuelt opret en lytter.
14. Klik Næste og vælg datasynkroniseringsmetoden.
15. Gennemgå valideringsresultaterne og håndter eventuelle problemer.
16. Klik Næste og gennemgå resuméet.
17. Klik Finish for at oprette tilgængelighedsgruppen.
18. Overvåg fremskridt og bekræft vellykket oprettelse.

4.6.2 Brug af Transact-SQL

Opret tilgængelighedsgrupper ved hjælp af Transact-SQL til scriptbare, gentagelige implementeringer.

1. Opret tilgængelighedsgruppen på den primære replika:

   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. Tilslut den sekundære replika til tilgængelighedsgruppen:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Tilslut dig den sekundære database:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Brug af PowerShell

PowerShell leverer scriptingfunktioner til oprettelse og administration af tilgængelighedsgrupper.

1. Opret tilgængelighedsgruppeobjektet:

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

2. Tilføj databaser:

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

3. Konfigurer replikaer med de ønskede egenskaber ved hjælp af cmdlet'en New-SqlAvailabilityReplica.
4. Sammenkæd sekundære replikaer ved hjælp af cmdlet'en Join-SqlAvailabilityGroup.

4.7 Tilføjelse af replikaer til tilgængelighedsgruppen

Konfigurer replikaspecifikke egenskaber, der styrer, hvordan hver instans deltager i tilgængelighedsgruppen.

4.7.1 Konfiguration af replikaegenskaber

Angiv egenskaber for hver replika for at definere dens rolle og funktioner inden for tilgængelighedsgruppen.

1. In SQL Server Management Studio, udvid AlwaysOn Høj Tilgængelighed -> Tilgængelighedsgrupper.
2. Udvid tilgængelighedsgruppen, og udvid derefter Tilgængelighedsreplikaer.
   
3. Højreklik på en replika, og vælg Ejendomme.
4. Gennemgå og rediger forbindelsesindstillinger for den primære og sekundære rolle.
5. Konfigurer sessionstimeoutværdier, hvis det er nødvendigt.
6. Klik OK for at gemme ændringer.

4.7.2 Indstilling af tilgængelighedstilstande

Konfigurer tilgængelighedstilstand for at styre synkroniseringsadfærden mellem replikaer.

1. Højreklik på tilgængelighedsgruppen, og vælg Ejendomme.
2. I Generelt side, gå til Tilgængelighedsreplikaer sektion.
3. For hver replika skal du vælge Synkron commit or Asynkron commit fra dropdown.
4. Brug synkron commit til lokale replikaer med høj tilgængelighed.
5. Brug asynkron commit til geografisk fjerne replikaer til nødgendannelse.
6. Klik OK for at gemme konfigurationen.

4.7.3 Indstilling af failover-tilstande

Konfigurer failover-tilstand for at styre, hvordan failover sker for hver replika.

1. Højreklik på tilgængelighedsgruppen, og vælg Ejendomme.
2. I Generelt side, gå til Tilgængelighedsreplikaer sektion.
3. For synkrone commit-replikaer skal du vælge Automatisk Ur or Manuel failover-tilstand.
4. Automatisk failover kræver synkron commit-tilstand og aktiverer uovervåget failover.
5. For asynkrone commit-replikaer er kun manuel failover tilgængelig.
6. Konfigurer op til tre replikaer til automatisk failover (én primær og to sekundære).
7. Klik OK for at anvende indstillingerne.

4.7.4 Konfiguration af sikkerhedskopieringsindstillinger

Angiv præferencer for backup for at kontrollere, hvor backuphandlinger skal udføres.

1. Højreklik på tilgængelighedsgruppen, og vælg Ejendomme.
2. Type Sikkerhedskopieringsindstillinger i venstre rude.
3. Vælg en af ​​sikkerhedskopieringsindstillingerne:
   • Foretrækker sekundærSikkerhedskopier på sekundær hvis tilgængelig, ellers primær
   • Kun sekundærtSikkerhedskopier kun på sekundære replikaer
   • PrimærSikkerhedskopier kun på primær replika
   • Enhver replikaSikkerhedskopier på enhver tilgængelig replika
4. Angiv prioritetsværdier for backup for hver replika (0-100).
5. Højere prioritetsværdier angiver foretrukne backupmål.
6. Klik OK for at gemme præferencerne.

4.8 Konfiguration af tilgængelighedsgruppens lytter

Opret en lytter for at levere et enkelt forbindelsespunkt, der automatisk omdirigerer til den aktuelle primære replika.

4.8.1 Oprettelse af lytteren

Tilføj en lytter til tilgængelighedsgruppen for administration af klientforbindelser.

1. In SQL Server Management Studio, udvid tilgængelighedsgruppen.
2. Højreklik Tilgængelighedsgruppelyttere og vælg Tilføj lytter.
   
3. Indtast et DNS-navn til lytteren (f.eks. AG_Listener).
4. Indtast portnummeret (standard er 1433).
5. Type Statisk IP for netværkstilstanden.
6. Klik Tilføj for at tilføje en IP-adresse for hvert undernet.
7. Indtast IP-adressen, og vælg undernettet.
8. Klik OK at skabe lytteren.
9. Bekræft, at lytteren vises i Object Explorer og er online.

4.8.2 Konfiguration af DNS- og IP-indstillinger

Bekræft DNS-registrering og netværkskonfiguration for lytteren.

1. Åbn DNS Manager på domænecontrolleren.
2. Bekræft, at lytternavnet er registreret med alle IP-adresser.
3. Test DNS-opløsning fra klientmaskiner:

   nslookup ListenerName

4. Bekræft, at alle konfigurerede IP-adresser returneres.
5. I Failover Cluster Manager skal du udvide roller og vælg tilgængelighedsgruppen.
6. Bekræft, at IP-adresseressourcerne er online.
7. Kontroller, at netværksnavnressourcen er online.
   

4.8.3 Test af lytterforbindelse

Bekræft, at klientprogrammer kan oprette forbindelse via lytteren.

1. Fra en klientmaskine, åbn SQL Server ManagementStudio.
2. Opret forbindelse ved hjælp af lytternavnet i stedet for et servernavn.
3. Udfør en forespørgsel for at bekræfte forbindelsen til den aktuelle primære replika:

   SELECT @@SERVERNAME;

4. Test read-intent-routing ved at tilføje ApplicationIntent=ReadOnly til forbindelsesstrengen.
5. Bekræft omdirigeringer af forbindelser til en læsbar sekundær replika.
6. Test failover ved manuelt at failovere tilgængelighedsgruppen og verificere genoprettelse af forbindelsen.

4.9 Datasynkroniseringsmetoder

Vælg en datasynkroniseringsmetode for at initialisere sekundære replikaer med databasekopier.

4.9.1 Automatisk såning

Automatisk seeding overfører databasedata over netværket uden at kræve manuelle sikkerhedskopier og gendannelser.

1. Under oprettelsen af ​​tilgængelighedsgruppen skal du vælge Automatisk såning som synkroniseringsmetode.
   
2. Sørg for netværksforbindelse og tilstrækkelig båndbredde mellem replikaer.
3. Den primære replika streamer automatisk databasedata til sekundære replikaer.
4. Overvåg seeding-fremgangen ved hjælp af tilgængelighedsgruppens dashboard eller DMV'er.
5. Automatisk såning kræver SQL Server 2016 eller nyere.
6. For store databaser skal du overveje netværkets påvirkning og planlægge i perioder med lav brug.

4.9.2 Manuel seeding (backup og gendannelse)

Manuel seeding involverer at tage sikkerhedskopier på den primære og gendanne dem på sekundære replikaer.

1. Tag en fuld sikkerhedskopi på den primære replika:

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

2. Tag en sikkerhedskopi af transaktionsloggen:

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

3. Gendan den fulde sikkerhedskopi på hver sekundær replika:

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

4. Gendan logbackupen:

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

5. Tilslut databasen til tilgængelighedsgruppen:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Bekræft, at synkroniseringen begynder, og at databasen når tilstanden SYNKRONISERET.

4.9.3 Database-snapshotfiler

Brug database-snapshot-filer til at initialisere sekundære replikaer fra eksisterende databasefiler.

1. Afmonter eller sikkerhedskopier databasen på den primære replika.
2. Kopier databasefiler til hver sekundær replika ved hjælp af de samme filstier.
3. På sekundære replikaer skal du vedhæfte databasen eller gendanne uden gendannelse.
4. Sørg for, at databasen er i tilstanden GENDANNER.
5. Tilslut databasen til tilgængelighedsgruppen.
6. Denne metode er nyttig til meget store databaser, hvor netværksoverførsel ville være upraktisk.

5. FAQ

5.1 Generelle spørgsmål

Q: Hvad er forskellen på Always On FCI og Always On AG?

A: Always On Failover Cluster-instanser giver høj tilgængelighed på instansniveau ved hjælp af delt lagring, mens Always On Availability Groups giver høj tilgængelighed på databaseniveau uden delt lagring. AG tilbyder læsbare sekundære databaser og mere fleksibel geografisk distribution.

Q: Kan jeg bruge Always On-tilgængelighedsgrupper med SQL Server Standardudgave?

A: Ja, SQL Server 2016 Standard Edition og nyere understøtter Basic Availability Groups med begrænsninger, herunder én database pr. AG, maksimalt to replikaer og ingen understøttelse af læsbar sekundær.

Q: Har jeg brug for delt lagerplads til Always On Availability Groups?

A: Nej, tilgængelighedsgrupper kræver ikke delt lagring. Hver replika vedligeholder uafhængige kopier af databaser på lokal lagring, synkroniseret via forsendelse af transaktionslogfiler.

Q: Hvad er det maksimale antal replikaer i en tilgængelighedsgruppe?

A: SQL Server Enterprise Edition understøtter op til ni replikaer (én primær og otte sekundære). Distribuerede tilgængelighedsgrupper kan understøtte op til 18 replikaer i alt på tværs af to tilgængelighedsgrupper.

5.2 Konfigurationsspørgsmål

Q: Hvordan vælger jeg mellem synkrone og asynkrone commit-tilstande?

A: Brug synkron commit til at undgå datatab inden for det samme datacenter eller netværk med lav latenstid. Brug asynkron commit til fjerne replikaer efter katastrofegendannelse, hvor synkron commit ville påvirke ydeevnen.

Q: Kan jeg blande synkrone og asynkrone replikaer i den samme tilgængelighedsgruppe?

A: Ja, tilgængelighedsgrupper understøtter blandede konfigurationer med både synkrone og asynkrone replikaer. Dette muliggør lokal høj tilgængelighed med synkrone replikaer og fjern katastrofegendannelse med asynkrone replikaer.

Q: Hvad sker der med mine forbindelser under failover?

A: Eksisterende forbindelser afbrydes, når der opstår failover. Applikationer med logik for genoptagelse af forbindelse genopretter automatisk forbindelsen til den nye primære forbindelse via lytteren. Failover-processen fuldføres typisk inden for sekunder til minutter.

Q: Skal jeg synkronisere logins og job på tværs af replikaer?

A: I SQL Server 2019 og tidligere, ja – logins, SQL Agent-job og linkede servere skal synkroniseres manuelt. SQL Server 2022 introducerer indesluttede tilgængelighedsgrupper, der automatisk inkluderer disse objekter.

5.3 Ledelsesspørgsmål

Q: Kan jeg køre sikkerhedskopier på sekundære replikaer?

A: Ja, sekundære replikaer understøtter fulde, differentielle og transaktionslogbackups. Konfigurer backuppræferencer for at aflaste backups fra den primære replika og reducere dens ressourceforbrug.

Q: Hvordan laver jeg en patch SQL Server med minimal nedetid?

A: Brug rullende opgraderinger ved først at opdatere sekundære replikaer, derefter udføre en manuel failover til en opdateret sekundær og til sidst opdatere den tidligere primære. Dette minimerer nedetiden i forhold til failoverens varighed.

Q: Kan jeg tilføje databaser til en eksisterende tilgængelighedsgruppe?

A: Ja, databaser kan føjes til kørende tilgængelighedsgrupper. Databasen skal være i fuld gendannelsesmodel med en fuld sikkerhedskopi, og sekundære replikaer skal seedes ved hjælp af automatisk seeding eller manuel sikkerhedskopiering og gendannelse.

Q: Hvad er automatisk såning, og skal jeg bruge det?

A: Automatisk seeding overfører databasedata over netværket for at initialisere sekundære replikaer uden manuelle sikkerhedskopier. Brug det til mindre databaser eller når netværksbåndbredden er tilstrækkelig. For meget store databaser kan manuel seeding være hurtigere.

Q: Hvor skal jeg køre DBCC CHECKDB i en tilgængelighedsgruppe?

A: Du bør køre DBCC CHECKDB på sekundære replikaer for at reducere belastningen på den primære replika. Databasekonsistenstjek kan udføres mod sekundære databaser uden at påvirke den primære replikas ydeevne.

For yderligere oplysninger om DBCC CHECKDB, se vores omfattende vejledning.

5.4 Fejlfindingsspørgsmål

Q: Hvorfor er min database i tilstanden IKKE SYNKRONISERER?

A: Almindelige årsager omfatter problemer med netværksforbindelse, afbrudt dataflytning, utilstrækkelig diskplads på sekundære replikaer eller problemer med slutpunktet. Kontroller beskrivelsen af ​​synkroniseringstilstanden og SQL Server fejllogfiler for specifikke detaljer. Hvis den sekundære database har indtastet en genoprettelsestilstand eller viser inddrivelse afventer, se de linkede vejledninger for målrettede rettelser.

Q: Hvordan gennemtvinger jeg failover, når den primære ikke er tilgængelig?

A: Opret forbindelse til en sekundær replika, og udfør ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Dette anerkender potentielt datatab og forfremmer den sekundære til den primære med det samme.

Q: Hvorfor kan klienter ikke oprette forbindelse til min lytter?

A: Bekræft, at lytteren er online i Failover Cluster Manager, at DNS-registreringen er lykkedes, at alle lytter-IP'er kan nås fra klienter, og at firewallregler tillader trafik til lytterporten.

Q: Hvad betyder en lang redo-kø?

A: En lang redo-kø indikerer, at den sekundære replika ikke kan anvende logposter så hurtigt, som de ankommer. Dette kan indikere flaskehalse på disk-I/O, CPU-begrænsninger eller blokering af skrivebeskyttede forespørgsler på den sekundære replika.

Q: Hvad skal jeg gøre, hvis en katastrofe påvirker alle replikaer, og mine sikkerhedskopier også er beskadiget?

A: Dette værst tænkelige scenarie er ekstremt sjældent, men kan opstå på grund af ransomware-angreb, udbredte lagringsfejl eller kaskadekatastrofer. Dit primære forsvar er forebyggelse: Oprethold geografisk distribuerede replikaer, gem sikkerhedskopier på separate steder, og
Test regelmæssigt dine procedurer for genoprettelse efter katastrofe. Hvis alle standardgendannelsesmuligheder fejler, skal en specialist SQL-datagendannelsesværktøj kan forsøge at udtrække data fra beskadigede MDF-filer som en sidste udvej.

5.5 Licens- og omkostningsspørgsmål

Q: Hvordan licenseres Always On Availability Groups?

A: SQL Server Licensering afhænger af udgaven og implementeringsmodellen. Tilgængelighedsgrupper for Enterprise Edition kræver Enterprise-licenser på alle replikaer. Passive sekundære replikaer kan være berettiget til gratis licensering under visse betingelser.

Q: Kan jeg bruge SQL Server Udviklerudgave til tilgængelighedsgrupper?

A: Ja, Developer Edition inkluderer alle Enterprise Edition-funktioner, inklusive fuld understøttelse af tilgængelighedsgrupper. Den er dog kun licenseret til udvikling og test, ikke produktionsbrug.

Q: Kræver læsbare sekundære filer yderligere licenser?

A: Licensering afhænger af scenariet. Passive sekundære systemer til disaster recovery kræver typisk ikke licenser. Aktive sekundære systemer, der betjener skrivebeskyttede arbejdsbelastninger, kræver generelt licenser, selvom specifikke vilkår varierer.

Q: Er der en gratis måde at få høj tilgængelighed med SQL Server?

A: SQL Server Express Edition understøtter ikke tilgængelighedsgrupper. SQL Server Standardudgaven understøtter grundlæggende tilgængelighedsgrupper startende med SQL Server 2016, der tilbyder grundlæggende høj tilgængelighed til Standard Edition-licenspriser.

Q: Hvad er distribuerede tilgængelighedsgrupper?

A: Distribuerede tilgængelighedsgrupper er en særlig type tilgængelighedsgruppe, der spænder over to separate tilgængelighedsgrupper, hvilket muliggør scenarier, der overstiger mulighederne i traditionelle tilgængelighedsgrupper. Introduceret i SQL Server I 2016 adresserer distribuerede tilgængelighedsgrupper krav til skalering og geografisk distribution.

6. konklusion

6.1 Sammenfatning af nøglepunkter

SQL Server Always On Availability Groups repræsenterer Microsofts førende løsning til høj tilgængelighed og katastrofegendannelse for missionskritiske databaser. De leverer failover på databaseniveau uden krav til delt lagring, læsbare sekundære replikaer til aflastning af arbejdsbelastninger og fleksibel geografisk distribution for omfattende databeskyttelse. For organisationer, der stadig kører løsninger som f.eks. forsendelse af tømmerstokke or replikation, tilgængelighedsgrupper tilbyder en mere robust og operationelt enklere opgraderingssti.

6.2 Hvornår skal man bruge Always On-tilgængelighedsgrupper

Vælg tilgængelighedsgrupper, når du har brug for høj tilgængelighed på databaseniveau med automatiske failover-funktioner. Organisationer, der har brug for nul datatabsbeskyttelse til kritiske databaser, drager fordel af synkrone commit-replikaer med automatisk failover. Applikationer, der kræver læseskalafunktioner, udnytter læsbare sekundære replikaer til at distribuere forespørgselsarbejdsbelastninger.

6.3 Kom godt i gang med din implementering

Begynd planlægningen af ​​tilgængelighedsgruppen ved at vurdere forretningskrav, herunder RTO, RPO og budgetbegrænsninger. Dokumenter den nuværende databaseinfrastruktur, applikationsafhængigheder og store tilgængelighedshuller. Design en arkitektur for tilgængelighedsgruppen, der adresserer kravene, samtidig med at den forbliver inden for ressourcebegrænsningerne.

Referencer

• Microsofts officielle dokument: Hvad er en Altid Til-tilgængelighedsgruppe?
• Microsofts officielle dokument: Introduktion til Always On-tilgængelighedsgrupper
• Microsofts officielle dokument: Distribuerede tilgængelighedsgrupper

---

Om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring inden for SQL Server miljøer og virksomhedsdatabaseadministration. Han har med succes løst hundredvis af databasegendannelsesscenarier på tværs af finansielle tjenester, sundhedsvæsenet og produktionsorganisationer.

Yuan har specialiseret sig i SQL Server databasegendannelse, løsninger til høj tilgængelighed og ydeevneoptimering. Hans omfattende praktiske erfaring omfatter administration af databaser på flere terabyte, implementering af Always On Availability Groups og udvikling af automatiserede backup- og gendannelsesstrategier til missionskritiske forretningssystemer.

Gennem sin tekniske ekspertise og praktiske tilgang fokuserer Yuan på at skabe omfattende vejledninger, der hjælper databaseadministratorer og IT-professionelle med at løse komplekse SQL Server udfordringer effektivt. Han holder sig opdateret med det nyeste SQL Server udgivelser og Microsofts udviklende databaseteknologier, og tester regelmæssigt gendannelsesscenarier for at sikre, at hans anbefalinger afspejler bedste praksis i den virkelige verden.

Har spørgsmål vedr SQL Server gendannelse eller brug for yderligere vejledning i fejlfinding af databaser? Yuan er velkommen feedback og forslag for at forbedre disse tekniske ressourcer.