Hvorfor et hurtigt VPN stadig gør en synkron SQL-godkendelse langsom

Åbn en forespørgelsessession på den primære og se, hvad en simpel skrivning venter på. Hvis databasen hører til en tilgængelighedsgruppe med synkron godkendelse, og den sekundære er forbundet, forlader en del af ventetiden bygningen: logposter rejser til replikaen, hærdes der, og meddelelsen om den hærdning kommer tilbage, før godkendelsen er færdig. Båndbredde forkorter ikke den rejse frem og tilbage. Gennemgangen nedenfor følger bekræftelsen fra skærmen til den eksterne disk og tilbage igen.

Begynd ved ventetypen på den primære

En skrivning, der venter på den eksterne replika, vises som en logrelateret ventetid i stedet for en CPU- eller låseventetid, og transaktionens varighed følger rejsen frem og tilbage i stedet for rækkeantallet. Mange små godkendelser gør det tydeligt, fordi hver især betaler rejsen separat. En enkelt masseoperation skjuler den samme pris i én længere bekræftelse.

Sortér arbejdsbyrden efter godkendelsesfrekvens, før du konkluderer noget om forbindelsen.

Læs replikaens tilstand, før du læser netværket. De tællere, der betyder noget, er sendekøen, redo-køen og synkroniseringstilstanden, og sammen viser de, om den sekundære følger med eller sakker bagud. En voksende sendekø peger på transport, mens en voksende redo-kø peger på den sekundæres eget arbejde eller lager. Det er forskellige reparationer, og ingen af dem bliver bedre af at tilføje båndbredde.

Følg bekræftelsen til den sekundære

Ved synkron godkendelse venter den primære på bekræftelse af, at den relevante log er hærdet på den sekundære, før den melder godkendelsen som fuldført. Hærdet betyder varig i loggen, ikke afspillet i datasider. Netop den forskel er grunden til, at en synkron sekundær kan være bagud med redo, mens den stadig bekræfter hærdning.

Gå vejen i rækkefølge, og mål hvert trin i stedet for helheden. Logposter går over transporten, den sekundære skriver og flusher dem, og bekræftelsen vender tilbage ad samme vej. Transportforsinkelse, sekundær planlægning og den sekundæres logdisk-latens lander alle i totalen, og kun det første tilhører netværksejeren. En sekundær, hvis logvolumen er mættet af noget andet, kan strække hver godkendelse, 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;

Tag det øjebliksbillede før og efter en repræsentativ skrivning i stedet for én gang en stille eftermiddag. Forskellen er det, der fortæller dig, hvilken kø der flyttede sig, mens godkendelsen ventede.

Mål vejen, ikke forbindelsen

En gennemstrømningstest måler kapacitet mellem to punkter, som ikke er dine replikaer, under en belastning, som ikke er din arbejdsbyrde. Bed netværksejeren om forsinkelse og tab langs den rigtige replikavej, mens der kører rigtig trafik, i begge retninger. Tab betyder mere end kapacitet her, fordi et tabt segment koster en retransmission, og hver godkendelse venter på én bekræftelse. En forbindelse, der ser fremragende ud i en downloadtest, kan stadig være dårligt egnet til et snakkesaligt godkendelsesmønster.

Hold databasens transportsikkerhed og adgangskontroller intakte, mens du måler. At måle en vej er aldrig en grund til at omgå dem.

Korrelér tiderne med tællerne i stedet for med intuition. Hvis sendekøen forbliver tom, og godkendelsen stadig venter, er forsinkelsen i bekræftelsen eller i den sekundæres flush. Hvis sendekøen vokser jævnt, er transporten eller kapaciteten begrænsningen. Notér, hvilken observation der støttede konklusionen, så den næste person kan gentage målingen i stedet for diskussionen.

Hvad asynkron tilstand egentlig ændrer

Asynkron godkendelse fjerner ventetiden på den sekundæres hærdningsbekræftelse, og det er derfor, skrivninger bliver hurtigere, og hvorfor din holdbarhedsposition ændrer sig. Den primære bekræfter transaktionen uden den eksterne bekræftelse. Den sekundære må derefter sakke bagud, og den forsinkelse er eksponeringen.

Hvis den primære går tabt, før loggen når et brugbart failover-mål, kasserer en tvungen flytning af tjenesten til den replika transaktioner, som applikationen allerede har fået at vide var godkendt.

Det er en beslutning om gendannelsespunkt, og den tilhører databaseejeren, ikke en ydelsesgennemgang. Fastlæg først det tolererede datatabsvindue, vælg den tilstand, der opfylder det, og optimér derefter inden for den grænse. Muligheder, der bevarer synkron beskyttelse, omfatter at fjerne undgåelige godkendelsesrejser, hvor applikationen tillader det, at rette en målt flaskehals i transport eller lager og at flytte replikaen, så bekræftelsen rejser kortere. Afvej dem mod det holdbarhedskrav, du startede med, og som ikke har ændret sig.