SQL Server Alltid på tilgjengelighetsgrupper: Komplett guide [2026]

1. Forståelse av tilgjengelighetsgrupper for alltid på

1.1 Hva det er og hvordan det fungerer

Alltid på tilgjengelighetsgrupper (AG) er en SQL Server Enterprise høy tilgjengelighet og en katastrofegjenopprettingsløsning som opererer på databasenivå. En tilgjengelighetsgruppe grupperer én eller flere brukerdatabaser i én failover-enhet og replikerer dem til opptil åtte sekundære replikaer gjennom kontinuerlig transaksjonsloggforsendelse. Når den primære replikaen feiler, tar en angitt synkron sekundær automatisk over, og gjenoppretter tilgangen på sekunder uten delt lagring eller manuell inngripen.

1.2 Alltid på tilgjengelighetsgrupper kontra failover-klyngeforekomster

SQL Server Always On inkluderer to forskjellige teknologier: Tilgjengelighetsgrupper (AG) og Failover Cluster Instances (FCI):

	Alltid på tilgjengelighetsgrupper	Alltid på failover-klyngeforekomster
Failover-omfang	Databasenivå	Instansnivå (alle databaser utfører feilovergang samtidig)
Data replikering	Loggbasert replikering til hver sekundær	Ingen – alle noder deler samme lagring
Delt lagring	Ikke obligatorisk	Påkrevd (Storage Area Network (SAN), iSCSI, S2D eller SMB)
Lesbare sekundærer	Ja	Nei
katastrofe~~POS=TRUNC gjenoppretting~~POS=HEADCOMP	Innebygd (asynkrone replikaer på tvers av nettsteder)	Ikke innebygd uten paring med AG

Når du skal bruke hver av dem: Bruk FCI når du trenger failover på instansnivå og allerede har delt lagringsinfrastruktur. Bruk AG når du trenger granularitet på databasenivå, lesbare sekundærfiler eller katastrofegjenoppretting. For den mest komplette beskyttelsen, kombiner begge deler: kjør hver replika som en FCI-node og koble dem sammen i en AG.

1.3 Fordeler og begrensninger

Fordeler:

• Automatisk failover med nesten null gjenopprettingstidsmål (RTO) for synkrone replikaer;
• null datatap (gjenopprettingspunktmål (RPO) = 0) i synkron iverksettelsesmodus;
• ingen delt lagring kreves – hver replika bruker uavhengig lokal lagring;
• lesbare sekundærenheter avlaster rapportering og sikkerhetskopieringsarbeidsbelastninger fra primæren;
• støtter både lokal høy tilgjengelighet (HA) og katastrofegjenoppretting på tvers av nettsteder (DR) i én enkelt konfigurasjon.

Begrensninger:

• Krever Windows Server Failover Clustering på alle replikaer;
• Enterprise Edition for komplett funksjonssett (Standard Edition støtter Basic AG med betydelige begrensninger);
• synkron-commit-modus legger til latens i skriveoperasjoner proporsjonal med nettverkets rundturstid;
• pålogginger, SQL Agent-jobber og koblede servere synkroniseres ikke automatisk i SQL Server 2019 og tidligere (løst i SQL Server 2022 inneholdt tilgjengelighetsgrupper).

2. Arkitektur for alltid på tilgjengelighetsgrupper

2.1 Kjernekomponenter og konsepter

2.1.1 Tilgjengelighetsdatabaser

Tilgjengelighetsdatabaser er brukerdatabasene som deltar i en tilgjengelighetsgruppe. Disse databasene må oppfylle spesifikke krav: de må bruke den fullstendige gjenopprettingsmodellen, ha en fullstendig sikkerhetskopi og finnes på den primære replikaen før de legges til i en tilgjengelighetsgruppe.

Når en database blir med i en tilgjengelighetsgruppe, blir den en del av et synkronisert sett som feiloverføres som en enhet. Alle databaser i en tilgjengelighetsgruppe deler samme failover-tilstand, som betyr at hvis den primære replikaen feiler, vil alle databaser feiloverføres til den samme sekundære replikaen samtidig. Dette sikrer konsistens for applikasjoner som er avhengige av flere relaterte databaser.

2.1.2 Tilgjengelighetsreplikaer

Tilgjengelighetsreplikaer er SQL Server instanser som er vert for kopier av tilgjengelighetsdatabaser. Hver replika vedlikeholder sin egen fysiske kopi av databasene, synkronisert gjennom forsendelse av transaksjonsloggposter. En tilgjengelighetsgruppe kan inneholde opptil ni replikaer: én primær replika og opptil åtte sekundære replikaer.

2.1.3 Primær replika

Primærreplikaen er vert for lese-/skrivekopien av tilgjengelighetsdatabasene. Alle dataendringer (SETT INN, UPDATE, SLETT) skjer på primærreplikaen. Klientapplikasjoner kobler seg til primærreplikaen for alle skriveoperasjoner, og som standard også for leseoperasjoner.

2.1.4 Sekundære replikaer

Sekundære replikaer er vert for skrivebeskyttede kopier av tilgjengelighetsdatabasene, som vedlikeholdes gjennom kontinuerlig bruk av transaksjonsloggposter mottatt fra den primære replikaen. Hver sekundære replika mottar, forsterker og bruker loggposter for å holde databasekopiene synkronisert med den primære.

2.2 Tilgjengelighetsmoduser

2.2.1 Synkron-Commit-modus

Synkron iverksettelsesmodus gir null beskyttelse mot datatap ved å kreve at den primære replikaen venter på bekreftelse på at transaksjonsloggpostene er herdet på den sekundære replikaen før transaksjoner iverksettes. Denne modusen er viktig for konfigurasjoner med høy tilgjengelighet der datatap er uakseptabelt.

2.2.2 Asynkron iverksettelsesmodus

Asynkron iverksettelsesmodus prioriterer ytelsen til den primære replikaen ved å tillate transaksjoner å iverksette uten å vente på at sekundære replikaer skal bekrefte loggherding. Denne modusen er passende for replikaer etter katastrofegjenoppretting eller når nettverksforsinkelse gjør synkron iverksettelse upraktisk.

