Hvis du implementerer SQL Server-tilgængelighedsgrupper, er et af de vigtige aspekter af en vellykket implementering at overvåge synkroniseringen af de sekundære replikadatabaser med den primære replika. Der er flere måder at overvåge replikasynkronisering i en tilgængelighedsgruppe, og dette indlæg vil vise hver af dem og forklare deres fordele og ulemper,
En af de nemmeste måder at overvåge status for en tilgængelighedsgruppe, hver af replikaserverne og tilgængelighedsdatabasene er gennem det indbyggede dashboard i Management Studio. Standardlayoutet af dashboardet giver dog ikke mange detaljer og skal tilpasses for at vise yderligere oplysninger om replika-serverne samt tilgængelighedsdatabaserne. Yderligere kolonner kan føjes til layoutet via linket Tilføj/fjern kolonner på dashboardet eller gennem højrekliks kontekstmenuen på en af de eksisterende kolonneoverskrifter, som vist nedenfor:
Tilpasning af AG Dashboard i SSMS
For tilgængelighedsdatabaserne vil overvågning af logafsendelseskøstørrelsen (KB), logafsendelseshastighed (KB/sek), estimeret datatab (tid), estimeret gendannelsestid (sekunder) og synkroniseringsydelse (sekunder) give dig en bedre forståelse af, hvordan data flyder til replikaerne og tilgængelighedsdatabasernes overordnede tilstand. For eksempel har jeg i skærmbilledet nedenfor ændret VM-netværkskonfigurationen for SQL03, så den har højere latenstid og lavere gennemløb, hvilket påvirker synkroniseringen af databaserne:
Her kan vi se, at der er næsten seks minutters potentielt datatab for SQL03, og 505 MB usendt log, der sendes med en hastighed på 7 MB/sek. til den sekundære (som i dette tilfælde er en asynkron sekundær) . Hvorimod SQL02 i øjeblikket er fanget og ikke har noget datatab som en synkron sekundær i konfigurationen.
Et alternativ til Availability Group Dashboard er direkte forespørgsel til DMV'erne, som er der, hvor dashboardet henter sine oplysninger som kilde. Følgende forespørgsel viser den aktuelle status og synkroniseringsmetrics for hver database i en tilgængelighedsgruppe:
SELECT ar.replica_server_name, adc.database_name, ag.name AS ag_name, drs.is_local, drs.is_primary_replica, drs.synchronization_state_desc, drs.is_commit_participant, drs.synchronization_health_desc, drs.recovery_lsn, drs.truncation_lsn, drs.last_sent_lsn, drs.last_sent_time, drs.last_received_lsn, drs.last_received_time, drs.last_hardened_lsn, drs.last_hardened_time, drs.last_redone_lsn, drs.last_redone_time, drs.log_send_queue_size, drs.log_send_rate, drs.redo_queue_size, drs.redo_rate, drs.filestream_send_rate, drs.end_of_log_lsn, drs.last_commit_lsn, drs.last_commit_time FROM sys.dm_hadr_database_replica_states AS drs INNER JOIN sys.availability_databases_cluster AS adc ON drs.group_id = adc.group_id AND drs.group_database_id = adc.group_database_id INNER JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id INNER JOIN sys.availability_replicas AS ar ON drs.group_id = ar.group_id AND drs.replica_id = ar.replica_id ORDER BY ag.name, ar.replica_server_name, adc.database_name;
Ved at forespørge DMV'erne direkte på den primære replika er det nemt at få opdateret information uden at vente på opdateringsperioden for dashboardet i Management Studio. Dette har været nyttigt et par gange, mens du konsulterede klienter, der havde en forbindelsesfejl mellem datacentre, eller hvor forbindelsen var nede på grund af vedligeholdelse i et stykke tid, og de sekundære replikaer er i gang med at indhente det, når forbindelsen blev genoprettet .
Det sidste indbyggede værktøj til overvågning af tilgængelighedsgruppesynkronisering er Performance Monitor, ved hjælp af SQLServer:Database Replica performance-objektet. Tabellen nedenfor viser de relevante ydeevnetællere og deres beskrivelser fra Books Online (https://msdn.microsoft.com/en-us/library/ff878356(v=sql.110).aspx):
| Tællernavn | Beskrivelse |
|---|---|
| Filbytes modtaget/sek. | Mængde FILESTREAM-data modtaget af den sekundære replika for den sekundære database i sidste sekund. |
| Logbytes modtaget/sek. | Mængde af logposter modtaget af den sekundære replika for databasen i det sidste sekund. |
| Resterende log til fortrydelse | Mængden af log-in kilobytes, der er tilbage for at fuldføre fortrydelsesfasen. |
| Logafsendelseskø | Mængde af logposter i logfilerne i den primære database, i kilobytes, som endnu ikke er blevet sendt til den sekundære replika. Denne værdi sendes til den sekundære replika fra den primære replika. Køstørrelse inkluderer ikke FILESTREAM-filer, der sendes til en sekundær. |
| Gendannelseskø | Mængde af logposter i logfilerne for den sekundære replika, der endnu ikke er blevet lavet om. |
| Gentag blokeret/sek. | Antal gange gentag tråden er blokeret på låse, der opbevares af læsere af databasen. |
| Gentag resterende bytes | Mængden af log-in kilobytes, der skal laves om for at afslutte tilbageføringsfasen. |
| Gendannet bytes/sek. | Mængde af logposter, der er lavet om på den sekundære database i det sidste sekund. |
| Samlet log kræver fortryd | Samlet kilobyte af log, der skal fortrydes. |
En af udfordringerne og begrænsningerne ved at bruge Performance Monitor til at overvåge miljøet er, at objektet kun er gyldigt på den forekomst af SQL Server, der er vært for en sekundær replika. Det betyder, at du skal tilføje tællerne fra hver sekundær replika til Performance Monitor for at få et fuldt overblik over, hvad der sker med alle de sekundære databaser, hvor både AG Dashboard i Management Studio og DMV-forespørgslen mod den primære replika giver oplysninger om alle de sekundære databaser på et enkelt sted.
Som et alternativ til de indbyggede funktioner til overvågning af tilgængelighedsgruppesynkronisering kan du også bruge tredjepartsværktøjer som SQL Sentry Performance Advisor, som inkluderer overvågning af tilgængelighedsgrupper som en standardfunktion. Du kan læse mere om denne funktion i dette blogindlæg fra Greg Gonzalez, der først introducerede funktionen i version 7.5 af produktet.
Performacnce Advisor AG Dashboard
Replika-fanen i Performance Advisor gør det muligt at udvide hver af de sekundære replika-servere for nemt at vise databaserne og deres aktuelle synkroniseringsdata. WSFC Node/Group Matrix-standardlayoutet øverst på dashboardet giver også helbredsoplysninger om den primære replikas sendekøstatus, den sekundære replikas genoptagekøstatus og datastrømmen mellem hver af replikaserverne. I dette eksempel kan vi se, at logafsendelseskøen på den primære i øjeblikket sender en stor mængde data fra SQL01 til SQL03, baseret på bredden af linjen mellem serverne, efter at forbindelsesproblemerne mellem SQL01 og SQL03 blev rettet i miljøet. Diagrammet til højre viser den hastighed, hvormed data overføres fra SQL01, sammen med den aktuelle størrelse af logafsendelseskøen, da det er den replika, der er valgt i venstre side. Hvis du klikker på en af de andre replika-servere i WSFC Node/Group Matrix-layoutet, ændres diagrammet også, så det matcher den specifikke replikas ydeevnemålinger i højre side.
Der er mange måder at overvåge ydeevnen af datasynkronisering mellem replika-servere i en tilgængelighedsgruppe i SQL Server. Det indbyggede Availability Group Dashboard i Management Studio indeholder et væld af information, som er nem at få adgang til, når du først ved, hvordan du tilpasser layoutet til at vise de vigtigste oplysninger på dashboardet. Det er også muligt at bruge DMV'erne direkte fra den primære replikaserver til at overvåge ydeevnen af datasynkronisering ved hjælp af Transact-SQL, og tredjepartsværktøjer som SQL Sentry inkluderer også overvågning af datasynkroniseringen. Selvom Performance Monitor kan give den samme information, gør det faktum, at ydeevnetællerne kun er tilgængelige fra den sekundære replika-server, det lidt mere arbejde at få et fuldt overblik over hele miljøet.