Pokud nasazujete SQL Server Availability Groups, je jedním z důležitých aspektů úspěšného nasazení monitorování synchronizace sekundárních replikových databází s primární replikou. Existuje několik způsobů, jak monitorovat synchronizaci replik ve skupině dostupnosti, a tento příspěvek ukáže každý z nich a vysvětlí jejich výhody a nevýhody,
Jedním z nejjednodušších způsobů monitorování stavu skupiny dostupnosti, každého z replikovaných serverů a databází dostupnosti je vestavěný řídicí panel v Management Studio. Výchozí rozložení řídicího panelu však neposkytuje mnoho podrobností a bude nutné jej upravit, aby zobrazovalo další informace o replikovaných serverech a také o databázích dostupnosti. Další sloupce lze do rozvržení přidat pomocí odkazu Přidat/odebrat sloupce na řídicím panelu nebo pomocí kontextové nabídky po kliknutí pravým tlačítkem myši na libovolné ze stávajících záhlaví sloupců, jak je znázorněno níže:
Přizpůsobení řídicího panelu AG v SSMS
U databází dostupnosti vám lépe porozumí sledování velikosti fronty odesílání protokolů (KB), rychlosti odesílání protokolů (KB/s), odhadované ztráty dat (čas), odhadované doby obnovy (sekundy) a výkonu synchronizace (sekundy). o tom, jak data proudí do replik a o celkovém stavu databází dostupnosti. Například na níže uvedeném snímku obrazovky jsem upravil konfiguraci sítě VM pro SQL03 tak, aby měla vyšší latenci a nižší propustnost, což ovlivňuje synchronizaci databází:
Zde můžeme vidět, že existuje téměř šest minut potenciální ztráty dat pro SQL03 a 505 MB neodeslaného protokolu, který je odesílán rychlostí 7 MB/s na sekundární server (což je v tomto případě asynchronní sekundární) . Zatímco SQL02 je aktuálně zachycen a nedochází ke ztrátě dat jako synchronní sekundární v konfiguraci.
Alternativou k řídicímu panelu skupiny dostupnosti je přímé dotazování na DMV, což je místo, odkud řídicí panel získává informace jako zdroj. Následující dotaz zobrazuje aktuální stav a metriky synchronizace pro každou databázi ve skupině dostupnosti:
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;
Dotazováním na DMV přímo na primární replice je snadné získat aktuální informace, aniž byste museli čekat na dobu aktualizace řídicího panelu v Management Studio. To bylo několikrát užitečné při konzultacích s klienty, kteří měli poruchu spojení mezi datovými centry nebo kde bylo připojení po určitou dobu mimo provoz z důvodu údržby a sekundární repliky jsou v procesu dohánění, jakmile bylo připojení obnoveno. .
Posledním nativním nástrojem pro monitorování synchronizace skupiny dostupnosti je Performance Monitor s použitím objektu výkonu SQLServer:Database Replica. Níže uvedená tabulka ukazuje příslušné čítače výkonu a jejich popisy z Books Online (https://msdn.microsoft.com/en-us/library/ff878356(v=sql.110).aspx):
| Název počítadla | Popis |
|---|---|
| Přijaté bajty souboru/s | Množství dat FILESTREAM přijatých sekundární replikou pro sekundární databázi za poslední sekundu. |
| Přijaté bajty protokolu/s | Množství záznamů protokolu přijatých sekundární replikou pro databázi za poslední sekundu. |
| Zbývá přihlásit pro vrácení zpět | Množství kilobajtů přihlášení zbývajících k dokončení fáze vrácení zpět. |
| Fronta odesílání protokolu | Množství záznamů protokolu v souborech protokolu primární databáze v kilobajtech, které ještě nebyly odeslány do sekundární repliky. Tato hodnota je odeslána do sekundární repliky z primární repliky. Velikost fronty nezahrnuje soubory FILESTREAM, které jsou odesílány na sekundární server. |
| Fronta na obnovení | Množství záznamů protokolu v souborech protokolu sekundární repliky, které ještě nebyly přepracovány. |
| Opakovat blokování/s | Počet případů, kdy bylo opakované vlákno zablokováno na zámcích držených čtenáři databáze. |
| Opakovat zbývající bajty | Množství kilobajtů přihlášení, které zbývá předělat, aby byla dokončena fáze návratu. |
| Opakované bajty/s | Počet záznamů protokolu přepracovaných v sekundární databázi za poslední sekundu. |
| Celkový protokol vyžadující vrácení zpět | Celkový počet kilobajtů protokolu, který je třeba vrátit zpět. |
Jedním z problémů a omezení používání nástroje Performance Monitor k monitorování prostředí je, že objekt je platný pouze v instanci serveru SQL Server, který je hostitelem sekundární repliky. To znamená, že musíte přidat čítače z každé sekundární repliky do Performance Monitor a získat úplný přehled o tom, co se děje se všemi sekundárními databázemi, kde jak AG Dashboard v Management Studio, tak dotaz DMV proti primární replice poskytují informace o všech sekundárních databázích na jednom místě.
Jako alternativu k vestavěným funkcím pro sledování synchronizace skupiny dostupnosti můžete také využít nástroje třetích stran, jako je SQL Sentry Performance Advisor, který zahrnuje sledování skupin dostupnosti jako standardní funkci. Více o této funkci si můžete přečíst v tomto příspěvku na blogu od Grega Gonzaleze, který tuto funkci poprvé představil ve verzi 7.5 produktu.
Performacnce Advisor AG Dashboard
Karta Repliky v nástroji Performance Advisor umožňuje rozšíření každého ze sekundárních replikačních serverů tak, aby se snadno zobrazovaly databáze a jejich aktuální synchronizační data. Výchozí rozložení matice uzlu/skupiny WSFC v horní části řídicího panelu také poskytuje zdravotní informace o stavu fronty odesílání primární repliky, stavu fronty opakování sekundární repliky a toku dat mezi jednotlivými servery repliky. V tomto příkladu můžeme vidět, že fronta odesílání protokolu na primárním serveru aktuálně odesílá velké množství dat z SQL01 do SQL03 na základě šířky čáry mezi servery poté, co byly opraveny problémy s konektivitou mezi SQL01 a SQL03 v prostředí. Graf vpravo ukazuje rychlost, jakou jsou data přenášena z SQL01, spolu s aktuální velikostí fronty odesílání protokolu, protože to je replika vybraná na levé straně. Kliknutím na jeden z dalších replikových serverů v rozložení WSFC Node/Group Matrix také změníte graf tak, aby odpovídal metrikám výkonu konkrétní repliky na pravé straně.
Existuje mnoho způsobů, jak monitorovat výkon synchronizace dat mezi replikovanými servery ve skupině dostupnosti v SQL Server. Vestavěný řídicí panel skupiny dostupnosti v Management Studio obsahuje velké množství informací, ke kterým je snadný přístup, jakmile budete vědět, jak upravit rozvržení, aby se na řídicím panelu zobrazovaly nejdůležitější informace. Je také možné použít DMV přímo z primárního replikového serveru ke sledování výkonu synchronizace dat pomocí Transact-SQL a nástroje třetích stran, jako je SQL Sentry, zahrnují také monitorování synchronizace dat. I když Performance Monitor může poskytnout stejné informace, fakt, že čítače výkonu jsou dostupné pouze ze sekundárního replikového serveru, dává trochu větší práci získat úplný přehled o celém prostředí.