Avveiningen er potensielt datatap under failover. Hvis den primære replikaen feiler, kan det hende at noen igangsatte transaksjoner ikke har nådd den sekundære replikaen. Mengden potensielt datatap avhenger av nettverksbåndbredde, ytelse for sekundær replika og tidspunktet for feilen. Organisasjoner må akseptere denne risikoen når de bruker asynkron modus.

2.3 Failover-typer

2.3.1 Automatisk failover

Automatisk failover gjør det mulig for tilgjengelighetsgruppen å oppdage feil i den primære replikaen og automatisk forfremme en sekundær replika til primær uten administratorinngripen. Denne funksjonen minimerer RTO ved å eliminere behovet for manuell respons på feil.

Automatisk failover krever synkron iverksettelsesmodus for å sikre null datatap. Når tilgjengelighetsgruppen er aktivert, overvåker den kontinuerlig tilstanden til den primære replikaen. Hvis den primære replikaen slutter å reagere eller feiler, starter Windows Server Failover Cluster automatisk failover til en angitt sekundær replika.

2.3.2 Manuell failover

Manuell failover lar administratorer bevisst bytte den primære replikarollen til en sekundær replika, vanligvis for planlagt vedlikehold eller testformål. I motsetning til automatisk failover krever manuell failover eksplisitt administratorhandling for å starte.

Manuell failover uten datatap er tilgjengelig for synkrone iverksettelsesreplikaer. Administratoren starter failoveren gjennom SQL Server Management Studio, Transact-SQL eller PowerShell. Den primære replikaen fullfører behandlingen av gjeldende transaksjoner, sender alle gjenværende loggposter til målsekundærrollen og venter på bekreftelse før den primære rollen overføres.

Manuell failover kan også forekomme med asynkrone replikaer med iverksettelse, men dette krever tvungen failover med potensielt datatap. Administratorer bør bare bruke tvungen manuell failover under faktiske katastrofescenarier når den primære replikaen ikke er tilgjengelig og datatap er akseptabelt sammenlignet med utvidet nedetid.

2.3.3 Tvungen failover

Tvungen failover tillater failover til en asynkron sekundær replika eller til en sekundær som ikke er fullstendig synkronisert, med eksplisitt erkjennelse av potensielt datatap. Dette alternativet fungerer som en siste utvei når den primære replikaen ikke er tilgjengelig og det ikke finnes noen synkronisert sekundær.

2.4 Datasynkronisering

2.4.1 Hvordan datasynkronisering fungerer

Datasynkronisering i Always On Availability Groups skjer gjennom kontinuerlig forsendelse av transaksjonsloggposter fra den primære replikaen til alle sekundære replikaer. Denne loggbaserte synkroniseringen sikrer konsistens samtidig som den tillater uavhengig lagring for hver replika.

2.4.2 Transaksjonsloggoppføringer og herding

Transaksjonsloggherding er det kritiske trinnet der loggposter skrives til varig lagring på sekundære replikaer. Herding sikrer at loggposter overlever feil i sekundære replikaer og kan spilles av på nytt under gjenoppretting.

2.5 Leseskala og lesbare sekundære replikaer

2.5.1 Avlasting av skrivebeskyttede arbeidsbelastninger

Lesbare sekundære replikaer gjør det mulig for organisasjoner å avlaste leseintensive arbeidsbelastninger fra den primære replikaen, noe som forbedrer den generelle systemytelsen og ressursutnyttelsen. Denne leseskaleringsmuligheten er en av hovedfordelene med tilgjengelighetsgrupper fremfor eldre løsninger med høy tilgjengelighet.

Organisasjoner bør vurdere krav til skrivebeskyttet arbeidsbelastning når de utformer konfigurasjoner for tilgjengelighetsgrupper. Flere lesbare sekundærer kan fordele rapporteringsbelastningen på tvers av flere servere. Skrivebeskyttede rutingslister definerer rekkefølgen sekundærer mottar leseintensjonstilkoblinger, noe som muliggjør strategier for lastbalansering.

2.5.2 Sikkerhetskopieringsoperasjoner på sekundære replikaer

Å kjøre sikkerhetskopier på sekundære replikaer reduserer belastningen på input/output (I/O) og CPU-en (Central Processing Unit) på den primære replikaen, slik at den kan fokusere på transaksjonelle arbeidsbelastninger. Denne funksjonen hjelper organisasjoner med å oppfylle krav til sikkerhetskopiering uten å påvirke produksjonsytelsen.

SQL Server støtter fullstendige sikkerhetskopier av databaser, differensielle sikkerhetskopier og sikkerhetskopier av transaksjonslogger på sekundære replikaer. Sikkerhetskopieringsinnstillinger kan konfigureres til å foretrekke sekundære replikaer, primær, kun sekundær eller en hvilken som helst replika. Sikkerhetskopieringssystemet velger automatisk en passende replika basert på disse innstillingene og gjeldende tilgjengelighet.

For mer informasjon om SQL Server sikkerhetskopiering, se vår omfattende guide.

2.6 Lyttere for tilgjengelighetsgruppen

2.6.1 Hva er en lytter?

En lytter for tilgjengelighetsgrupper er et virtuelt nettverksnavn (VNN) og en IP-adresse som klientapplikasjoner bruker for å koble til databaser for tilgjengelighetsgrupper. Lytteren omdirigerer automatisk tilkoblinger til den gjeldende primære replikaen, noe som eliminerer behovet for at applikasjoner sporer hvilken server som for øyeblikket er primær.

2.6.2 Ruting av klienttilkobling

Klienttilkoblingsruting gjennom lytteren støtter både lese-skrive- og skrivebeskyttede tilkoblingsintensjoner. Lytteren undersøker tilkoblingsforespørselen og ruter den til riktig replika basert på applikasjonens intensjon.

3. Forutsetninger og krav

3.1 Windows Server Failover-klynger for tilgjengelighetsgrupper

