Waarom een snel VPN een synchrone SQL-bevestiging nog steeds vertraagt

Open een querysessie op de primaire en kijk waar een eenvoudige schrijfactie op wacht. Als de database deel uitmaakt van een beschikbaarheidsgroep met synchrone bevestiging en de secundaire is verbonden, verlaat een deel van die wachttijd het gebouw: logrecords reizen naar de replica, worden daar gehard, en het bericht over die verharding komt terug voordat de bevestiging klaar is. Bandbreedte verkort die reis heen en terug niet. De wandeling hieronder volgt de bevestiging van het scherm naar de externe schijf en weer terug.

Begin bij het wachttype op de primaire

Een schrijfactie die op de externe replica wacht, verschijnt als een loggerelateerde wachttijd in plaats van een CPU- of vergrendelingswachttijd, en de duur van de transactie volgt de reis heen en terug in plaats van het aantal rijen. Veel kleine bevestigingen maken dat duidelijk, omdat elk de reis apart betaalt. Eén bulkbewerking verbergt dezelfde kosten in één langere bevestiging.

Sorteer uw werklast op bevestigingsfrequentie voordat u iets over de verbinding concludeert.

Lees de status van de replica voordat u het netwerk leest. De tellers die ertoe doen, zijn de verzendwachtrij, de redo-wachtrij en de synchronisatiestatus, en samen laten ze zien of de secundaire bijblijft of achterloopt. Een groeiende verzendwachtrij wijst op transport, terwijl een groeiende redo-wachtrij wijst op het eigen werk of de opslag van de secundaire. Dat zijn verschillende reparaties, en geen van beide wordt beter door bandbreedte toe te voegen.

Volg de bevestiging naar de secundaire

Bij synchrone bevestiging wacht de primaire op bevestiging dat het betreffende log op de secundaire is gehard voordat hij de bevestiging als voltooid meldt. Gehard betekent duurzaam in het log, niet opnieuw afgespeeld in datapagina's. Precies dat onderscheid verklaart waarom een synchrone secundaire achter kan lopen in redo terwijl hij de verharding nog bevestigt.

Loop het pad in volgorde en meet elke fase in plaats van het geheel. Logrecords gaan over het transport, de secundaire schrijft en spoelt ze, en de bevestiging keert langs dezelfde weg terug. Transportvertraging, planning van de secundaire en latency van de logschijf van de secundaire belanden allemaal in het totaal, en alleen de eerste is van de netwerkeigenaar. Een secundaire waarvan het logvolume door iets anders verzadigd is, kan elke bevestiging rekken terwijl de verbinding stil staat.

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;

Neem dat momentopname voor en na een representatieve schrijfactie in plaats van één keer op een rustige middag. Het verschil vertelt u welke wachtrij bewoog terwijl de bevestiging wachtte.

Meet het pad, niet de verbinding

Een doorvoertest meet capaciteit tussen twee punten die niet uw replica's zijn, onder een belasting die niet uw werklast is. Vraag de netwerkeigenaar om vertraging en verlies langs het echte replicapad terwijl echt verkeer loopt, in beide richtingen. Verlies weegt hier zwaarder dan capaciteit, omdat een verloren segment een hertransmissie kost en elke bevestiging op één bevestiging wacht. Een verbinding die er in een downloadtest uitstekend uitziet, kan toch slecht passen bij een spraakzaam bevestigingspatroon.

Houd de transportbeveiliging van de database en de toegangscontroles intact terwijl u meet. Een pad meten is nooit een reden om ze te omzeilen.

Correleer de tijden met de tellers in plaats van met intuïtie. Als de verzendwachtrij leeg blijft en de bevestiging nog wacht, zit de vertraging in de bevestiging of in het spoelen van de secundaire. Als de verzendwachtrij gestaag groeit, zijn transport of capaciteit de beperking. Noteer welke observatie de conclusie ondersteunde, zodat de volgende persoon de meting kan herhalen in plaats van de discussie.

Wat asynchrone modus werkelijk verandert

Asynchrone bevestiging verwijdert het wachten op de verhardingsbevestiging van de secundaire, waardoor schrijfacties sneller worden en waardoor uw duurzaamheidspositie verandert. De primaire bevestigt de transactie zonder die externe bevestiging. De secundaire mag dan achterlopen, en die achterstand is de blootstelling.

Als de primaire verloren gaat voordat het log een bruikbaar failover-doel bereikt, gooit het forceren van de dienst naar die replica transacties weg waarvan de applicatie al had gehoord dat ze bevestigd waren.

Dat is een beslissing over het herstelpunt en die hoort bij de database-eigenaar, niet bij een prestatiebeoordeling. Stel eerst het getolereerde gegevensverliesvenster vast, kies de modus die daaraan voldoet en optimaliseer daarna binnen die grens. Opties die de synchrone bescherming behouden, omvatten het verwijderen van vermijdbare bevestigingsreizen waar de applicatie dat toestaat, het verhelpen van een gemeten knelpunt in transport of opslag, en het verplaatsen van de replica zodat de bevestiging minder afstand aflegt. Weeg ze af tegen de duurzaamheidseis waarmee u begon, die niet is veranderd.