Por que un VPN rápido aínda frea unha confirmación SQL síncrona

Abra unha sesión de consulta no primario e observe que espera unha escritura simple. Se a base de datos pertence a un grupo de dispoñibilidade con confirmación síncrona e a secundaria está conectada, parte desa espera sae do edificio: os rexistros do log viaxan á réplica, endurécense alí, e a nova dese endurecemento volve antes de que a confirmación remate. O ancho de banda non acurta esa viaxe de ida e volta. O percorrido seguinte segue o acuse de recibo desde a pantalla ata o disco remoto e de volta.

Comece polo tipo de espera no primario

Unha escritura que espera na réplica remota aparece como unha espera relacionada co log en lugar dunha espera de CPU ou de bloqueo, e a duración da transacción segue a viaxe de ida e volta en vez do número de filas. Moitas confirmacións pequenas fan iso evidente, porque cada unha paga a viaxe por separado. Unha soa operación masiva agocha o mesmo custo dentro dun acuse máis longo.

Ordene a súa carga de traballo por frecuencia de confirmación antes de concluír nada sobre a ligazón.

Lea o estado da réplica antes de ler a rede. Os contadores que importan son a cola de envío, a cola de redo e o estado de sincronización, e xuntos mostran se a secundaria segue o ritmo ou queda atrás. Unha cola de envío crecente apunta ao transporte, mentres que unha cola de redo crecente apunta ao traballo ou ao almacenamento propios da secundaria. Son reparacións distintas e ningunha mellora engadindo ancho de banda.

Siga o acuse ata a secundaria

Con confirmación síncrona, o primario espera a confirmación de que o log correspondente foi endurecido na secundaria antes de informar que a confirmación está feita. Endurecido significa duradeiro no log, non reproducido nas páxinas de datos. Esa distinción é xustamente a razón pola que unha secundaria síncrona pode quedar atrás en redo mentres aínda confirma o endurecemento.

Percorra o camiño en orde e mida cada etapa en lugar do conxunto. Os rexistros do log van polo transporte, a secundaria escríbeos e baleíraos, e o acuse volve polo mesmo camiño. O atraso do transporte, a planificación da secundaria e a latencia do disco de log da secundaria entran todos no total, e só o primeiro pertence ao dono da rede. Unha secundaria cuxo volume de log está saturado por outra cousa pode estirar cada confirmación mentres a ligazón está ociosa.

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 e despois dunha escritura representativa en lugar de unha vez nunha tarde tranquila. A diferenza é o que lle di que cola se moveu mentres a confirmación esperaba.

Mida o camiño, non a ligazón

Unha proba de rendemento mide a capacidade entre dous puntos que non son as súas réplicas, baixo unha carga que non é o seu traballo. Pida ao dono da rede o atraso e a perda ao longo do camiño real da réplica mentres corre tráfico real, en ambas as direccións. A perda importa máis que a capacidade aquí, porque un segmento perdido custa unha retransmisión e cada confirmación espera un acuse. Unha ligazón que parece excelente nunha proba de descarga pode seguir sendo inadecuada para un patrón de confirmacións moi falador.

Manteña intactas a seguridade do transporte da base de datos e os controis de acceso mentres mide. Medir un camiño nunca é razón para saltalos.

Correlacione os tempos cos contadores en lugar de coa intuición. Se a cola de envío segue baleira e a confirmación aínda espera, o atraso está no acuse ou no baleirado da secundaria. Se a cola de envío medra de forma constante, o transporte ou a capacidade son a restrición. Anote que observación apoiou a conclusión para que a seguinte persoa poida repetir a medición en lugar da discusión.

Que cambia de verdade o modo asíncrono

A confirmación asíncrona elimina a espera do acuse de endurecemento da secundaria, e por iso as escrituras van máis rápido e por iso cambia a súa posición de durabilidade. O primario confirma a transacción sen ese acuse remoto. Entón permítese que a secundaria quede atrás, e ese atraso é a exposición.

Se se perde o primario antes de que o log chegue a un obxectivo de conmutación por erro utilizábel, forzar o servizo nesa réplica descarta transaccións que a aplicación xa recibira como confirmadas.

É unha decisión de punto de recuperación e pertence ao dono da base de datos, non a unha revisión de rendemento. Fixe primeiro a xanela de perda de datos tolerada, escolla o modo que a satisface e logo optimice dentro dese límite. As opcións que manteñen a protección síncrona inclúen eliminar as viaxes de confirmación evitábeis onde a aplicación o permita, corrixir un pescozo de botella medido de transporte ou almacenamento, e mover a réplica para que o acuse percorra menos distancia. Péseas contra o requisito de durabilidade co que comezou, que non cambiou.