3.1.1 Grunnleggende om Windows Server Failover Clustering

Windows Server Failover Clustering (WSFC) danner grunnlaget for Always On Availability Groups ved å administrere klyngemedlemskap, tilstandsovervåking og failover-orkestrering. I motsetning til Failover Cluster Instances bruker tilgjengelighetsgrupper WSFC bare til klyngekoordinering, ikke til administrasjon av delt lagring.

hver enkelt SQL Server Instansen som deltar i en tilgjengelighetsgruppe må være en node i en WSFC-klynge. Klyngen administrerer quorumavstemning, nodetilstandsdeteksjon og tilgjengelighetsgrupperessurstilstand. Når den primære replikaen feiler, koordinerer WSFC failover-prosessen og oppdaterer klyngeressurser for å gjenspeile den nye primære replikaen.

3.1.2 Konfigurasjon av klyngequorum

Klyngequorum bestemmer hvilke noder som kan operere når det oppstår problemer med nettverkstilkoblingen, og forhindrer dermed split-brain-scenarier der flere noder uavhengig av hverandre hevder å være primære. Quorum-konfigurasjonen definerer hva som utgjør et flertallsvalg for klyngebeslutninger.

Flere quorummoduser er tilgjengelige for tilgjengelighetsgrupper:

• Node Majority bruker bare klyngenodestemmer og fungerer bra for klynger med et odde antall noder.
• Node- og fildelingsflertall legger til en vitneavstemning for fildeling, egnet for nodeklynger med partall.
• Node- og diskmajoritet bruker et diskvitne, men er mindre vanlig for tilgjengelighetsgrupper siden delt lagring ikke er nødvendig.

3.1.3 Klynging av flere undernett

Klynging med flere undernett gjør det mulig for replikaer av tilgjengelighetsgrupper å spenne over forskjellige nettverksundernett, noe som støtter geografisk distribuerte distribusjoner på tvers av datasentre. Denne funksjonen er viktig for konfigurasjoner for katastrofegjenoppretting der replikaer finnes på separate steder.

3.2 SQL Server Utgavekrav

3.2.1 Funksjoner i Enterprise Edition

SQL Server Enterprise Edition tilbyr full funksjonalitet for tilgjengelighetsgrupper uten begrensninger. Enterprise Edition støtter opptil åtte sekundære replikaer, lesbare sekundærfiler, automatisk seeding, distribuerte tilgjengelighetsgrupper og alle avanserte funksjoner.

3.2.2 Funksjoner i standardutgaven (grunnleggende tilgjengelighetsgrupper)

SQL Server Standardutgaven fra 2016 og senere støtter grunnleggende tilgjengelighetsgrupper med betydelige begrensninger. Grunnleggende tilgjengelighetsgrupper gir sentral funksjonalitet med høy tilgjengelighet til en lavere kostnad, egnet for organisasjoner med enklere krav.

4. Konfigurering av alltid-på-tilgjengelighetsgrupper

4.1 Forberedelse av miljøet

Før du oppretter en tilgjengelighetsgruppe, må miljøet være ordentlig klargjort med Active Directory-kontoer, serverkonfigurasjoner og nettverksinfrastruktur på plass.

4.1.1 Oppsett av domenekontroller

Active Directory-domenekontrolleren må konfigureres til å støtte tilgjengelighetsgruppeklyngen og SQL Server tjenestekontoer.

1. Logg inn på domenekontrolleren med domeneadministratorpåloggingsinformasjon.
2. Open Server Manager og naviger til verktøy -> Active Directory-brukere og datamaskiner.
3. Opprett en organisasjonsenhet for SQL Server objekter hvis et ikke finnes.
4. Kontroller at datamaskinobjekter for alle klyngenoder finnes i Active Directory.
5. Sørg for at DNS-tjenestene (Domain Name System) er riktig konfigurert, og at alle servernavn løses riktig.

4.1.2 Opprette tjenestekontoer

Opprett dedikerte Active Directory-tjenestekontoer for SQL Server tjenester på hver node.

1. Open Active Directory-brukere og datamaskiner på domenekontrolleren.
2. Høyreklikk på den aktuelle organisasjonsenheten og velg Ny -> Bruker.
3. Skriv inn tjenestekontonavnet (for eksempel svc_SQLServer) og angi Brukerens påloggingsnavn.
4. Klikk neste og skriv inn et sterkt passord.
5. Velg Brukeren kan ikke endre passord og Passord utløper aldri.
6. Klikk neste og deretter Finish for å opprette kontoen.
7. Gjenta for eventuelle ekstra tjenestekontoer som trengs (SQL Server Agent, SSRS, osv.).

4.1.3 Konfigurering av administratorrettigheter

Tjenestekontoer og kontoene som brukes til å konfigurere SQL Server må ha nødvendige tillatelser på alle klyngenoder.

1. Logg inn på hver klyngenodeserver.
2. Open Datamaskinbehandling fra Start meny eller Serverbehandling.
3. Expand Lokale brukere og grupper og velg Grupper.
4. Høyreklikk administratorer og velg Eiendommer.
5. Klikk Legg til og skriv inn navnet på tjenestekontoen.
6. Klikk Sjekk navnene for å validere kontoen, og klikk deretter OK.
7. Klikk OK for å lukke dialogboksen Administratoregenskaper.
8. Gjenta på alle klyngenoder.

4.2 Installere og konfigurere WSFC

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

4.2.1 Installere funksjonen for failover-klynging

Installer funksjonen for failover-klynger på hver server som skal delta i tilgjengelighetsgruppen.

1. Open Server Manager på den første klyngenoden.
2. Klikk Administrer -> Legg til roller og funksjoner.
3. Klikk neste gjennom introduksjonsskjermene.
4. Velg Rollebasert eller funksjonsbasert installasjon og klikk neste.
5. Velg den lokale serveren og klikk neste.
6. Hopp over Roller-skjermen og klikk på neste.
7. På Funksjonsskjermen velger du Failover Clustering.
8. Klikk Legg til funksjoner når du blir bedt om å inkludere administrasjonsverktøy.
9. Klikk neste og deretter Install.
10. Vent til installasjonen er fullført og klikk Lukke.
11. Gjenta på alle servere som skal delta i klyngen.

