Felsökning: Potentiell dataförlust med asynkrona commit-tillgänglighetsgrupprepliker

Gäller för:SQL Server

Efter att du har utfört en tvingad manuell failover för en tillgänglighetsgrupp till en sekundär replik med asynkron commit kan det visa sig att dataförlusten är större än ditt återställningspunktsmål (RPO). Eller, när du beräknar den potentiella dataförlusten för en sekundär replik med asynkron commit med metoden i Monitor Performance for Always On Availability Groups, konstaterar du att den överstiger din RPO.

En sekundär replika med synkron commit garanterar noll dataförlust, men den potentiella dataförlusten för en sekundär replik med asynkron commit beror på hur mycket logg som fortfarande väntar på att härdas på den sekundära repliken.

Följande avsnitt beskriver vanliga orsaker till hög potentiell dataförlust hos en asynkron commit sekundär replika, förutsatt att du inte har ett systemiskt prestandaproblem i din serverinstans som inte är relaterat till tillgänglighetsgrupper.

  1. Hög nätverkslatens eller låg nätverksgenomströmning orsakar logguppbyggnad på primär replik

  2. Disk-I/O-flaskhals bromsar loghärdningen på sekundärkopian

Hög nätverkslatens eller låg nätverksgenomströmning orsakar logguppbyggnad på primär replik

Den vanligaste anledningen till att databaserna överskrider sin RPO är att de inte kan skickas till den sekundära replikan tillräckligt snabbt.

Explanation

Den primära repliken aktiverar flödeskontrollen på loggsändningen när den har överskridit det maximalt tillåtna antalet icke-bekräftade meddelanden som skickas till den sekundära repliken. Tills några av dessa meddelanden har bekräftats kan inga fler loggblock skickas till den sekundära repliken. Eftersom dataförlust bara kan förhindras när loggmeddelandena har skrivits till den sekundära repliken, ökar en växande mängd loggmeddelanden som inte har skickats risken för dataförlust.

Diagnos och lösning

Ett högt antal meddelanden som skickas om till den sekundära repliken kan indikera hög nätverkslatens och nätverksbrus. Du kan också jämföra DMV-värdet log_send_rate med prestandaobjektet Log Bytes Flushed/sec. Om loggar rensas till disken snabbare än de skickas kan den potentiella dataförlusten öka oändligt.

Det är också användbart att kontrollera de två prestandaobjekten SQL Server:Availability Replica > Flow Control Time (ms/sec) och SQL Server:Availability Replica > Flow Control/sec. Att multiplicera dessa två värden visar i sista sekund hur mycket tid som lagts på att vänta på att flödeskontrollen skulle klaras. Ju längre väntetid för flödeskontroll, desto lägre sändningshastighet.

Följande mått är användbara för att diagnostisera nätverkslatens och genomströmning. Du kan använda andra Windows verktyg, såsom ping.exe och Network Monitor, för att utvärdera latens och nätverksanvändning.

  • DMV sys.dm_hadr_database_replica_states, log_send_queue_size

  • DMV sys.dm_hadr_database_replica_states, log_send_rate

  • Prestandaräknare SQL Server:Database > Log Bytes Flushed/sec

  • Prestandaräknare SQL Server:Database Mirroring > Send/Receive Ack Time

  • Prestandaräknare SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Prestandaräknare SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Prestandaräknare SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Prestandaräknare SQL Server:Availability Replica > Flow Control/sec

  • Prestandaräknare SQL Server:Availability Replica > Resent Messages/sec

För att åtgärda detta problem, försök uppgradera din nätverksbandbredd eller ta bort eller minska onödig nätverkstrafik.

Disk-I/O-flaskhals bromsar loghärdningen på sekundärkopian

Beroende på hur databasfilerna är placerade kan härdningen av transaktionsloggen gå långsammare på grund av I/O-konkurrens med rapporteringsbelastningen.

Explanation

Dataförlust förhindras så snart loggblocket härdas på loggfilen. Därför är det avgörande att isolera loggfilen från datafilen. Om loggfilen och datafilen båda mappas till samma hårddisk, kommer rapportering av arbetsbelastning med intensiva läsningar av datafilen att förbruka samma I/O-resurser som logghärdningsoperationen behöver. Långsam härdning av loggen kan leda till långsam bekräftelse till den primära repliken, vilket kan orsaka att flödeskontrollen aktiveras alltför ofta och långa väntetider för flödeskontroll.

Diagnos och lösning

Om du har verifierat att nätverket inte lider av hög latens eller låg genomströmning bör du undersöka sekundärkopian för I/O-konflikter. Frågor från SQL Server: Minimera disk-I/O är användbara för att identifiera invändningar. Exempel från den artikeln finns nedan för din bekvämlighet.

Följande skript låter dig se antalet läsningar och skrivningar på varje data- och loggfil för varje tillgänglighetsdatabas som körs på en instans av SQL Server. Den sorteras efter genomsnittlig I/O-stalltid, i millisekunder. Observera att siffrorna är kumulativa från senaste gången serverinstansen startades. Därför bör du ta skillnaden mellan två mätningar efter en viss tid.

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;

Nästa fråga ger en ögonblicksbild från en viss tidpunkt (inte kumulativ) av I/O-förfrågningar som väntar i ditt system.

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;

Du kan jämföra hur read I/O och write I/O matchar varandra för att identifiera I/O-konflikt.

Här följer några andra prestandaräknare som kan hjälpa dig att identifiera flaskhalsar i I/O:

  • Fysisk disk: alla räknare

  • Fysisk disk: Genomsnittlig disksek/överföring

  • SQL Server: Databaser > Väntetid för tömning av transaktionslogg

  • SQL Server: Databaser > Väntetider för loggtömning/sek

  • SQL Server: Databaser > Log Pool Diskläsningar/sek

Om du identifierar en I/O-flaskhals och har lagt loggfilen och datafilen på samma hårddisk, är det första du bör göra att lägga datafilen och loggfilen på separata diskar. Denna bästa praxis förhindrar att rapporteringsarbetsbelastningen stör loggöverföringsvägen från primärkopian till loggbufferten och dess förmåga att förstärka transaktionen på sekundärkopian.

Relaterat innehåll

  • Last updated on