Varför ett snabbt VPN ändå gör en synkron SQL-bekräftelse långsam

Öppna en frågesession på primären och se vad en enkel skrivning väntar på. Om databasen tillhör en tillgänglighetsgrupp med synkron bekräftelse och den sekundära är ansluten, lämnar en del av den väntan byggnaden: loggposter reser till repliken, härdas där, och meddelandet om härdningen kommer tillbaka innan bekräftelsen är klar. Bandbredd förkortar inte den resan fram och tillbaka. Genomgången nedan följer bekräftelsen från skärmen till den externa disken och tillbaka.

Börja vid väntetypen på primären

En skrivning som väntar på den externa repliken visas som en loggrelaterad väntetid i stället för en CPU- eller låsväntetid, och transaktionens varaktighet följer resan fram och tillbaka i stället för antalet rader. Många små bekräftelser gör det tydligt, eftersom var och en betalar resan separat. En enda massoperation döljer samma kostnad i en längre bekräftelse.

Sortera arbetsbelastningen efter bekräftelsefrekvens innan du drar någon slutsats om förbindelsen.

Läs replikens tillstånd innan du läser nätverket. Räknarna som betyder något är sändningskön, redo-kön och synkroniseringstillståndet, och tillsammans visar de om den sekundära håller jämna steg eller hamnar efter. En växande sändningskö pekar på transporten, medan en växande redo-kö pekar på den sekundäras eget arbete eller lagring. Det är olika reparationer, och ingen av dem blir bättre av att lägga till bandbredd.

Följ bekräftelsen till den sekundära

Vid synkron bekräftelse väntar primären på bekräftelse av att den aktuella loggen har härdats på den sekundära innan den rapporterar bekräftelsen som klar. Härdad betyder varaktig i loggen, inte uppspelad i datasidor. Just den skillnaden förklarar varför en synkron sekundär kan ligga efter i redo medan den fortfarande bekräftar härdningen.

Gå vägen i ordning och mät varje steg i stället för helheten. Loggposter går över transporten, den sekundära skriver och spolar dem, och bekräftelsen kommer tillbaka samma väg. Transportfördröjning, schemaläggning på den sekundära och den sekundäras loggdisk-latens hamnar alla i summan, och bara den första tillhör nätverksägaren. En sekundär vars loggvolym är mättad av något annat kan dra ut varje bekräftelse medan förbindelsen står oanvänd.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Ta den ögonblicksbilden före och efter en representativ skrivning i stället för en gång en stilla eftermiddag. Skillnaden är det som säger vilken kö som flyttade sig medan bekräftelsen väntade.

Mät vägen, inte förbindelsen

Ett genomströmningstest mäter kapacitet mellan två punkter som inte är dina repliker, under en belastning som inte är din arbetsbelastning. Be nätverksägaren om fördröjning och förlust längs den verkliga replikvägen medan verklig trafik går, i båda riktningarna. Förlust väger tyngre än kapacitet här, eftersom ett tappat segment kostar en omsändning och varje bekräftelse väntar på en bekräftelse. En förbindelse som ser utmärkt ut i ett nedladdningstest kan fortfarande passa dåligt för ett pratsamt bekräftelsemönster.

Håll databasens transportsäkerhet och åtkomstkontroller intakta medan du mäter. Att mäta en väg är aldrig en anledning att kringgå dem.

Korrelera tiderna med räknarna i stället för med intuition. Om sändningskön förblir tom och bekräftelsen fortfarande väntar, ligger fördröjningen i bekräftelsen eller i den sekundäras spolning. Om sändningskön växer jämnt är transporten eller kapaciteten begränsningen. Anteckna vilken observation som stödde slutsatsen, så att nästa person kan upprepa mätningen i stället för diskussionen.

Vad asynkront läge faktiskt ändrar

Asynkron bekräftelse tar bort väntan på den sekundäras härdningsbekräftelse, och det är därför skrivningar blir snabbare och varför din hållbarhetsposition ändras. Primären bekräftar transaktionen utan den externa bekräftelsen. Den sekundära tillåts då hamna efter, och den eftersläpningen är exponeringen.

Om primären förloras innan loggen når ett användbart mål för växling, kastar ett påtvingat flytt av tjänsten till den repliken transaktioner som applikationen redan hade fått besked om var bekräftade.

Det är ett beslut om återställningspunkt och det tillhör databasägaren, inte en prestandagranskning. Fastställ först fönstret för tolererad dataförlust, välj det läge som uppfyller det och optimera sedan inom den gränsen. Alternativ som behåller synkront skydd inkluderar att ta bort onödiga bekräftelseresor där applikationen tillåter det, att åtgärda en uppmätt flaskhals i transport eller lagring, och att flytta repliken så att bekräftelsen färdas kortare. Väg dem mot hållbarhetskravet du började med, som inte har ändrats.