Por qué un VPN rápido sigue frenando una confirmación SQL síncrona

Abra una sesión de consulta en el primario y observe qué espera una escritura simple. Si la base de datos pertenece a un grupo de disponibilidad con confirmación síncrona y la secundaria está conectada, parte de esa espera sale del edificio: los registros del log viajan a la réplica, se endurecen allí, y la noticia de ese endurecimiento vuelve antes de que la confirmación termine. El ancho de banda no acorta ese viaje de ida y vuelta. El recorrido siguiente sigue el acuse de recibo desde la pantalla hasta el disco remoto y de vuelta.

Empiece por el tipo de espera en el primario

Una escritura que espera en la réplica remota aparece como una espera relacionada con el log en lugar de una espera de CPU o de bloqueo, y la duración de la transacción sigue el viaje de ida y vuelta en vez del número de filas. Muchas confirmaciones pequeñas lo hacen evidente, porque cada una paga el viaje por separado. Una sola operación masiva esconde el mismo coste dentro de un acuse más largo.

Ordene su carga de trabajo por frecuencia de confirmación antes de concluir nada sobre el enlace.

Lea el estado de la réplica antes de leer la red. Los contadores que importan son la cola de envío, la cola de redo y el estado de sincronización, y juntos muestran si la secundaria sigue el ritmo o se queda atrás. Una cola de envío creciente apunta al transporte, mientras que una cola de redo creciente apunta al trabajo o al almacenamiento propios de la secundaria. Son reparaciones distintas y ninguna mejora añadiendo ancho de banda.

Siga el acuse hasta la secundaria

Con confirmación síncrona, el primario espera la confirmación de que el log correspondiente se ha endurecido en la secundaria antes de informar que la confirmación está hecha. Endurecido significa duradero en el log, no reproducido en las páginas de datos. Esa distinción es justo la razón por la que una secundaria síncrona puede quedarse atrás en redo mientras sigue confirmando el endurecimiento.

Recorra el camino en orden y mida cada etapa en lugar del conjunto. Los registros del log van por el transporte, la secundaria los escribe y los vacía, y el acuse vuelve por el mismo camino. El retardo del transporte, la planificación de la secundaria y la latencia del disco de log de la secundaria entran todos en el total, y solo el primero pertenece al dueño de la red. Una secundaria cuyo volumen de log está saturado por otra cosa puede estirar cada confirmación mientras el enlace está ocioso.

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;

Tome esa instantánea antes y después de una escritura representativa en lugar de una vez en una tarde tranquila. La diferencia es lo que le dice qué cola se movió mientras la confirmación esperaba.

Mida el camino, no el enlace

Una prueba de rendimiento mide la capacidad entre dos puntos que no son sus réplicas, bajo una carga que no es su trabajo. Pida al dueño de la red el retardo y la pérdida a lo largo del camino real de la réplica mientras corre tráfico real, en ambas direcciones. La pérdida importa más que la capacidad aquí, porque un segmento perdido cuesta una retransmisión y cada confirmación espera un acuse. Un enlace que parece excelente en una prueba de descarga puede seguir siendo inadecuado para un patrón de confirmaciones muy hablador.

Mantenga intactas la seguridad del transporte de la base de datos y los controles de acceso mientras mide. Medir un camino nunca es razón para saltárselos.

Correlacione los tiempos con los contadores en lugar de con la intuición. Si la cola de envío sigue vacía y la confirmación aún espera, el retardo está en el acuse o en el vaciado de la secundaria. Si la cola de envío crece de forma constante, el transporte o la capacidad son la restricción. Anote qué observación respaldó la conclusión para que la siguiente persona pueda repetir la medición en lugar de la discusión.

Qué cambia realmente el modo asíncrono

La confirmación asíncrona elimina la espera del acuse de endurecimiento de la secundaria, y por eso las escrituras van más rápido y por eso cambia su posición de durabilidad. El primario confirma la transacción sin ese acuse remoto. Entonces se permite que la secundaria se quede atrás, y ese retraso es la exposición.

Si se pierde el primario antes de que el log llegue a un objetivo de conmutación por error utilizable, forzar el servicio en esa réplica descarta transacciones que la aplicación ya había recibido como confirmadas.

Es una decisión de punto de recuperación y pertenece al dueño de la base de datos, no a una revisión de rendimiento. Fije primero la ventana de pérdida de datos tolerada, elija el modo que la satisface y luego optimice dentro de ese límite. Las opciones que mantienen la protección síncrona incluyen eliminar los viajes de confirmación evitables donde la aplicación lo permita, corregir un cuello de botella medido de transporte o almacenamiento, y mover la réplica para que el acuse recorra menos distancia. Péselas contra el requisito de durabilidad con el que empezó, que no ha cambiado.