Řešení problémů: Možná ztráta dat u replik skupiny dostupnosti s asynchronním potvrzováním

platí pro:SQL Server

Po nuceném manuálním failoveru na skupině dostupnosti na sekundární repliku s asynchronním commitem můžete zjistit, že ztráta dat je větší než cíl vašeho bodu obnovy (RPO). Nebo když spočítáte potenciální ztrátu dat sekundární repliky s asynchronním commitem pomocí metody v Monitor Performance for Always On Availability Groups, zjistíte, že překračuje vaše RPO.

Sekundární replika se synchronním potvrzováním zaručuje nulovou ztrátu dat, ale potenciální ztráta dat u sekundární repliky s asynchronním potvrzováním závisí na tom, kolik záznamů protokolu na sekundární replice ještě čeká na zápis na disk.

Následující sekce popisují běžné příčiny vysoké potenciální ztráty dat sekundární repliky s asynchronním commitem, za předpokladu, že nemáte systémový problém s výkonem ve vaší serverové instanci, který by nesouvisel s dostupnostními skupinami.

  1. Vysoká latence sítě nebo nízká propustnost sítě způsobují hromadění logů na primární replice

  2. Diskové I/O úzké hrdlo zpomaluje ztvrdnutí logu na sekundární replikě

Vysoká latence sítě nebo nízká propustnost sítě způsobují hromadění logů na primární replice

Nejčastějším důvodem, proč databáze překračují svůj RPO, je to, že je nelze poslat do sekundární repliky dostatečně rychle.

Explanation

Primární replika aktivuje řízení toku při odesílání logu, když překročí maximální povolený počet nepotvrzených zpráv zaslaných sekundární replice. Dokud některé z těchto zpráv nebudou potvrzeny, nelze do sekundární repliky odesílat žádné další logovací bloky. Protože ztrátě dat lze zabránit pouze tehdy, když jsou zpevněna na sekundární replice, hromadění neodeslaných log zpráv zvyšuje potenciální ztrátu dat.

Diagnóza a vyřešení

Vysoký počet zpráv znovu odeslaných sekundární replikě může naznačovat vysokou latenci sítě a síťový šum. Můžete také porovnat hodnotu log_send_rate DMV s výkonnostním objektem Log Bytes Flushed/sec. Pokud jsou logy na disk přenášeny rychleji, než jsou odesílány, potenciální ztráta dat se může zvyšovat neomezeně.

Je také užitečné zkontrolovat dva výkonnostní objekty SQL Server:Availability Replica > Flow Control Time (ms/sec) a SQL Server:Availability Replica > Flow Control/sec. Vynásobením těchto dvou hodnot vám v poslední chvíli ukáže, kolik času jste strávili čekáním na vyčištění průtoku. Čím delší doba čekání na řízení průtoku, tím nižší je rychlost odesílání.

Následující metriky jsou užitečné při diagnostice latence a propustnosti sítě. Můžete použít i jiné Windows nástroje, jako jsouping.exe a Network Monitor, k vyhodnocení latence a využití sítě.

  • DMV sys.dm_hadr_database_replica_states, log_send_queue_size

  • DMV sys.dm_hadr_database_replica_states, log_send_rate

  • Čítač výkonu SQL Server:Database > Log Bytes Flushed/sec

  • Čítač výkonu SQL Server:Database Mirroring > Send/Receive Ack Time

  • Čítač výkonu SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Čítač výkonu SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Čítač výkonu SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Čítač výkonu SQL Server:Availability Replica > Flow Control/sec

  • Čítač výkonu SQL Server:Availability Replica > Resent Messages/sec

K vyřešení tohoto problému zkuste zvýšit šířku pásma sítě nebo odstranit či snížit zbytečný síťový provoz.

Diskové I/O úzké hrdlo zpomaluje ztvrdnutí logu na sekundární replikě

V závislosti na způsobu umístění databázových souborů se může potvrzování transakčního logu zpomalit kvůli kolizím v I/O s reportovací zátěží.

Explanation

Ztrátě dat je zabráněno, jakmile je blok protokolu trvale zapsán do souboru protokolu. Proto je zásadní izolovat logovací soubor od datového souboru. Pokud jsou log soubor i datový soubor namapovány na stejný pevný disk, hlášení náročnosti s intenzivními čteními datového souboru spotřebuje stejné I/O zdroje potřebné pro operaci log hardening. Pomalé ztvrdnutí logu může znamenat pomalé potvrzení primární repliky, což může způsobit nadměrnou aktivaci řízení průtoku a dlouhé čekací doby při řízení průtoku.

Diagnóza a vyřešení

Pokud jste ověřili, že síť netrpí vysokou latencí nebo nízkou propustností, měli byste prozkoumat sekundární repliku pro I/O spory. Dotazy ze SQL Server: Minimize Disk I/O jsou užitečné pro identifikaci sporů. Příklady z tohoto článku jsou uvedeny níže pro vaše pohodlí.

Následující skript vám umožní vidět počet přečtených a zápisů na každém datovém a logovacím souboru pro každou dostupnou databázi běžící na instanci SQL Server. Je to seřazeno podle průměrné doby zastoje I/O, v milisekundách. Všimněte si, že čísla se sčítají od posledního spuštění instance serveru. Proto byste měli rozdíl mezi dvěma měřeními změřit až po uplynutí určité doby.

SELECT DB_NAME(database_id) AS   
   [Database Name] ,   
   file_id ,   
   io_stall_read_ms ,   
   num_of_reads ,   
   CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,   
   io_stall_write_ms ,   
   num_of_writes ,  
   CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,   
   io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,   
   num_of_reads + num_of_writes AS [total_io] ,   
   CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads  
+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]  
FROM sys.dm_io_virtual_file_stats(NULL, NULL)  
WHERE DB_NAME(database_id) IN (SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)  
ORDER BY avg_io_stall_ms DESC;

Tento další dotaz poskytuje momentální (nikoli kumulativní) snímek požadavků na vstup/výstup čekajících na vašem systému.

SELECT DB_NAME(mf.database_id) AS [Database] ,   
   mf.physical_name ,  
   r.io_pending ,   
   r.io_pending_ms_ticks ,   
   r.io_type ,   
   fs.num_of_reads ,   
   fs.num_of_writes  
FROM sys.dm_io_pending_io_requests AS r   
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle   
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id  
AND fs.file_id = mf.file_id  
ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;

Můžete porovnat, jak si navzájem odpovídají operace čtení a zápisu, a identifikovat tak kolize vstupně-výstupních operací.

Následují další ukazatele výkonu, které vám mohou pomoci při diagnostice úzkých míst I/O:

  • Fyzický disk: všechny čítače

  • Fyzický disk: průměrná sekce disku/přenos

  • SQL Server: Databáze > Doba čekání na vyprázdnění protokolu

  • SQL Server: Databáze > Počet čekání na vyprázdnění protokolu za sekundu

  • SQL Server: Databáze > Počet čtení z disku ve fondu protokolu za sekundu

Pokud zjistíte úzké místo vstupu/výstupu (I/O) a máte protokolový soubor i datový soubor umístěné na stejném pevném disku, první věc, kterou byste měli udělat, je umístit datový soubor a protokolový soubor na samostatné disky. Tato osvědčená praxe zabraňuje tomu, aby reportovací zátěž zasahovala do cesty přenosu logů z primární repliky do log bufferu a její schopnosti zpevnit transakci na sekundární replice.

Související obsah

  • Poslední aktualizace v