Perché una VPN veloce rallenta ancora una conferma SQL sincrona

Aprire una sessione di query sul primario e osservare cosa attende una scrittura semplice. Se il database appartiene a un gruppo di disponibilità con conferma sincrona e la secondaria è connessa, parte di quell'attesa esce dall'edificio: i record del log viaggiano verso la replica, vengono induriti lì, e la notizia di quell'indurimento torna prima che la conferma finisca. La larghezza di banda non accorcia quel viaggio di andata e ritorno. Il percorso sotto segue l'accettazione dallo schermo al disco remoto e ritorno.

Iniziate dal tipo di attesa sul primario

Una scrittura in attesa sulla replica remota appare come un'attesa legata al log invece che un'attesa di CPU o di lock, e la durata della transazione segue il viaggio di andata e ritorno invece del numero di righe. Molte conferme piccole lo rendono evidente, perché ognuna paga il viaggio separatamente. Una sola operazione massiva nasconde lo stesso costo dentro un'accettazione più lunga.

Ordinate il carico di lavoro per frequenza di conferma prima di concludere qualcosa sul collegamento.

Leggete lo stato della replica prima di leggere la rete. I contatori che contano sono la coda di invio, la coda di redo e lo stato di sincronizzazione, e insieme mostrano se la secondaria tiene il passo o resta indietro. Una coda di invio in crescita punta al trasporto, mentre una coda di redo in crescita punta al lavoro o allo storage della secondaria stessa. Sono riparazioni diverse e nessuna migliora aggiungendo larghezza di banda.

Seguite l'accettazione fino alla secondaria

Con la conferma sincrona il primario attende la conferma che il log in questione sia stato indurito sulla secondaria prima di dichiarare la conferma completata. Indurito significa durevole nel log, non riprodotto nelle pagine dati. È proprio questa distinzione a spiegare perché una secondaria sincrona possa restare indietro nel redo pur continuando a confermare l'indurimento.

Percorrete il cammino in ordine e misurate ogni fase invece dell'insieme. I record del log passano per il trasporto, la secondaria li scrive e li scarica, e l'accettazione torna lungo lo stesso cammino. Il ritardo del trasporto, la pianificazione della secondaria e la latenza del disco di log della secondaria finiscono tutte nel totale, e solo la prima appartiene al responsabile della rete. Una secondaria il cui volume di log è saturato da altro può allungare ogni conferma mentre il collegamento resta inattivo.

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;

Prendete quell'istantanea prima e dopo una scrittura rappresentativa invece di una volta in un pomeriggio tranquillo. La differenza è ciò che vi dice quale coda si è mossa mentre la conferma attendeva.

Misurate il cammino, non il collegamento

Un test di throughput misura la capacità tra due punti che non sono le vostre repliche, sotto un carico che non è il vostro lavoro. Chiedete al responsabile della rete il ritardo e la perdita lungo il cammino reale della replica mentre scorre traffico reale, in entrambe le direzioni. La perdita qui conta più della capacità, perché un segmento perso costa una ritrasmissione e ogni conferma attende un'accettazione. Un collegamento che sembra eccellente in un test di download può ancora essere inadatto a un modello di conferme molto loquace.

Mantenete intatti la sicurezza del trasporto del database e i controlli di accesso mentre misurate. Misurare un cammino non è mai una ragione per aggirarli.

Correlate i tempi con i contatori invece che con l'intuito. Se la coda di invio resta vuota e la conferma attende ancora, il ritardo è nell'accettazione o nello scarico della secondaria. Se la coda di invio cresce costantemente, il vincolo è il trasporto o la capacità. Annotate quale osservazione ha sostenuto la conclusione, così la persona successiva può ripetere la misura invece della discussione.

Cosa cambia davvero la modalità asincrona

La conferma asincrona elimina l'attesa dell'accettazione di indurimento della secondaria, ed è per questo che le scritture diventano più veloci e che cambia la vostra posizione di durabilità. Il primario conferma la transazione senza quell'accettazione remota. Alla secondaria è allora permesso restare indietro, e quel ritardo è l'esposizione.

Se il primario va perso prima che il log raggiunga un obiettivo di failover utilizzabile, forzare il servizio su quella replica scarta transazioni che l'applicazione aveva già ricevuto come confermate.

È una decisione sul punto di ripristino e appartiene al responsabile del database, non a una revisione delle prestazioni. Fissate prima la finestra di perdita dati tollerata, scegliete la modalità che la soddisfa, poi ottimizzate dentro quel limite. Le opzioni che mantengono la protezione sincrona includono la rimozione dei viaggi di conferma evitabili dove l'applicazione lo consente, la correzione di un collo di bottiglia misurato di trasporto o storage, e lo spostamento della replica perché l'accettazione percorra meno distanza. Pesatele contro il requisito di durabilità con cui avete iniziato, che non è cambiato.