SQL Server 2017 con 500 database: Frequent AG si disconnette da CU9

Ciao a tutti e grazie in anticipo per il vostro aiuto. Stiamo riscontrando problemi con i gruppi di disponibilità di SQL Server 2017.

sfondo

La società è un software back-end B2B al dettaglio. Circa 500 database a tenant singolo e 5 database condivisi utilizzati da tutti i tenant. La caratteristica del carico di lavoro viene letta principalmente e la maggior parte dei database ha un'attività molto bassa.

I server di produzione fisica ospitati in co-location sono stati recentemente aggiornati da SQL Server 2014 Enterprise su Windows Server 2012 in una configurazione SAN / FCI condivisa a SQL Server 2017 Enterprise su Windows Server 2016 su 2 socket / 32 core / 768 GB RAM e locale Unità SSD che utilizzano AlwaysOn AG. Il traffico AG utilizza porte NIC 10G dedicate con una connessione via cavo incrociata.

Il loro requisito è che tutti i database eseguano il failover insieme, quindi hanno dovuto metterli tutti in un'unica AG. È una singola replica sincrona non leggibile su un server identico.

I nuovi server sono in produzione da giugno 2018. Sono stati installati gli ultimi aggiornamenti CU (CU7 al momento) e Windows e il sistema funzionava bene. Circa un mese dopo, dopo aver aggiornato i server da CU7 a CU9, hanno iniziato a notare le seguenti sfide, elencate in ordine di priorità.

Abbiamo monitorato i server utilizzando SQL Sentry e non abbiamo riscontrato colli di bottiglia fisici. Tutti gli indicatori chiave sembrano buoni. La CPU ha una media del 20%, i tempi di I / O in genere inferiori a 1 ms, la RAM non completamente utilizzata e la rete <1%.

Le sfide

I sintomi sembrano migliorare dopo il failover, ma si ripresentano entro pochi giorni, indipendentemente dal server principale: i sintomi sono identici su entrambi i server.

1. Timeout client sporadici e errori di connettività come

   ... si è verificato un errore durante la creazione della connessione ...

   o

   Timeout di esecuzione scaduto

   A volte queste durano fino a 40 secondi, quindi si attenuano.

2. Il completamento del processo di backup del registro delle transazioni richiede 10 volte più tempo rispetto al passato. In precedenza sono stati necessari 2-3 minuti per eseguire il backup dei registri di tutti i 500 database, ora sono necessari 15-25. Abbiamo verificato che il backup stesso funziona correttamente con un buon throughput. Tuttavia, c'è un piccolo ritardo dopo aver completato il backup di un registro e prima di iniziare il successivo. inizia molto basso, ma entro un giorno o due arriva a 2-3 secondi. Moltiplicato per 500 database e c'è la differenza.

3. Occasionalmente, alcuni database apparentemente casuali rimangono bloccati nello stato "Non sincronizzato" dopo il failover manuale. L'unico modo per risolverlo è riavviare il servizio SQL Server sulla replica secondaria o rimuovere e ricollegare questi database all'AG.

4. Un altro problema introdotto da CU10 (e non risolto in CU11): connessioni al timeout secondario al blocco su database master.sys e persino impossibilità di utilizzare Esplora oggetti SSMS per la replica secondaria. La causa principale sembra essere bloccata dal writer VSS di Microsoft SQL Server che emette la query seguente:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases

osservazioni

Credo di aver trovato la pistola fumante nei registri degli errori. I log degli errori sono pieni di messaggi AG, etichettati come 'solo informativi', ma sembra che non siano affatto normali e che esiste una correlazione molto forte della loro frequenza con gli errori dell'applicazione.

Gli errori sono di diversi tipi e si presentano in sequenze:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• Connessione di gruppi di disponibilità AlwaysOn con database secondario terminata per il database primario "XYZ" sulla replica di disponibilità "DB" con ID replica: {GUID}. Questo è solo un messaggio informativo. Non è richiesta alcuna azione da parte dell'utente.

• Connessione Gruppi di disponibilità AlwaysOn con database secondario stabilito per il database primario "ABC" sulla replica di disponibilità "DB" con ID replica: {GUID}. Questo è solo un messaggio informativo. Non è richiesta alcuna azione da parte dell'utente.

Alcuni giorni ci sono decine di migliaia di quelli.

In questo articolo viene descritto lo stesso tipo di sequenza di errori in SQL 2016 e lì si afferma che è anormale. Ciò spiega anche il fenomeno "non sincronizzante" dopo il failover. La questione discussa era per il 2016 ed è stata risolta all'inizio di quest'anno in una CU. tuttavia, è l'unico riferimento pertinente che ho potuto trovare per i primi 2 tipi di messaggi, oltre ai riferimenti ai messaggi di seeding iniziale automatico che non dovrebbero essere qui in quanto l'AG è già stata stabilita.

