Kvifor eit raskt VPN framleis gjer ei synkron SQL-bekrefting treg

Opne ein spørjesesjon på primæren og sjå kva ei enkel skriving ventar på. Viss databasen høyrer til ei tilgjengelegheitsgruppe med synkron bekrefting og den sekundære er tilkopla, forlèt ein del av den ventetida bygningen: loggpostar reiser til replikaen, blir herda der, og meldinga om herdinga kjem tilbake før bekreftinga er ferdig. Bandbreidd forkortar ikkje den reisa fram og tilbake. Gjennomgangen nedanfor følgjer bekreftinga frå skjermen til den eksterne disken og tilbake.

Byrja ved ventetypen på primæren

Ei skriving som ventar på den eksterne replikaen, viser seg som ei loggrelatert ventetid i staden for ei CPU- eller låseventetid, og varigheita på transaksjonen følgjer reisa fram og tilbake i staden for talet på radene. Mange små bekreftingar gjer det tydeleg, fordi kvar einskild betaler reisa separat. Éin einaste masseoperasjon gøymer den same kostnaden i éi lengre bekrefting.

Sorter arbeidsmengda etter bekreftingsfrekvens før du konkluderer noko om sambandet.

Les tilstanden til replikaen før du les nettverket. Teljarane som betyr noko, er sendekøen, redo-køen og synkroniseringstilstanden, og saman viser dei om den sekundære held følgje eller sakkar akterut. Ein veksande sendekø peikar på transporten, medan ein veksande redo-kø peikar på den sekundære sitt eige arbeid eller lagring. Det er ulike reparasjonar, og ingen av dei blir betre av å leggje til bandbreidd.

Følg bekreftinga til den sekundære

Ved synkron bekrefting ventar primæren på bekrefting av at den aktuelle loggen er herda på den sekundære, før han melder bekreftinga som fullført. Herda betyr varig i loggen, ikkje spela av i datasider. Nettopp den skilnaden forklarer kvifor ein synkron sekundær kan liggje etter i redo medan han framleis bekreftar herding.

Gå vegen i rekkjefølgje og mål kvart trinn i staden for heilskapen. Loggpostar går over transporten, den sekundære skriv og spylar dei, og bekreftinga kjem tilbake same vegen. Transportforsinking, planlegging på den sekundære og loggdisklatensen til den sekundære hamnar alle i totalen, og berre den første høyrer til nettverkseigaren. Ein sekundær der loggvolumet er metta av noko anna, kan strekkje kvar bekrefting medan sambandet står ledig.

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 det augneblinksbiletet før og etter ei representativ skriving i staden for éin gong ein stille ettermiddag. Skilnaden er det som fortel deg kva kø som flytta seg medan bekreftinga venta.

Mål vegen, ikkje sambandet

Ein gjennomstrøymingstest måler kapasitet mellom to punkt som ikkje er replikaene dine, under ei belasting som ikkje er arbeidsmengda di. Be nettverkseigaren om forseinking og tap langs den verkelege replikavegen medan verkeleg trafikk går, i begge retningar. Tap tyder meir enn kapasitet her, fordi eit tapt segment kostar ein retransmisjon, og kvar bekrefting ventar på éi bekrefting. Eit samband som ser framifrå ut i ein nedlastingstest, kan framleis passe dårleg til eit snakkesalig bekreftingsmønster.

Hald transportsikkerheita til databasen og tilgangskontrollane intakte medan du måler. Å måle ein veg er aldri ein grunn til å omgå dei.

Korreler tidene med teljarane i staden for med intuisjon. Viss sendekøen blir ståande tom og bekreftinga framleis ventar, ligg forseinkinga i bekreftinga eller i spylinga til den sekundære. Viss sendekøen veks jamt, er transporten eller kapasiteten avgrensinga. Noter kva observasjon som støtta konklusjonen, slik at neste person kan gjenta målinga i staden for diskusjonen.

Kva asynkron modus verkeleg endrar

Asynkron bekrefting fjernar ventinga på herdingsbekreftinga til den sekundære, og det er derfor skrivingar blir raskare, og derfor endrar haldbarheitsposisjonen din seg. Primæren bekreftar transaksjonen utan den eksterne bekreftinga. Den sekundære får då løyve til å sakke akterut, og den forseinkinga er eksponeringa.

Viss primæren går tapt før loggen når eit brukbart failover-mål, kastar ei tvungen flytting av tenesta til den replikaen transaksjonar som applikasjonen allereie er blitt fortald var bekrefta.

Det er ei avgjerd om gjenopprettingspunkt, og ho høyrer til databaseeigaren, ikkje ein ytingsgjennomgang. Fastset først det tolererte datatapsvindauget, vel modusen som oppfyller det, og optimaliser deretter innanfor den grensa. Alternativ som held på synkron vern, omfattar å fjerne unødvendige bekreftingsreiser der applikasjonen tillèt det, å rette ein målt flaskehals i transport eller lagring, og å flytte replikaen slik at bekreftinga reiser kortare. Veg dei mot haldbarheitskravet du byrja med, som ikkje har endra seg.