4.2.2 Opprette failover-klyngen

Etter at du har installert Failover Clustering-funksjonen på alle noder, oppretter du klyngen fra én node.

1. Open Failover-klyngeadministrator fra Server Manager -> verktøy.
2. Klikk Opprett klynge i Handlinger-ruten.
3. Klikk neste på siden Før du begynner.
4. Klikk Søk og legg til alle servere som skal være klyngenoder.
5. Klikk neste etter å ha lagt til alle nodene.
6. Permisjon Kjør alle tester (anbefales) valgt og klikk neste.
7. Gjennomgå resultatene av valideringstesten og rett opp eventuelle feil eller advarsler.
8. Klikk Finish etter at valideringen er fullført.
9. Skriv inn et navn for klyngen og en IP-adresse.
10. Fjern merkingen Legg til all kvalifisert lagring i klyngen ettersom delt lagring ikke er nødvendig.
11. Klikk neste og gjennomgå bekreftelsen.
12. Klikk Finish for å opprette klyngen.

4.2.3 Validere klyngekonfigurasjonen

Valider klyngekonfigurasjonen for å sikre at alle noder kan kommunisere ordentlig og at klyngen fungerer som den skal.

1. In Failover-klyngeadministrator, høyreklikk på klyngenavnet.
2. Velg Valider klynge fra menyen.
3. Klikk neste på siden Før du begynner.
4. Velg Kjør alle tester (anbefales) og klikk neste.
5. Klikk neste for å starte valideringstester.
6. Gjennomgå valideringsrapporten når testene er fullført.
7. Håndter eventuelle feil eller advarsler som er identifisert i rapporten.
8. Klikk Finish for å lukke veiviseren.

4.3 Installasjon SQL Server for tilgjengelighetsgrupper

Install SQL Server på hver node som skal delta i tilgjengelighetsgruppen ved hjelp av alternativet for frittstående installasjon.

1. Kjør SQL Server installasjonsmediet på den første noden.
2. Velg Ny SQL Server frittstående installasjon.
3. Skriv inn produktnøkkelen eller velg evalueringsversjonen.
4. Godta lisensvilkårene og klikk neste.
5. Fullfør nødvendige kontroller og løs eventuelle problemer.
6. På siden Funksjonsvalg velger du Databasemotortjenester.
7. Konfigurer forekomstnavn (bruk samme forekomstnavn på alle noder).
8. På siden Serverkonfigurasjon angir du påloggingsinformasjonen for tjenestekontoen.
9. Konfigurer oppstartstyper for tjenester som Automatisk.
10. På konfigurasjonssiden for databasemotoren velger du autentiseringsmodus.
11. Legg til administratorkontoer.
12. Konfigurer datakataloger ved hjelp av konsistente stier på tvers av alle noder.
13. Fullfør installasjonen og bekreft at den er vellykket.
14. Gjenta installasjonen på alle andre klyngenoder med identiske innstillinger.

4.4 Aktivering av funksjonen for alltid på-tilgjengelighetsgrupper

Etter å ha installert SQL Server På alle noder, aktiver funksjonen Always On Availability Groups på hver instans.

4.4.1 Aktivering via SQL Server Konfigurasjonsbehandling

Bruk SQL Server Konfigurasjonsbehandling for å aktivere Always On-tilgjengelighetsgrupper via det grafiske grensesnittet.

1. Open SQL Server Konfigurasjonsbehandling på den første noden.
2. Expand SQL Server Tjenester i venstre rute.
3. Høyreklikk på SQL Server eksempel og velg Eiendommer.
4. Klikk på AlwaysOn høy tilgjengelighet fanen.
5. Trykk her Aktiver AlwaysOn-tilgjengelighetsgrupper.
6. Kontroller at navnet på Windows-failover-klyngen er riktig.
7. Klikk OK for å lagre endringene.
8. Klikk OK på advarselen om at tjenesten må startes på nytt.
9. Høyreklikk på SQL Server tjeneste og velg Restart.
10. Vent til tjenesten starter på nytt.
11. Gjenta på alle klyngenoder.

4.4.2 Aktivering via PowerShell

PowerShell tilbyr en skriptmetode for å aktivere Always On Availability Groups på tvers av flere noder.

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

   Import-Module SQLPS -DisableNameChecking

3. Aktiver alltid på-tilgjengelighetsgrupper:

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

4. Tjenesten vil automatisk starte på nytt når du bruker Force-parameteren.
5. Bekreft at funksjonen er aktivert:

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

6. Gjenta for hver klyngenode, og erstatt med riktige server- og forekomstnavn.

4.4.3 Bekrefte at funksjonen er aktivert

Kontroller at Always On Availability Groups er aktivert på alle forekomster før du fortsetter med konfigurasjonen.

1. Koble til hver SQL Server eksempel ved bruk av SQL Server ManagementStudio.
2. Åpne et nytt spørrevindu og utfør:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Bekreft at resultatet er 1 (aktivert).
4. Sjekk at SQL Server instansen vises i Failover Cluster Manager under klyngeroller.
5. Bekreft at tilgjengelighetsgruppens endepunkt finnes ved å kjøre:

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

6. Hvis endepunktet ikke finnes, vil det bli opprettet under opprettelsen av tilgjengelighetsgruppen.

4.5 Klargjøre databaser for tilgjengelighetsgrupper

Databaser må oppfylle spesifikke krav før de kan legges til i en tilgjengelighetsgruppe.

4.5.1 Krav til databasegjenopprettingsmodell

Endre databasegjenopprettingsmodellen til FULL på den primære replikaen før du legger den til i en tilgjengelighetsgruppe.

1. Koble til den primære replikaen ved hjelp av SQL Server ManagementStudio.
2. Høyreklikk på databasen og velg Eiendommer.
3. Velg alternativer side.
4. Endring Gjenopprettingsmodell til Full.
5. Klikk OK for å lagre endringen.
6. Alternativt kan du bruke Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Ta fullstendige sikkerhetskopier av databasen

