Por que a súa confirmación SQL síncrona espera a viaxe de ida e volta pola VPN

A latencia de escritura disparouse despois de que unha réplica se mudase ao segundo sitio, e o túnel é o compoñente máis novo, así que leva a culpa. O túnel pode ser inocente: dentro dun grupo de dispoñibilidade con confirmación síncrona, a primaria non pode acusar recibo dunha confirmación ata que se complete unha escritura remota do rexistro, así que cada transacción paga unha viaxe de ida e volta por moitos megabits que poida transportar a ligazón. O rendemento mide bytes por segundo, a latencia mide canto dura un intercambio, e unha confirmación só necesita un pequeno intercambio para rematar. Un só número resolve a discusión: a duración da confirmación dunha transacción pequena, medida dentro da base de datos de dispoñibilidade e de novo contra unha táboa local na mesma instancia.

Que espera realmente a primaria

Con confirmación síncrona, a primaria retén o acuse da confirmación ata que o socio confirma que os seus rexistros de rexistro están endurecidos. Endurecido significa escrito de forma duradeira no rexistro de transaccións da secundaria, non reexecutado nas súas páxinas de datos. O redo pode quedar atrás minutos sen engadir nin un milisegundo á confirmación da primaria.

Documentación de Microsoft sobre os modos de dispoñibilidade explica ese apretón de mans e describe que fai a plataforma cando un socio cae. Unha réplica marcada como síncrona é unha regra sobre esperar, non unha promesa permanente de que exista unha copia remota san para cada confirmación. A ruta desconectada defínese aparte, e non é simplemente que a confirmación falle.

Así que a espera que observa é unha suma: transporte do rexistro, planificación nos dous hosts e a escritura no almacenamento remoto. Unha secundaria cun volume de rexistro saturado engade tempo que ningunha proba de velocidade mostrará. Ese disco raramente se mide cando a queixa menciona a VPN.

O ancho de banda non é retardo de ida e volta

Unha proba de velocidade inunda a ruta brevemente e informa unha taxa. Unha confirmación pide algo máis estreito: canto tarda unha mensaxe pequena en chegar ao outro lado, persistirse e volver. A lonxitude da ruta, as colas e a perda de paquetes fixan ese número, e ningún deles mellora cando o provedor sobe o teito.

Por iso un túnel «rápido» pode engadir unha penalización visible a unha carga de traballo intensiva en escritura formada por moitas transaccións pequenas e secuenciais. O mesmo total de bytes repartido entre mil confirmacións paga a viaxe de ida e volta mil veces; unha transferencia masiva paga una vez.

Pida ao propietario da rede o retardo e a perda medidos sobre a propia ruta da réplica baixo unha carga representativa. Un ping desde un portátil de oficina ata a pasarela VPN, ou unha proba de velocidade a un nodo próximo, non atribúe case nada á ruta que o rexistro percorre de verdade. Faga que a ventá de medición coincida coas horas en que a escritura é lenta.

Lea o estado da réplica antes de cambiar nada

Comece polo que as instancias informan sobre si mesmas, porque as dúas partes poden discrepar sobre o san que é a asociación e unha media do panel oculta que cola se move. As consultas de abaixo responden preguntas distintas: unha le o estado de replicación por base de datos, a outra le como está configurada cada réplica. Execute ambas antes de tocar un modo.

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;

O primeiro resultado separa o transporte do rexistro do redo. log_send_queue_size subindo mentres redo_queue_size se mantén plano significa que o rexistro non chegou; o contrario significa que chegou e que a reprodución vai por detrás. Só o primeiro caso está na ruta da confirmación.

O segundo resultado confirma que réplicas están realmente configuradas como vostede supón, porque un modo cambiado durante un incidente anterior adoita quedar cambiado e sen documentar. Lea a fila que lle interesa en lugar do valor predeterminado do grupo: availability_mode_desc e failover_mode_desc son por réplica. secondary_lag_seconds só existe en SQL Server 2016 e posteriores, así que unha compilación máis antiga déixalle só as columnas de cola de envío e de redo.

Despois mida unha escritura representativa en lugar de fiarse dunha media do panel. Execute o bloque de abaixo na base de datos de dispoñibilidade e despois execúteo de novo contra a mesma forma de táboa nunha base de datos fóra do grupo na mesma instancia. A diferenza entre as dúas duracións é un prezo aproximado do rexistro remoto, e nunha discusión co equipo de rede aguanta moito mellor ca un gráfico. Despois cambie unha variable cada vez, ou a diferenza deixa de significar nada.

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;

Que compra a confirmación asíncrona e que custa

Con confirmación asíncrona, a primaria deixa de esperar a confirmación do endurecemento remoto, así que a viaxe de ida e volta sae da ruta da confirmación. A latencia de confirmación baixa e a secundaria é libre de quedarse atrás unha cantidade que ninguén controla. É unha solución real para a espera e un cambio real da promesa.

O prezo é unha decisión sobre o punto de recuperación. Se a primaria morre antes de que o seu rexistro chegue a un destino de conmutación por erro que realmente poida usar, mover o servizo á copia asíncrona descarta transaccións que a aplicación xa informara como confirmadas. Ningún diálogo de configuración o presenta así, porque é unha cuestión de negocio sobre a perda aceptable, non un axuste de rendemento. Escriba a ventá de perda tolerada antes do incidente, non durante.

Acorde o modo con quen posúe os datos, por escrito, xunto co procedemento de conmutación por erro para o caso en que o destino preferido non estea dispoñible. O síncrono nun documento de deseño non é un manual operativo, e o asíncrono non é unha licenza para deixar de vixiar as colas.

Escolla unha solución que poida defender despois

Existen catro opcións honestas. Recorte as viaxes de confirmación evitables onde a semántica da aplicación permita agrupar; arranxe un pescozo de botella de transporte ou de almacenamento que medise, o que pode significar un volume de rexistro máis rápido na secundaria en lugar dun tubo máis grande; achegue a réplica para que a viaxe de ida e volta se encolla; ou relaxe a política de protección e acepte unha ventá de perda máis ampla. Cada unha compra latencia gastando outra cousa, e a cuarta gasta durabilidade. Nómbreo antes de escoller.

Decida co obxectivo de latencia da carga de traballo e o seu requisito de durabilidade diante ao mesmo tempo, porque optimizar un gasta o outro en silencio. Despois volva executar a mesma transacción que mediu antes do cambio. Unha solución que non pode mover ese número é unha conxectura cun ticket de cambio.

Garde as lecturas de antes e despois no rexistro de cambios. Se non, a seguinte persoa que vexa escrituras lentas repite a investigación desde o principio e comeza culpando outra vez o túnel.