Por qué su confirmación SQL síncrona espera el viaje de ida y vuelta por la VPN

La latencia de escritura se disparó después de que una réplica se mudara al segundo sitio, y el túnel es el componente más nuevo, así que se lleva la culpa. El túnel puede ser inocente: dentro de un grupo de disponibilidad con confirmación síncrona, la primaria no puede acusar recibo de una confirmación hasta que se complete una escritura remota del registro, así que cada transacción paga un viaje de ida y vuelta por muchos megabits que pueda transportar el enlace. El rendimiento mide bytes por segundo, la latencia mide cuánto dura un intercambio, y una confirmación solo necesita un pequeño intercambio para terminar. Un solo número zanja la discusión: la duración de la confirmación de una transacción pequeña, medida dentro de la base de datos de disponibilidad y de nuevo contra una tabla local en la misma instancia.

Qué espera realmente la primaria

Con confirmación síncrona, la primaria retiene el acuse de la confirmación hasta que el socio confirma que sus registros de registro están endurecidos. Endurecido significa escrito de forma duradera en el registro de transacciones de la secundaria, no reejecutado en sus páginas de datos. El redo puede quedarse atrás minutos sin añadir ni un milisegundo a la confirmación de la primaria.

Documentación de Microsoft sobre los modos de disponibilidad explica ese apretón de manos y describe qué hace la plataforma cuando un socio se cae. Una réplica marcada como síncrona es una regla sobre esperar, no una promesa permanente de que exista una copia remota sana para cada confirmación. La ruta desconectada se define aparte, y no es simplemente que la confirmación falle.

Así que la espera que observa es una suma: transporte del registro, planificación en ambos hosts y la escritura en el almacenamiento remoto. Una secundaria con un volumen de registro saturado añade tiempo que ninguna prueba de velocidad mostrará. Ese disco rara vez se mide cuando la queja menciona la VPN.

El ancho de banda no es retardo de ida y vuelta

Una prueba de velocidad inunda la ruta brevemente e informa una tasa. Una confirmación pide algo más estrecho: cuánto tarda un mensaje pequeño en llegar al otro lado, persistirse y volver. La longitud de la ruta, las colas y la pérdida de paquetes fijan ese número, y ninguno de ellos mejora cuando el proveedor sube el techo.

Por eso un túnel «rápido» puede añadir una penalización visible a una carga de trabajo intensiva en escritura formada por muchas transacciones pequeñas y secuenciales. El mismo total de bytes repartido entre mil confirmaciones paga el viaje de ida y vuelta mil veces; una transferencia masiva lo paga una vez.

Pida al propietario de la red el retardo y la pérdida medidos sobre la propia ruta de la réplica bajo una carga representativa. Un ping desde un portátil de oficina hasta la puerta de enlace VPN, o una prueba de velocidad a un nodo cercano, no atribuye casi nada a la ruta que el registro recorre de verdad. Haga que la ventana de medición coincida con las horas en que la escritura es lenta.

Lea el estado de la réplica antes de cambiar nada

Empiece por lo que las instancias informan sobre sí mismas, porque las dos partes pueden discrepar sobre lo sana que es la asociación y una media del panel oculta qué cola se mueve. Las consultas de abajo responden a preguntas distintas: una lee el estado de replicación por base de datos, la otra lee cómo está configurada cada réplica. Ejecute 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;

El primer resultado separa el transporte del registro del redo. log_send_queue_size subiendo mientras redo_queue_size se mantiene plano significa que el registro no ha llegado; lo contrario significa que llegó y que la reproducción va por detrás. Solo el primer caso está en la ruta de la confirmación.

El segundo resultado confirma qué réplicas están realmente configuradas como usted supone, porque un modo cambiado durante un incidente anterior suele quedarse cambiado y sin documentar. Lea la fila que le interesa en lugar del valor predeterminado del grupo: availability_mode_desc y failover_mode_desc son por réplica. secondary_lag_seconds solo existe en SQL Server 2016 y posteriores, así que una compilación más antigua le deja solo las columnas de cola de envío y de redo.

Luego mida una escritura representativa en lugar de fiarse de una media del panel. Ejecute el bloque de abajo en la base de datos de disponibilidad y después ejecútelo de nuevo contra la misma forma de tabla en una base de datos fuera del grupo en la misma instancia. La diferencia entre las dos duraciones es un precio aproximado del registro remoto, y en una discusión con el equipo de red aguanta mucho mejor que un gráfico. Después cambie una variable cada vez, o la diferencia deja 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;

Qué compra la confirmación asíncrona y qué cuesta

Con confirmación asíncrona, la primaria deja de esperar la confirmación del endurecimiento remoto, así que el viaje de ida y vuelta sale de la ruta de la confirmación. La latencia de confirmación baja y la secundaria es libre de quedarse atrás una cantidad que nadie controla. Es una solución real para la espera y un cambio real de la promesa.

El precio es una decisión sobre el punto de recuperación. Si la primaria muere antes de que su registro llegue a un destino de conmutación por error que realmente pueda usar, mover el servicio a la copia asíncrona descarta transacciones que la aplicación ya había informado como confirmadas. Ningún diálogo de configuración lo presenta así, porque es una cuestión de negocio sobre la pérdida aceptable, no un ajuste de rendimiento. Escriba la ventana de pérdida tolerada antes del incidente, no durante.

Acuerde el modo con quien posee los datos, por escrito, junto con el procedimiento de conmutación por error para el caso en que el destino preferido no esté disponible. Lo síncrono en un documento de diseño no es un manual operativo, y lo asíncrono no es una licencia para dejar de vigilar las colas.

Elija una solución que pueda defender después

Existen cuatro opciones honestas. Recorte los viajes de confirmación evitables donde la semántica de la aplicación permita agrupar; arregle un cuello de botella de transporte o de almacenamiento que haya medido, lo que puede significar un volumen de registro más rápido en la secundaria en lugar de un tubo más grande; acerque la réplica para que el viaje de ida y vuelta se encoja; o relaje la política de protección y acepte una ventana de pérdida más amplia. Cada una compra latencia gastando otra cosa, y la cuarta gasta durabilidad. Nómbrelo antes de elegir.

Decida con el objetivo de latencia de la carga de trabajo y su requisito de durabilidad delante al mismo tiempo, porque optimizar uno gasta el otro en silencio. Después vuelva a ejecutar la misma transacción que midió antes del cambio. Una solución que no puede mover ese número es una conjetura con un ticket de cambio.

Guarde las lecturas de antes y después en el registro de cambios. Si no, la siguiente persona que vea escrituras lentas repite la investigación desde el principio y empieza culpando otra vez al túnel.