Perché il tuo commit SQL sincrono attende il viaggio di andata e ritorno sulla VPN

La latenza di scrittura è schizzata dopo che una replica è stata spostata nel secondo sito, e il tunnel è il componente più recente, quindi si prende la colpa. Il tunnel può essere innocente: dentro un gruppo di disponibilità con commit sincrono la primaria non può confermare un commit finché non è completata una scrittura di log remota, quindi ogni transazione paga un viaggio di andata e ritorno per quanti megabit la linea possa trasportare. Il throughput misura byte al secondo, la latenza misura quanto dura uno scambio, e un commit ha bisogno solo di un piccolo scambio per concludersi. Un solo numero chiude la discussione: la durata del commit di una piccola transazione, misurata dentro il database di disponibilità e poi di nuovo contro una tabella locale sulla stessa istanza.

Che cosa attende davvero la primaria

Con il commit sincrono la primaria trattiene l'accusa del commit finché il partner non conferma che i suoi record di log sono irrobustiti. Irrobustito significa scritto in modo durevole nel log delle transazioni della secondaria, non rieseguito nelle sue pagine dati. Il redo può restare indietro di minuti senza aggiungere un solo millisecondo al commit della primaria.

La documentazione Microsoft sui modi di disponibilità illustra quella stretta di mano e cosa fa la piattaforma quando un partner esce. Una replica contrassegnata come sincrona è una regola sull'attesa, non una promessa permanente che esista una copia remota sana per ogni commit. Il percorso disconnesso è definito a parte, e non è semplicemente che il commit fallisce.

Quindi l'attesa che osservate è una somma: trasporto del log, pianificazione su entrambi gli host e la scrittura sullo storage remoto. Una secondaria con un volume di log saturo aggiunge tempo che nessun test di velocità mostrerà. Quel disco viene raramente misurato quando la lamentela nomina la VPN.

La larghezza di banda non è ritardo di andata e ritorno

Un test di velocità inonda brevemente il percorso e riporta una velocità. Un commit chiede qualcosa di più stretto: quanto tempo impiega un piccolo messaggio a raggiungere l'altro lato, essere reso persistente e tornare. La lunghezza del percorso, le code e la perdita di pacchetti determinano quel numero, e nessuno di essi migliora quando il fornitore alza il tetto.

Un tunnel «veloce» può quindi aggiungere una penalità visibile a un carico di lavoro intensivo in scrittura composto da molte piccole transazioni sequenziali. Lo stesso totale di byte diviso su mille commit paga il viaggio di andata e ritorno mille volte; un trasferimento massivo lo paga una volta.

Chiedete al proprietario della rete ritardo e perdita misurati sulla rotta della replica stessa sotto un carico rappresentativo. Un ping da un portatile d'ufficio al gateway VPN, o un test di velocità verso un nodo vicino, non attribuisce quasi nulla alla rotta che il log percorre davvero. Fate coincidere la finestra di misura con le ore in cui la scrittura è lenta.

Leggete lo stato della replica prima di cambiare qualsiasi cosa

Partite da ciò che le istanze riportano di sé stesse, perché i due lati possono non essere d'accordo su quanto sia sana la partnership e una media del cruscotto nasconde quale coda si muove. Le query sotto rispondono a domande diverse: una legge lo stato di replica per database, l'altra legge come è configurata ogni replica. Eseguitele entrambe prima di toccare 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;

Il primo risultato separa il trasporto del log dal redo. log_send_queue_size che sale mentre redo_queue_size resta piatto significa che il log non è arrivato; il contrario significa che è arrivato e che la riproduzione è indietro. Solo il primo caso sta sul percorso del commit.

Il secondo risultato conferma quali repliche sono realmente configurate come supponete, perché un modo cambiato durante un incidente precedente tende a restare cambiato e non documentato. Leggete la riga che vi interessa invece del valore predefinito del gruppo: availability_mode_desc e failover_mode_desc sono per replica. secondary_lag_seconds esiste solo su SQL Server 2016 e successivi, quindi una build più vecchia vi lascia solo le colonne della coda di invio e del redo.

Poi misurate una scrittura rappresentativa invece di fidarvi di una media del cruscotto. Eseguite il blocco sotto nel database di disponibilità, poi eseguitelo di nuovo contro la stessa forma di tabella in un database fuori dal gruppo sulla stessa istanza. La differenza tra le due durate è un prezzo approssimativo del log remoto, e in una discussione con il team di rete tiene molto meglio di un grafico. Poi cambiate una variabile alla volta, altrimenti la differenza non significa più nulla.

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;

Che cosa compra il commit asincrono e quanto costa

Con il commit asincrono la primaria smette di attendere la conferma dell'irrobustimento remoto, così il viaggio di andata e ritorno esce dal percorso del commit. La latenza di commit scende e la secondaria è libera di restare indietro di una quantità che nessuno controlla. È una correzione reale per l'attesa e un cambiamento reale della promessa.

Il prezzo è una decisione sul punto di ripristino. Se la primaria muore prima che il suo log raggiunga un obiettivo di failover che potete davvero usare, spostare il servizio sulla copia asincrona scarta transazioni che l'applicazione aveva già segnalato come confermate. Nessuna finestra di configurazione lo presenta così, perché è una questione aziendale sulla perdita accettabile, non un'impostazione di prestazioni. Scrivete la finestra di perdita tollerata prima dell'incidente, non durante.

Concordate il modo con chi possiede i dati, per iscritto, insieme alla procedura di failover per il caso in cui l'obiettivo preferito non sia disponibile. Il sincrono in un documento di progettazione non è un manuale operativo, e l'asincrono non è una licenza per smettere di sorvegliare le code.

Scegliete una correzione che possiate difendere dopo

Esistono quattro opzioni oneste. Tagliate i viaggi di andata e ritorno del commit evitabili dove la semantica dell'applicazione consente il raggruppamento; correggete un collo di bottiglia di trasporto o di archiviazione che avete misurato, il che può significare un volume di log più veloce sulla secondaria invece di un tubo più grande; avvicinate la replica così il viaggio di andata e ritorno si riduce; oppure allentate la politica di protezione e accettate una finestra di perdita più ampia. Ognuna compra latenza spendendo qualcos'altro, e la quarta spende durabilità. Nominate la spesa prima di scegliere.

Decidete con l'obiettivo di latenza del carico di lavoro e il suo requisito di durabilità davanti a voi allo stesso tempo, perché ottimizzare l'uno spende l'altro in silenzio. Poi rieseguite la stessa transazione che avete misurato prima del cambiamento. Una correzione che non può muovere quel numero è una supposizione con un ticket di cambiamento.

Conservate le letture prima e dopo nel registro dei cambiamenti. Altrimenti la prossima persona che vede scritture lente ripete l'indagine dall'inizio e ricomincia a dare la colpa al tunnel.