Løs fejl i Exchange DAG-databasekopier

En Database Availability Group (DAG) i Microsoft Exchange Server er en fundamental komponent for at sikre høj tilgængelighed og databeskyttelse for postkassedatabaser. Ved at replikere databaser på tværs af flere servere, minimerer en DAG nedetid og sikrer, at brugerne kan fortsætte med at arbejde, selv hvis en server fejler. Men hvad sker der, når selve replikeringsprocessen eller et failover fejler? Disse situationer kan være kritiske og kræver en hurtig og korrekt indsats. Denne artikel vil guide dig gennem processen med at identificere, fejlfinde og løse almindelige problemer relateret til fejlbehæftede databasekopier og failover-scenarier i en Exchange DAG.

Forståelse af almindelige DAG-problemer

Før vi dykker ned i løsningerne, er det vigtigt at forstå, hvorfor problemer med DAG-databasekopier opstår. Årsagerne kan være mange og varierede, herunder:

• Netværksproblemer: Ustabile eller langsomme netværksforbindelser mellem DAG-medlemmer er en hyppig årsag til, at replikering fejler eller bliver sat på pause.
• Diskpladsproblemer: Utilstrækkelig diskplads på destinationsserveren kan forhindre en vellykket seeding eller replikering.
• Korrupte logfiler eller databaser: En beskadiget database eller transaktionslogfil på den aktive server kan stoppe replikeringsprocessen.
• Problemer med Cluster Service: Da en DAG er bygget på Windows Failover Clustering, kan problemer med selve klyngetjenesten direkte påvirke DAG'ens funktion.
• Active Directory replikeringsforsinkelser: Som vi vil se senere, kan forsinkelser i AD-synkronisering mellem domænecontrollere føre til uventede fejl under konfigurationen.

Trin-for-trin guide: Reseeding af en fejlbehæftet databasekopi

Når en postkassedatabasekopi i en Exchange Server DAG får status som "Failed", er det ofte nødvendigt at genstarte replikeringsprocessen ved at udføre en reseeding. Dette indebærer at erstatte den fejlbehæftede kopi med en frisk kopi fra den aktive database. Processen udføres via Exchange Management Shell.

Trin 1: Suspender replikeringen

Det første skridt er at suspendere replikeringen for den specifikke, fejlbehæftede databasekopi. Dette gøres for at forhindre yderligere replikeringsforsøg, mens vi forbereder os på at seede på ny. Kør følgende kommando på serveren, hvor kopien er fejlet:

[PS] C:\>Suspend-MailboxDatabaseCopy -Identity "Mailbox Database 01\EX2"

Du vil blive bedt om at bekræfte handlingen. Når du har bekræftet, vil status for databasekopien ændre sig fra "Failed" til "Failed and Suspended". Dette indikerer, at systemet anerkender fejlen, men ikke længere aktivt forsøger at rette den via automatisk replikering.

Trin 2: Opdater databasekopien (Reseeding)

Nu er det tid til at starte selve reseeding-processen. Dette gøres med kommandoen Update-MailboxDatabaseCopy. Parameteren -DeleteExistingFiles er vigtig, da den sikrer, at alle eksisterende (og potentielt korrupte) database- og logfiler på destinationsserveren slettes, før den nye kopi overføres.

[PS] C:\>Update-MailboxDatabaseCopy -Identity "Mailbox Database 01\EX2" -DeleteExistingFiles

Varigheden af denne proces afhænger direkte af databasens størrelse og netværkshastigheden mellem serverne. Når processen er fuldført, vil replikeringen automatisk blive genoptaget. Hvis du ønsker manuel kontrol over, hvornår replikeringen skal genoptages, kan du tilføje parameteren -ManualResume:

[PS] C:\>Update-MailboxDatabaseCopy -Identity "Mailbox Database 01\EX2" -DeleteExistingFiles -ManualResume

Fejlfinding ved et komplet DAG Failover-scenarie

Et failover er den proces, hvor en passiv databasekopi bliver den aktive, når den primære server går ned. Selvom dette burde være en automatisk og problemfri proces, kan der opstå komplikationer, især ved pludselige nedbrud som f.eks. en strømafbrydelse.

Forestil dig et scenarie: Din primære Exchange-server lukker uventet ned. Den sekundære server skulle tage over, men brugerne rapporterer, at de ikke kan oprette forbindelse til deres postkasser, hverken via Outlook eller OWA. Her er en tjekliste til fejlfinding:

1. Verificer DNS: Sørg for, at dine DNS-poster (både for mail og autodiscover) peger på IP-adresserne for *begge* DAG-medlemmer. Dette giver klienterne mulighed for at finde den aktive server, uanset hvilken det er.
2. Tjek klyngestatus: Brug PowerShell til at kontrollere sundheden af din Windows Failover Cluster. Kommandoen Get-ClusterNode skal vise den primære server som "Down" og den sekundære som "Up".
3. Kontroller databasekopiernes status: Kør Get-MailboxDatabaseCopyStatus * | Format-Table -AutoSize. Hvis du ser, at databaserne på den sekundære server ikke er monteret (Mounted), og deres "Content Index State" er "Failed", har du fundet kernen af problemet.
4. Undersøg databasens tilstand: Hvis databaserne ikke vil montere manuelt, kan det skyldes korruption. Brug ESEUtil til at tjekke databasens tilstand. Naviger til databasens filsti og kør: eseutil.exe /mh "min-database.edb". Kig efter linjen "State". Hvis den viser Dirty Shutdown, indikerer det, at databasen ikke blev lukket korrekt ned og kan være i en inkonsekvent tilstand.