Ta en fullstendig sikkerhetskopi av databasen for å etablere sikkerhetskopikjeden som kreves for tilgjengelighetsgrupper.

1. In SQL Server Management Studio, høyreklikk på databasen.
2. Velg Oppgaver -> Sikkerhetskopiere.
3. Bekreft Sikkerhetskopieringstype er satt til Full.
4. Velg et sikkerhetskopimål eller legg til et nytt mål.
5. Klikk OK for å utføre sikkerhetskopieringen.
6. Alternativt kan du bruke Transact-SQL:

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

4.5.3 Ta sikkerhetskopier av transaksjonslogger

Ta en sikkerhetskopi av transaksjonsloggen for å sikre at loggkjeden er etablert og minimere initialiseringstiden.

1. In SQL Server Management Studio, høyreklikk på databasen.
2. Velg Oppgaver -> Sikkerhetskopiere.
3. Endring Sikkerhetskopieringstype til Transaksjonslogg.
4. Velg et sikkerhetskopimål.
5. Klikk OK for å utføre sikkerhetskopieringen.
6. Alternativt kan du bruke Transact-SQL:

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

4.6 Opprette tilgjengelighetsgruppen

Opprett tilgjengelighetsgruppen ved hjelp av en av flere tilgjengelige metoder, avhengig av dine preferanser og automatiseringskrav.

4.6.1 Bruke veiviseren for ny tilgjengelighetsgruppe

Veiviseren for ny tilgjengelighetsgruppe har et grafisk grensesnitt for å opprette tilgjengelighetsgrupper.

1. In SQL Server Management Studio, koble til forekomsten som skal være vert for den primære replikaen.
2. Expand AlwaysOn høy tilgjengelighet i Objektutforskeren.
3. Høyreklikk Tilgjengelighetsgrupper og velg Veiviser for ny tilgjengelighetsgruppe.
   
4. Klikk neste på introduksjonssiden.
5. Skriv inn et navn for tilgjengelighetsgruppen og klikk på neste.
6. På siden Velg databaser velger du databasene som skal inkluderes.
7. Bekreft at databasene oppfyller alle kravene, og klikk på neste.
8. På siden Angi replikaer klikker du på Legg til replika.
9. Koble til hver sekundære replikaforekomst.
10. Konfigurer replikaegenskaper for hver forekomst (tilgjengelighetsmodus, failover-modus).
11. Klikk på endepunkter fanen og gjennomgå konfigurasjonen av endepunktet.
12. Klikk på Sikkerhetskopieringsinnstillinger fanen og konfigurer prioriteter for sikkerhetskopiering.
13. Klikk på lytteren tab og eventuelt opprett en lytter.
14. Klikk neste og velg datasynkroniseringsmetoden.
15. Gjennomgå valideringsresultatene og løse eventuelle problemer.
16. Klikk neste og gjennomgå sammendraget.
17. Klikk Finish for å opprette tilgjengelighetsgruppen.
18. Overvåk fremdriften og bekreft at opprettelsen er vellykket.

4.6.2 Bruk av Transact-SQL

Opprett tilgjengelighetsgrupper ved hjelp av Transact-SQL for skriptbare, repeterbare distribusjoner.

1. Opprett tilgjengelighetsgruppen på den primære replikaen:

   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. Bli med i den sekundære replikaen i tilgjengelighetsgruppen:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Bli med i den sekundære databasen:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Bruk av PowerShell

PowerShell tilbyr skriptfunksjoner for oppretting og administrasjon av tilgjengelighetsgrupper.

1. Opprett tilgjengelighetsgruppeobjektet:

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

2. Legg til databaser:

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

3. Konfigurer replikaer med ønskede egenskaper ved hjelp av cmdleten New-SqlAvailabilityReplica.
4. Koble til sekundære replikaer ved hjelp av cmdleten Join-SqlAvailabilityGroup.

4.7 Legge til replikaer i tilgjengelighetsgruppen

Konfigurer replikaspesifikke egenskaper som styrer hvordan hver forekomst deltar i tilgjengelighetsgruppen.

4.7.1 Konfigurere replikaegenskaper

Angi egenskaper for hver replika for å definere dens rolle og funksjoner innenfor tilgjengelighetsgruppen.

1. In SQL Server Ledelsestudio, utvid AlwaysOn høy tilgjengelighet -> Tilgjengelighetsgrupper.
2. Utvid tilgjengelighetsgruppen, og utvid deretter Tilgjengelighetsreplikaer.
   
3. Høyreklikk på en replika og velg Eiendommer.
4. Gjennomgå og endre tilkoblingsinnstillinger for primær- og sekundærrollene.
5. Konfigurer verdier for tidsavbrudd for økten om nødvendig.
6. Klikk OK for å lagre endringer.

4.7.2 Angi tilgjengelighetsmoduser

Konfigurer tilgjengelighetsmodus for å kontrollere synkroniseringsvirkemåten mellom replikaer.

1. Høyreklikk på tilgjengelighetsgruppen og velg Eiendommer.
2. på Informasjon siden, gå til Tilgjengelighetsreplikaer seksjon.
3. For hver replika, velg Synkron commit or Asynkron commit fra rullegardinmenyen.
4. Bruk synkron commit for lokale replikaer med høy tilgjengelighet.
5. Bruk asynkron commit for geografisk fjerne replikaer for katastrofegjenoppretting.
6. Klikk OK for å lagre konfigurasjonen.

4.7.3 Angi failover-moduser

Konfigurer failover-modus for å kontrollere hvordan failover skjer for hver replika.

1. Høyreklikk på tilgjengelighetsgruppen og velg Eiendommer.
2. på Informasjon siden, gå til Tilgjengelighetsreplikaer seksjon.
3. For synkrone iverksettelsesreplikaer, velg Automatisk or Håndbok failover-modus.
4. Automatisk failover krever synkron iverksettelsesmodus og aktiverer uovervåket failover.
5. For asynkrone iverksettelsesreplikaer er bare manuell failover tilgjengelig.
6. Konfigurer opptil tre replikaer for automatisk failover (én primær og to sekundær).
7. Klikk OK for å bruke innstillingene.

