Hvorfor et raskt VPN fortsatt gjør en synkron SQL-bekreftelse treg

Åpne en spørringssesjon på primæren og se hva en enkel skriving venter på. Hvis databasen tilhører en tilgjengelighetsgruppe med synkron bekreftelse og den sekundære er tilkoblet, forlater en del av den ventingen bygningen: loggposter reiser til replikaen, herdes der, og meldingen om herdingen kommer tilbake før bekreftelsen er ferdig. Båndbredde forkorter ikke den reisen frem og tilbake. Gjennomgangen nedenfor følger bekreftelsen fra skjermen til den eksterne disken og tilbake.

Begynn ved ventetypen på primæren

En skriving som venter på den eksterne replikaen vises som en loggrelatert ventetid i stedet for en CPU- eller låseventetid, og transaksjonens varighet følger reisen frem og tilbake i stedet for antall rader. Mange små bekreftelser gjør det tydelig, fordi hver enkelt betaler reisen separat. Én enkelt masseoperasjon skjuler den samme kostnaden i én lengre bekreftelse.

Sorter arbeidsmengden etter bekreftelsesfrekvens før du konkluderer noe om forbindelsen.

Les replikaens tilstand før du leser nettverket. Tellerne som betyr noe, er sendekøen, redo-køen og synkroniseringstilstanden, og sammen viser de om den sekundære holder følge eller sakker akterut. En voksende sendekø peker på transporten, mens en voksende redo-kø peker på den sekundæres eget arbeid eller lagring. Det er forskjellige reparasjoner, og ingen av dem blir bedre av å legge til båndbredde.

Følg bekreftelsen til den sekundære

Ved synkron bekreftelse venter primæren på bekreftelse av at den aktuelle loggen er herdet på den sekundære, før den melder bekreftelsen som fullført. Herdet betyr varig i loggen, ikke spilt av i datasider. Nettopp den forskjellen forklarer hvorfor en synkron sekundær kan ligge etter i redo mens den fortsatt bekrefter herding.

Gå veien i rekkefølge og mål hvert trinn i stedet for helheten. Loggposter går over transporten, den sekundære skriver og spyler dem, og bekreftelsen kommer tilbake samme vei. Transportforsinkelse, planlegging på den sekundære og den sekundæres loggdisk-latens ender alle i totalen, og bare den første tilhører nettverkseieren. En sekundær der loggvolumet er mettet av noe annet, kan strekke hver bekreftelse mens forbindelsen 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 øyeblikksbildet før og etter en representativ skriving i stedet for én gang en stille ettermiddag. Forskjellen er det som forteller deg hvilken kø som flyttet seg mens bekreftelsen ventet.

Mål veien, ikke forbindelsen

En gjennomstrømningstest måler kapasitet mellom to punkter som ikke er replikaene dine, under en belastning som ikke er arbeidsmengden din. Be nettverkseieren om forsinkelse og tap langs den virkelige replikaveien mens virkelig trafikk går, i begge retninger. Tap betyr mer enn kapasitet her, fordi et tapt segment koster en retransmisjon, og hver bekreftelse venter på én bekreftelse. En forbindelse som ser fremragende ut i en nedlastingstest, kan fortsatt passe dårlig til et snakkesalig bekreftelsesmønster.

Hold databasens transportsikkerhet og tilgangskontroller intakte mens du måler. Å måle en vei er aldri en grunn til å omgå dem.

Korreler tidene med tellerne i stedet for med intuisjon. Hvis sendekøen blir stående tom og bekreftelsen fortsatt venter, ligger forsinkelsen i bekreftelsen eller i den sekundæres spyling. Hvis sendekøen vokser jevnt, er transporten eller kapasiteten begrensningen. Noter hvilken observasjon som støttet konklusjonen, slik at neste person kan gjenta målingen i stedet for diskusjonen.

Hva asynkron modus faktisk endrer

Asynkron bekreftelse fjerner ventingen på den sekundæres herdingsbekreftelse, og det er derfor skrivinger blir raskere, og derfor endres holdbarhetsposisjonen din. Primæren bekrefter transaksjonen uten den eksterne bekreftelsen. Den sekundære får da lov til å sakke akterut, og den forsinkelsen er eksponeringen.

Hvis primæren går tapt før loggen når et brukbart failover-mål, kaster en tvungen flytting av tjenesten til den replikaen transaksjoner som applikasjonen allerede er blitt fortalt var bekreftet.

Det er en beslutning om gjenopprettingspunkt, og den tilhører databaseeieren, ikke en ytelsesgjennomgang. Fastsett først det tolererte datatapsvinduet, velg modusen som oppfyller det, og optimaliser deretter innenfor den grensen. Alternativer som beholder synkron beskyttelse, omfatter å fjerne unødvendige bekreftelsesreiser der applikasjonen tillater det, å rette en målt flaskehals i transport eller lagring, og å flytte replikaen slik at bekreftelsen reiser kortere. Vei dem mot holdbarhetskravet du startet med, som ikke har endret seg.