Per què la vostra confirmació SQL síncrona espera el viatge d'anada i tornada per la VPN

La latència d'escriptura va fer un salt després que una rèplica es traslladés al segon lloc, i el túnel és el component més nou, així que s'emporta la culpa. El túnel pot ser innocent: dins d'un grup de disponibilitat amb confirmació síncrona, la primària no pot reconèixer una confirmació fins que no s'hagi completat una escriptura del registre remot, així que cada transacció paga un viatge d'anada i tornada per molts megabits que l'enllaç pugui portar. El rendiment mesura bytes per segon, la latència mesura quant dura un intercanvi, i una confirmació només necessita un petit intercanvi per acabar. Un sol número resol la discussió: la durada de la confirmació d'una transacció petita, mesurada dins de la base de dades de disponibilitat i de nou contra una taula local a la mateixa instància.

Què espera realment la primària

Amb confirmació síncrona, la primària reté l'acusament de confirmació fins que el soci confirma que els seus registres de registre estan endurits. Endurit vol dir escrit de manera duradora al registre de transaccions de la secundària, no reexecutat a les seves pàgines de dades. El redo pot quedar-se enrere minuts sense afegir ni un mil·lisegon a la confirmació de la primària.

Documentació de Microsoft sobre els modes de disponibilitat explica aquesta encaixada de mans i descriu què fa la plataforma quan un soci cau. Una rèplica marcada com a síncrona és una regla sobre esperar, no una promesa permanent que existeixi una còpia remota sana per a cada confirmació. El camí desconnectat es defineix a part, i no és simplement que la confirmació falli.

Així, l'espera que observeu és una suma: transport del registre, planificació als dos hosts i escriptura a l'emmagatzematge remot. Una secundària amb un volum de registre saturat afegeix temps que cap prova de velocitat no mostrarà. Aquest disc rarament es mesura quan la queixa esmenta la VPN.

L'amplada de banda no és retard d'anada i tornada

Una prova de velocitat inunda el camí breument i informa d'una taxa. Una confirmació demana una cosa més estreta: quant triga un missatge petit a arribar a l'altra banda, persistir-se i tornar. La longitud del camí, les cues i la pèrdua de paquets fixen aquest número, i cap d'ells no millora quan el proveïdor apuja el sostre.

Per tant, un túnel «ràpid» pot afegir una penalització visible a una càrrega de treball intensiva en escriptura feta de moltes transaccions petites i seqüencials. El mateix total de bytes repartit entre mil confirmacions paga el viatge d'anada i tornada mil vegades; una transferència massiva el paga una vegada.

Demaneu al propietari de la xarxa el retard i la pèrdua mesurats sobre la mateixa ruta de la rèplica sota una càrrega representativa. Un ping des d'un portàtil d'oficina fins a la passarel·la VPN, o una prova de velocitat fins a un node proper, gairebé no atribueix res a la ruta que el registre recorre de debò. Feu que la finestra de mesura coincideixi amb les hores en què l'escriptura és lenta.

Llegiu l'estat de la rèplica abans de canviar res

Comenceu pel que les instàncies informen sobre elles mateixes, perquè les dues bandes poden discrepar sobre com de sana és l'associació i una mitjana del tauler amaga quina cua es mou. Les consultes de sota responen preguntes diferents: una llegeix l'estat de replicació per base de dades, l'altra llegeix com està configurada cada rèplica. Executeu-les totes dues abans de tocar cap mode.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

El primer resultat separa el transport del registre del redo. log_send_queue_size pujant mentre redo_queue_size es manté pla vol dir que el registre no ha arribat; el contrari vol dir que ha arribat i que la reproducció va enrere. Només el primer cas seu al camí de la confirmació.

El segon resultat confirma quines rèpliques estan realment configurades tal com suposeu, perquè un mode canviat durant un incident anterior sol quedar canviat i sense documentar. Llegiu la fila que us interessa en lloc del valor per defecte del grup: availability_mode_desc i failover_mode_desc són per rèplica. secondary_lag_seconds només existeix a SQL Server 2016 i posteriors, així que una versió més antiga us deixa només les columnes de cua d'enviament i de redo.

A continuació, mesureu una escriptura representativa en lloc de confiar en una mitjana del tauler. Executeu el bloc de sota a la base de dades de disponibilitat, i després torneu-lo a executar contra la mateixa forma de taula en una base de dades fora del grup a la mateixa instància. La diferència entre les dues durades és un preu aproximat del registre remot, i en una discussió amb l'equip de xarxa aguanta molt millor que un gràfic. Després canvieu una variable alhora, o la diferència deixa de significar res.

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

Què compra la confirmació asíncrona i què costa

Amb confirmació asíncrona, la primària deixa d'esperar la confirmació de l'enduriment remot, així que el viatge d'anada i tornada surt del camí de la confirmació. La latència de confirmació baixa i la secundària és lliure de quedar-se enrere una quantitat que ningú controla. És una solució real per a l'espera i un canvi real de la promesa.

El preu és una decisió sobre el punt de recuperació. Si la primària mor abans que el seu registre arribi a un objectiu de failover que realment pugueu fer servir, moure el servei a la còpia asíncrona descarta transaccions que l'aplicació ja havia informat com a confirmades. Cap diàleg de configuració ho presenta així, perquè és una qüestió de negoci sobre la pèrdua acceptable, no un paràmetre de rendiment. Escriviu la finestra de pèrdua tolerada abans de l'incident, no durant.

Acordeu el mode amb qui posseeix les dades, per escrit, juntament amb el procediment de failover per al cas que l'objectiu preferit no estigui disponible. El síncron en un document de disseny no és un manual operatiu, i l'asíncron no és una llicència per deixar de vigilar les cues.

Trieu una solució que pugueu defensar després

Hi ha quatre opcions honestes. Retalleu els viatges de confirmació evitables on la semàntica de l'aplicació permeti agrupar; repareu un coll d'ampolla de transport o d'emmagatzematge que hàgiu mesurat, cosa que pot significar un volum de registre més ràpid a la secundària en lloc d'un tub més gran; apropeu la rèplica perquè el viatge d'anada i tornada s'encongeixi; o afluixeu la política de protecció i accepteu una finestra de pèrdua més àmplia. Cadascuna compra latència gastant una altra cosa, i la quarta gasta durabilitat. Anomeneu la despesa abans de triar.

Decidiu amb l'objectiu de latència de la càrrega de treball i el requisit de durabilitat alhora davant vostre, perquè optimitzar un gasta l'altre en silenci. Després torneu a executar la mateixa transacció que vau mesurar abans del canvi. Una solució que no pot moure aquest número és una conjectura amb un tiquet de canvi.

Guardeu les lectures d'abans i després al registre de canvis. Si no, la propera persona que vegi escriptures lentes repeteix la investigació des del principi i torna a començar culpant el túnel.