4.7.4 Konfigurering av sikkerhetskopieringsinnstillinger

Angi sikkerhetskopieringsinnstillinger for å kontrollere hvor sikkerhetskopieringsoperasjoner skal utføres.

1. Høyreklikk på tilgjengelighetsgruppen og velg Eiendommer.
2. Velg Sikkerhetskopieringsinnstillinger i venstre rute.
3. Velg én av sikkerhetskopieringsinnstillingene:
   • Foretrekk sekundærSikkerhetskopier på sekundær hvis tilgjengelig, ellers primær
   • Bare sekundærtSikkerhetskopier kun på sekundære replikaer
   • primærSikkerhetskopier kun på primærreplika
   • Enhver kopiSikkerhetskopier på alle tilgjengelige replikaer
4. Angi prioritetsverdier for sikkerhetskopiering for hver replika (0–100).
5. Høyere prioritetsverdier angir foretrukne sikkerhetskopieringsmål.
6. Klikk OK for å lagre innstillingene.

4.8 Konfigurering av tilgjengelighetsgruppens lytter

Opprett en lytter for å gi et enkelt tilkoblingspunkt som automatisk omdirigerer til den gjeldende primære replikaen.

4.8.1 Opprette lytteren

Legg til en lytter i tilgjengelighetsgruppen for klienttilkoblingsadministrasjon.

1. In SQL Server Management Studio, utvid tilgjengelighetsgruppen.
2. Høyreklikk Tilgjengelighetsgruppelyttere og velg Legg til lytter.
   
3. Skriv inn et DNS-navn for lytteren (for eksempel AG_Listener).
4. Skriv inn portnummeret (standard er 1433).
5. Velg Statisk IP for nettverksmodus.
6. Klikk Legg til for å legge til en IP-adresse for hvert delnett.
7. Skriv inn IP-adressen og velg delnettet.
8. Klikk OK å skape lytteren.
9. Bekreft at lytteren vises i Object Explorer og er online.

4.8.2 Konfigurering av DNS- og IP-innstillinger

Bekreft DNS-registrering og nettverkskonfigurasjon for lytteren.

1. Åpne DNS Manager på domenekontrolleren.
2. Bekreft at lytternavnet er registrert med alle IP-adresser.
3. Test DNS-oppløsning fra klientmaskiner:

   nslookup ListenerName

4. Bekreft at alle konfigurerte IP-adresser returneres.
5. I Failover Cluster Manager, utvid Roller og velg tilgjengelighetsgruppen.
6. Bekreft at IP-adresseressursene er online.
7. Sjekk at nettverksnavnressursen er online.
   

4.8.3 Testing av lyttertilkobling

Kontroller at klientapplikasjoner kan koble til via lytteren.

1. Fra en klientmaskin, åpne SQL Server ManagementStudio.
2. Koble til ved hjelp av lytternavnet i stedet for et servernavn.
3. Kjør en spørring for å bekrefte tilkoblingen til gjeldende primære replika:

   SELECT @@SERVERNAME;

4. Test leseintensjonsruting ved å legge til ApplicationIntent=ReadOnly i tilkoblingsstrengen.
5. Bekreft omdirigering av tilkoblinger til en lesbar sekundær replika.
6. Test failover ved å manuelt failovere tilgjengelighetsgruppen og bekrefte ny tilkobling.

4.9 Metoder for datasynkronisering

Velg en datasynkroniseringsmetode for å initialisere sekundære replikaer med databasekopier.

4.9.1 Automatisk såing

Automatisk seeding overfører databasedata over nettverket uten behov for manuell sikkerhetskopiering og gjenoppretting.

1. Under opprettelsen av tilgjengelighetsgruppen, velg Automatisk såing som synkroniseringsmetode.
   
2. Sørg for nettverkstilkobling og tilstrekkelig båndbredde mellom replikaene.
3. Den primære replikaen strømmer automatisk databasedata til sekundære replikaer.
4. Overvåk fremdriften for såing ved hjelp av tilgjengelighetsgruppens dashbord eller DMV-er.
5. Automatisk såing krever SQL Server 2016 eller nyere.
6. For store databaser, vurder nettverkspåvirkning og planlegging i perioder med lav bruk.

4.9.2 Manuell seeding (sikkerhetskopiering og gjenoppretting)

Manuell seeding innebærer å ta sikkerhetskopier på den primære og gjenopprette dem på sekundære replikaer.

1. Ta en fullstendig sikkerhetskopi på den primære replikaen:

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

2. Ta en sikkerhetskopi av transaksjonsloggen:

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

3. Gjenopprett den fullstendige sikkerhetskopien på hver sekundære replika:

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

4. Gjenopprett sikkerhetskopien av loggen:

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

5. Bli med i databasen i tilgjengelighetsgruppen:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Bekreft at synkroniseringen starter og at databasen når statusen SYNKRONISERT.

4.9.3 Database-øyeblikksbilder

Bruk database-snapshot-filer til å initialisere sekundære replikaer fra eksisterende databasefiler.

1. Koble fra eller sikkerhetskopier databasen på den primære replikaen.
2. Kopier databasefiler til hver sekundære replika ved å bruke de samme filbanene.
3. På sekundære replikaer, koble til databasen eller gjenopprett uten gjenoppretting.
4. Sørg for at databasen er i GJENOPPRETTING-tilstand.
5. Bli med i databasen i tilgjengelighetsgruppen.
6. Denne metoden er nyttig for svært store databaser der nettverksoverføring ville være upraktisk.

5. FAQ

5.1 Generelle spørsmål

Spørsmål: Hva er forskjellen mellom Always On FCI og Always On AG?