Ecco un riepilogo degli errori giornalieri della scorsa settimana, per giorni con errori> 10K per tipo sul PRIMARY (il secondario mostra 'perdere la connessione con il primario ...'):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Occasionalmente vediamo anche messaggi "strani" come:

Il database del gruppo di disponibilità "DB" sta cambiando i ruoli da "SECONDARIO" a "SECONDARIO" perché la sessione di mirroring o il gruppo di disponibilità hanno eseguito il failover a causa della sincronizzazione dei ruoli. Questo è solo un messaggio informativo. Non è richiesta alcuna azione da parte dell'utente.

... tra una serie di stati che cambiano da "SECONDARIO" a "RISOLVERE".

Dopo il failover manuale, il sistema potrebbe andare avanti per diversi giorni senza un singolo messaggio di questi tipi e all'improvviso, senza motivo apparente, ne avremo migliaia contemporaneamente, il che a sua volta causerà la mancata risposta del server e causerà l'applicazione timeout di connessione. Si tratta di un bug critico in quanto alcune delle loro applicazioni non incorporano un meccanismo di tentativi e pertanto potrebbero perdere dati. Quando si verifica un tale scoppio di errori, la seguente attesa digita sky-rocket. Questo mostra le attese subito dopo che sembra aver perso la connessione a tutti i database contemporaneamente:

Circa 30 secondi dopo, tutto torna alla normalità in termini di attese, ma i messaggi di AG continuano a inondare i registri degli errori a velocità variabili e in diverse ore del giorno, orari apparentemente casuali incluse le ore di punta. L'aumento simultaneo del carico di lavoro durante queste esplosioni di errori ovviamente peggiora le cose. Se solo alcuni database vengono disconnessi, in genere non provoca il timeout delle connessioni poiché viene risolto abbastanza rapidamente da solo.

Abbiamo provato a verificare che effettivamente CU9 ha avviato il problema, ma siamo riusciti a eseguire il downgrade di entrambi i nodi solo a CU9. I tentativi di eseguire il downgrade di uno dei nodi a CU8 hanno comportato il blocco del nodo nello stato "Risoluzione" che mostra lo stesso errore nel registro:

Impossibile leggere la configurazione permanente del gruppo di disponibilità Always On con l'ID risorsa corrispondente '…. La configurazione permanente è scritta da un SQL Server di versione superiore che ospita la replica di disponibilità primaria. Aggiornare l'istanza locale di SQL Server per consentire alla replica di disponibilità locale di diventare una replica secondaria.

Ciò significa che dovremo introdurre i tempi di inattività per poter eseguire il downgrade di entrambi i nodi su CU8 contemporaneamente. Questo suggerisce anche che ci sono stati alcuni importanti aggiornamenti di AG che potrebbero spiegare ciò che stiamo vivendo.

Abbiamo già provato a regolare max_worker_threads dal suo valore predefinito di 0 (= 960 sulla nostra scatola in base a questo articolo ) gradualmente fino a 2.000 senza alcun impatto osservato sugli errori.

Cosa possiamo fare per risolvere queste disconnessioni AG? Qualcuno là fuori sta riscontrando problemi simili? Altre persone con un numero elevato di database in una AG possono forse vedere messaggi simili nel registro errori SQL che iniziano con CU9 o CU8?

Grazie in anticipo per qualsiasi aiuto!

Aggiornare:

1. Le disconnessioni del Gruppo di disponibilità frequente sono state confermate come una regressione introdotta da CU9 e sono state risolte dopo l'installazione di CU12.

2. I problemi di blocco sulla replica secondaria sono stati confermati come un problema con un aggiornamento al codice del writer VSS introdotto in CU10. Speriamo che venga risolto in CU 13. La soluzione provvisoria è sostituire manualmente le DLL del writer VSS con le DLL Pre-CU10 ...

   BEGIN RANT-SACTION;

   Sfortunatamente, Microsoft sembra non riuscire più volte a controllare correttamente il QA non solo gli aggiornamenti di Windows 10, ma anche i software mission-critical aziendali come SQL Server.

   Preferivo di gran lunga la loro precedente strategia di service pack, almeno avevano abbastanza tempo per testarli correttamente prima di infliggere crisi di produzione e perdita di dati ai loro clienti con il rilascio disinteressato di aggiornamenti a metà.

   COMMIT RANT-SACTION;

Hai controllato i thread di lavoro? Normalmente sempre attivo utilizzare più thread di lavoro per funzionare e normalmente il valore predefinito non è sufficiente. Ho avuto lo stesso problema con 600 database in un sempre attivo, quindi aggiungiamo più thread sul parametro dell'istanza e questo ha risolto il nostro problema. Spero che sia di aiuto!