Løsning af failover-problemet

Hvis den primære server er helt nede og ikke kan startes, og klyngen forhindrer den sekundære server i at montere databaserne, er den mest drastiske, men nødvendige, handling at fjerne den fejlbehæftede server fra klyngen. Dette kaldes "eviction". Når den døde server er fjernet fra klyngen, skulle den sekundære server kunne overtage ejerskabet fuldt ud og montere databaserne. En genstart af den sekundære server kan være nødvendig for at fuldføre processen. Hvis klienterne stadig har problemer, kan det midlertidigt være nødvendigt at ændre DNS, så den kun peger på den fungerende sekundære server, indtil en ny primær server er bygget.

Den specifikke fejl: "The seeding operation failed"

Nogle gange støder administratorer på en meget specifik fejlmeddelelse, når de forsøger at tilføje en ny databasekopi med Add-MailboxDatabaseCopy:

The seeding operation failed. Error: An error occurred while running prerequisite checks. Error: The specified database isn't configured for replication and therefore cannot be used to perform seed operations.

Denne fejl er ofte forvirrende, da databasen tydeligvis *er* en del af en DAG. Årsagen er typisk relateret til Active Directory-replikering. Hvis kilde- og destinationsserveren for databasekopien kommunikerer med forskellige domænecontrollere, kan der opstå en timing-fejl. Kilde-serveren opretter konfigurationen i AD, men destinationsserveren læser fra sin lokale domænecontroller, som endnu ikke har modtaget opdateringen. Derfor tror destinationsserveren, at databasen ikke er konfigureret til replikering.

Workaround: Den kontrollerede metode

Selvom fejlen ofte løser sig selv, når AD-replikeringen indhenter det forsømte, kan man undgå den og få mere kontrol over processen ved at bruge ConfigurationOnly-parameteren.

1. Trin 1: Tilføj kun konfigurationen: Denne kommando opretter databasekopi-objektet i Active Directory uden at starte selve seeding-processen. Dette giver AD tid til at replikere ændringen. Add-MailboxDatabaseCopy DB01 -MailboxServer Contoso-E16B -ConfigurationOnly
2. Trin 2: Suspender den nye kopi: For at forberede en manuel seed, suspenderes den netop oprettede kopi. Suspend-MailboxDatabaseCopy -Identity DB01\Contoso-E16B
3. Trin 3: Start manuel seeding: Nu kan du sikkert starte seeding-processen, da AD-konfigurationen er på plads på tværs af domænecontrollerne. Update-MailboxDatabaseCopy -Identity DB01\Contoso-E16B

For at tjekke, hvilken domænecontroller en Exchange-server bruger, kan du køre: Get-ExchangeServer -Status -Identity $env:COMPUTERNAME | Format-Table CurrentDomainController.

Sammenligning af Seeding-metoder

Her er en hurtig sammenligning af de to primære tilgange til at opdatere en databasekopi.

Ofte Stillede Spørgsmål (OSS)

Hvad betyder "Dirty Shutdown" for en Exchange-database?

En "Dirty Shutdown" tilstand betyder, at databasen ikke blev lukket korrekt. Der er transaktioner i logfilerne, som endnu ikke er skrevet til databasefilen (.edb). En database i denne tilstand kan ikke monteres, før en "soft recovery" proces har kørt og committet disse logs. I en sund DAG-failover-situation sker dette automatisk, men hvis processen fejler, kan det indikere dybere problemer.

Kan jeg ignorere "The seeding operation failed"-fejlen?

Ja, ifølge Microsoft kan selve fejlmeddelelsen ofte ignoreres, da klyngen typisk vil forsøge igen og lykkes, når Active Directory-replikeringen er fuldført. Dog giver den beskrevne workaround med `-ConfigurationOnly` dig mulighed for at undgå fejlen og have en mere forudsigelig og kontrolleret proces.

Hvorfor er DNS så vigtigt for DAG failover?

Klientapplikationer som Outlook bruger DNS til at finde Exchange-serveren. I et DAG-miljø peger klienten typisk på et navn, der er associeret med DAG'ens Client Access-array eller selve servernavnene. Hvis DNS ikke er konfigureret til at inkludere IP-adressen på den sekundære server, vil klienterne ikke kunne finde den nye aktive server efter et failover, selvom databaserne er monteret og klar.

Skal jeg altid bruge `-DeleteExistingFiles`?

Når en kopi har status "Failed", er det den sikreste fremgangsmåde at bruge `-DeleteExistingFiles`. Dette sikrer, at du starter med et rent lærred og ikke risikerer, at rester af gamle eller korrupte filer på destinationsserveren skaber nye problemer. Det garanterer, at den nye kopi er en nøjagtig klon af kildedatabasen.