A: Always On Failover Cluster-instanser gir høy tilgjengelighet på instansnivå ved bruk av delt lagring, mens Always On Availability Groups gir høy tilgjengelighet på databasenivå uten delt lagring. AG tilbyr lesbare sekundærer og mer fleksibel geografisk distribusjon.

Spørsmål: Kan jeg bruke Alltid på-tilgjengelighetsgrupper med SQL Server Standardutgave?

A: Ja, SQL Server 2016 Standard Edition og senere støtter Basic Availability Groups med begrensninger, inkludert én database per AG, maksimalt to replikaer og ingen lesbar sekundær støtte.

Spørsmål: Trenger jeg delt lagring for Always On Availability Groups?

A: Nei, tilgjengelighetsgrupper krever ikke delt lagring. Hver replika opprettholder uavhengige kopier av databaser på lokal lagring, synkronisert gjennom transaksjonsloggforsendelse.

Spørsmål: Hva er det maksimale antallet replikaer i en tilgjengelighetsgruppe?

A: SQL Server Enterprise Edition støtter opptil ni replikaer (én primær og åtte sekundære). Distribuerte tilgjengelighetsgrupper kan støtte opptil 18 replikaer totalt på tvers av to tilgjengelighetsgrupper.

5.2 Konfigurasjonsspørsmål

Spørsmål: Hvordan velger jeg mellom synkrone og asynkrone commit-moduser?

A: Bruk synkron commit for null datatap innenfor samme datasenter eller nettverk med lav latens. Bruk asynkron commit for fjerne replikaer etter katastrofegjenoppretting der synkron commit ville påvirke ytelsen.

Spørsmål: Kan jeg blande synkrone og asynkrone replikaer i samme tilgjengelighetsgruppe?

A: Ja, tilgjengelighetsgrupper støtter blandede konfigurasjoner med både synkrone og asynkrone replikaer. Dette muliggjør lokal høy tilgjengelighet med synkrone replikaer og fjern katastrofegjenoppretting med asynkrone replikaer.

Q: Hva skjer med tilkoblingene mine under failover?

A: Eksisterende tilkoblinger blir brutt når det oppstår en failover. Applikasjoner med logikk for tilkoblingsforsøk kobler seg automatisk til den nye primære tilkoblingen gjennom lytteren. Failover-prosessen fullføres vanligvis i løpet av sekunder til minutter.

Spørsmål: Må jeg synkronisere pålogginger og jobber på tvers av replikaer?

A: I SQL Server 2019 og tidligere, ja – pålogginger, SQL Agent-jobber og tilkoblede servere må synkroniseres manuelt. SQL Server 2022 introduserer inneholdte tilgjengelighetsgrupper som automatisk inkluderer disse objektene.

5.3 Spørsmål til ledelsen

Spørsmål: Kan jeg kjøre sikkerhetskopier på sekundære replikaer?

A: Ja, sekundære replikaer støtter fullstendige sikkerhetskopier, differensielle sikkerhetskopier og sikkerhetskopier av transaksjonslogger. Konfigurer sikkerhetskopieringsinnstillinger for å avlaste sikkerhetskopier fra den primære replikaen og redusere ressursbruken.

Spørsmål: Hvordan oppdaterer jeg SQL Server med minimal nedetid?

A: Bruk rullerende oppgraderinger ved å først oppdatere sekundære replikaer, deretter utføre en manuell failover til en oppdatert sekundær, og til slutt oppdatere den tidligere primære. Dette minimerer nedetiden i forhold til failover-varigheten.

Spørsmål: Kan jeg legge til databaser i en eksisterende tilgjengelighetsgruppe?

A: Ja, databaser kan legges til i tilgjengelighetsgrupper som kjører. Databasen må være i full gjenopprettingsmodell med en full sikkerhetskopi, og sekundære replikaer må seedes ved hjelp av automatisk seeding eller manuell sikkerhetskopiering og gjenoppretting.

Spørsmål: Hva er automatisk såing, og bør jeg bruke det?

A: Automatisk seeding overfører databasedata over nettverket for å initialisere sekundære replikaer uten manuelle sikkerhetskopier. Bruk den for mindre databaser eller når nettverksbåndbredden er tilstrekkelig. For veldig store databaser kan manuell seeding være raskere.

Q: Hvor skal jeg kjøre DBCC CHECKDB i en tilgjengelighetsgruppe?

A: Du bør kjøre DBCC CHECKDB på sekundære replikaer for å redusere belastningen på den primære replikaen. Databasekonsistenskontroller kan kjøres mot sekundære databaser uten å påvirke ytelsen til primære replikaer.

For mer informasjon om DBCC CHECKDB, se vår omfattende guide.

5.4 Feilsøkingsspørsmål

Spørsmål: Hvorfor er databasen min i statusen IKKE SYNKRONISERER?

A: Vanlige årsaker inkluderer problemer med nettverkstilkobling, midlertidig stoppet dataflyt, utilstrekkelig diskplass på sekundære replikaer eller problemer med endepunktet. Sjekk beskrivelsen av synkroniseringshelse og SQL Server feillogger for spesifikke detaljer. Hvis den sekundære databasen har lagt inn en gjenopprettingsstatus eller viser gjenoppretting venter, se de lenkede veiledningene for målrettede løsninger.

Spørsmål: Hvordan tvinger jeg frem failover når primærversjonen ikke er tilgjengelig?

A: Koble til en sekundær replika og utfør ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Dette bekrefter potensielt datatap og forfremmer den sekundære til den primære umiddelbart.

Q: Hvorfor kan ikke klienter koble seg til lytteren min?

A: Bekreft at lytteren er online i Failover Cluster Manager, at DNS-registreringen er fullført, at alle lytter-IP-adresser er tilgjengelige fra klienter, og at brannmurregler tillater trafikk til lytterporten.

Q: Hva betyr en lang gjentakelseskø?

A: En lang gjentakelseskø indikerer at den sekundære replikaen ikke kan bruke loggposter like raskt som de ankommer. Dette kan tyde på flaskehalser på disk-I/O, CPU-begrensninger eller blokkering fra skrivebeskyttede spørringer på den sekundære.

