Per què un VPN ràpid encara alenteix una confirmació SQL síncrona

Obriu una sessió de consulta al primari i observeu què espera una escriptura simple. Si la base de dades pertany a un grup de disponibilitat amb confirmació síncrona i la secundària està connectada, part d'aquesta espera surt de l'edifici: les entrades del registre viatgen a la rèplica, s'hi endureixen, i la notícia d'aquest enduriment torna abans que la confirmació acabi. L'amplada de banda no escurça aquest viatge d'anada i tornada. El recorregut següent segueix l'acusament de recepció des de la pantalla fins al disc remot i de tornada.

Comença pel tipus d'espera al primari

Una escriptura que espera a la rèplica remota es mostra com una espera relacionada amb el registre i no com una espera de CPU o de bloqueig, i la durada de la transacció segueix el viatge d'anada i tornada en lloc del nombre de files. Moltes confirmacions petites ho fan evident, perquè cadascuna paga el viatge per separat. Una sola operació massiva amaga el mateix cost dins d'un acusament més llarg.

Ordena la càrrega de treball per freqüència de confirmació abans de concloure res sobre l'enllaç.

Llegeix l'estat de la rèplica abans de llegir la xarxa. Els comptadors que importen són la cua d'enviament, la cua de redo i l'estat de sincronització, i junts mostren si la secundària segueix el ritme o es queda enrere. Una cua d'enviament creixent assenyala el transport, mentre que una cua de redo creixent assenyala la feina o l'emmagatzematge propis de la secundària. Són reparacions diferents i cap de les dues millora afegint amplada de banda.

Segueix l'acusament fins a la secundària

Amb confirmació síncrona, el primari espera la confirmació que el registre pertinent s'ha endurit a la secundària abans d'informar que la confirmació s'ha fet. Endurit vol dir durador al registre, no reproduït a les pàgines de dades. Aquesta distinció és exactament per què una secundària síncrona pot quedar enrere en redo mentre encara confirma l'enduriment.

Recorre el camí en ordre i mesura cada etapa en lloc del conjunt. Les entrades del registre passen pel transport, la secundària les escriu i les buida, i l'acusament torna pel mateix camí. El retard del transport, la planificació de la secundària i la latència del disc de registre de la secundària entren tots al total, i només el primer pertany a l'amo de la xarxa. Una secundària el volum de registre de la qual està saturat per una altra cosa pot allargar cada confirmació mentre l'enllaç està aturat.

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;

Pren aquesta instantània abans i després d'una escriptura representativa en lloc d'una vegada en una tarda tranquil·la. La diferència és el que et diu quina cua es va moure mentre la confirmació esperava.

Mesura el camí, no l'enllaç

Una prova de rendiment mesura la capacitat entre dos punts que no són les teves rèpliques, sota una càrrega que no és la teva feina. Demana a l'amo de la xarxa el retard i la pèrdua al llarg del camí real de la rèplica mentre hi ha trànsit real, en tots dos sentits. La pèrdua importa més que la capacitat aquí, perquè un segment perdut costa una retransmissió i cada confirmació espera un acusament. Un enllaç que sembla excel·lent en una prova de descàrrega encara pot ser inadequat per a un patró de confirmacions molt parlador.

Mantén intactes la seguretat del transport de la base de dades i els controls d'accés mentre mesures. Mesurar un camí no és mai una raó per saltar-se'ls.

Correlaciona els temps amb els comptadors en lloc de amb la intuïció. Si la cua d'enviament continua buida i la confirmació encara espera, el retard és a l'acusament o al buidatge de la secundària. Si la cua d'enviament creix de manera constant, el transport o la capacitat són la restricció. Anota quina observació va donar suport a la conclusió perquè la propera persona pugui repetir la mesura en lloc de l'argument.

Què canvia realment el mode asíncron

La confirmació asíncrona elimina l'espera de l'acusament d'enduriment de la secundària, i per això les escriptures van més de pressa i per això canvia la teva posició de durabilitat. El primari confirma la transacció sense aquesta confirmació remota. Llavors es permet que la secundària es quedi enrere, i aquest endarreriment és l'exposició.

Si es perd el primari abans que el registre arribi a un objectiu de commutació per error utilitzable, forçar el servei en aquesta rèplica descarta transaccions que l'aplicació ja havia rebut com a confirmades.

Aquesta és una decisió de punt de recuperació i pertany a l'amo de la base de dades, no a una revisió de rendiment. Fixa primer la finestra de pèrdua de dades tolerada, tria el mode que la satisfà, i després optimitza dins d'aquest límit. Les opcions que mantenen la protecció síncrona inclouen eliminar els viatges de confirmació evitables on l'aplicació ho permeti, arreglar un coll d'ampolla mesurat de transport o d'emmagatzematge, i moure la rèplica perquè l'acusament recorri menys distància. Pesa-les contra el requisit de durabilitat amb què vas començar, que no ha canviat.