Spørsmål: Hva bør jeg gjøre hvis en katastrofe påvirker alle replikaer og sikkerhetskopiene mine også er ødelagt?

A: Dette verst tenkelige scenarioet, selv om det er ekstremt sjeldent, kan oppstå på grunn av ransomware-angrep, omfattende lagringsfeil eller kaskadekatastrofer. Ditt primære forsvar er forebygging: vedlikehold geografisk distribuerte replikaer, lagre sikkerhetskopier på separate steder, og
Test regelmessig prosedyrene for gjenoppretting etter katastrofe. Hvis alle standard gjenopprettingsalternativer mislykkes, bør en spesialisert SQL-verktøy for datagjenoppretting kan forsøke å trekke ut data fra skadede MDF-filer som en siste utvei.

5.5 Lisens- og kostnadsspørsmål

Spørsmål: Hvordan lisensieres Always On Availability Groups?

A: SQL Server Lisensiering avhenger av utgaven og distribusjonsmodellen. Tilgjengelighetsgrupper for Enterprise Edition krever Enterprise-lisenser på alle replikaer. Passive sekundære replikaer kan kvalifisere for gratis lisensiering under visse betingelser.

Spørsmål: Kan jeg bruke SQL Server Utviklerutgave for tilgjengelighetsgrupper?

A: Ja, Developer Edition inkluderer alle funksjoner i Enterprise Edition, inkludert støtte for full tilgjengelighetsgrupper. Den er imidlertid kun lisensiert for utvikling og testing, ikke produksjonsbruk.

Spørsmål: Krever lesbare sekundærfiler ytterligere lisenser?

A: Lisensiering avhenger av scenarioet. Passive sekundærfiler for katastrofegjenoppretting krever vanligvis ikke lisenser. Aktive sekundærfiler som betjener skrivebeskyttede arbeidsbelastninger krever vanligvis lisenser, selv om spesifikke vilkår varierer.

Spørsmål: Finnes det en gratis måte å få høy tilgjengelighet med SQL Server?

A: SQL Server Express Edition støtter ikke tilgjengelighetsgrupper. SQL Server Standardutgaven støtter grunnleggende tilgjengelighetsgrupper som starter med SQL Server 2016, som tilbyr grunnleggende høy tilgjengelighet til Standard Edition-lisenskostnader.

Spørsmål: Hva er distribuerte tilgjengelighetsgrupper?

A: Distribuerte tilgjengelighetsgrupper er en spesiell type tilgjengelighetsgruppe som spenner over to separate tilgjengelighetsgrupper, og muliggjør scenarier som overgår mulighetene til tradisjonelle tilgjengelighetsgrupper. Introdusert i SQL Server I 2016 tar distribuerte tilgjengelighetsgrupper opp krav til skalering og geografisk distribusjon.

6. konklusjon

6.1 Sammendrag av nøkkelpunkter

SQL Server Always On Availability Groups representerer Microsofts fremste løsning for høy tilgjengelighet og katastrofegjenoppretting for forretningskritiske databaser. De tilbyr failover på databasenivå uten krav til delt lagring, lesbare sekundære replikaer for avlasting av arbeidsbelastninger og fleksibel geografisk distribusjon for omfattende databeskyttelse. For organisasjoner som fortsatt kjører løsninger som tømmerforsendelse or replikering, tilgjengelighetsgrupper tilbyr en mer robust og driftsmessig enklere oppgraderingsbane.

6.2 Når du skal bruke Alltid på-tilgjengelighetsgrupper

Velg tilgjengelighetsgrupper når du trenger høy tilgjengelighet på databasenivå med automatiske failover-funksjoner. Organisasjoner som trenger null datatapbeskyttelse for kritiske databaser, drar nytte av synkrone commit-replikaer med automatisk failover. Applikasjoner som krever leseskaleringsfunksjoner, utnytter lesbare sekundære replikaer for å distribuere spørrearbeidsbelastninger.

6.3 Komme i gang med implementeringen

Begynn planleggingen av tilgjengelighetsgruppen ved å vurdere forretningskrav, inkludert RTO, RPO og budsjettbegrensninger. Dokumenter gjeldende databaseinfrastruktur, applikasjonsavhengigheter og store tilgjengelighetshull. Design en arkitektur for tilgjengelighetsgruppen som adresserer kravene samtidig som den holder seg innenfor ressursbegrensningene.

Referanser

• Microsofts offisielle dokument: Hva er en Alltid på-tilgjengelighetsgruppe?
• Microsofts offisielle dokument: Komme i gang med alltid på-tilgjengelighetsgrupper
• Microsofts offisielle dokument: Distribuerte tilgjengelighetsgrupper

---

om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring innen SQL Server miljøer og administrasjon av bedriftsdatabaser. Han har løst hundrevis av databasegjenopprettingsscenarier på tvers av finansielle tjenester, helsevesen og produksjonsorganisasjoner.

Yuan spesialiserer seg på SQL Server databasegjenoppretting, løsninger for høy tilgjengelighet og ytelsesoptimalisering. Hans omfattende praktiske erfaring inkluderer administrasjon av databaser på flere terabyte, implementering av Always On Availability Groups og utvikling av automatiserte sikkerhetskopierings- og gjenopprettingsstrategier for forretningskritiske forretningssystemer.

Gjennom sin tekniske ekspertise og praktiske tilnærming fokuserer Yuan på å lage omfattende veiledninger som hjelper databaseadministratorer og IT-fagfolk med å løse komplekse SQL Server utfordringer effektivt. Han holder seg oppdatert på det siste SQL Server utgivelser og Microsofts utviklende databaseteknologier, og tester jevnlig gjenopprettingsscenarioer for å sikre at anbefalingene hans gjenspeiler beste praksis i den virkelige verden.

Har spørsmål vedr SQL Server gjenoppretting eller trenger du ytterligere veiledning for feilsøking av databaser? Yuan ønsker velkommen tilbakemeldinger og forslag for å forbedre disse tekniske ressursene.