Database di SQL Server Distributed Availability Group non sincronizzati dopo il riavvio del server

Ci stiamo preparando per eseguire un grande aggiornamento sui nostri server SQL e stiamo notando alcuni comportamenti insoliti con i gruppi di disponibilità distribuita che sto cercando di risolvere prima di andare avanti.

Il mese scorso, ho aggiornato un server secondario remoto da SQL Server 2016 a SQL Server 2017. Questo server fa parte di più gruppi di disponibilità distribuiti (DAG) e un gruppo di disponibilità separato (AG) . Quando abbiamo aggiornato questo server, non eravamo consapevoli che sarebbe entrato in uno stato illeggibile , quindi durante il mese scorso abbiamo fatto affidamento esclusivamente sul server primario.

Come parte del prossimo aggiornamento, ho applicato la patch CU 4 al server e l'ho riavviata. Quando il server è tornato online, il secondario appena patchato mostrava che tutti i DAG / AG si stavano sincronizzando senza problemi.

Tuttavia, il primario stava mostrando una storia molto diversa. Lo riferiva

• l'AG separata si stava sincronizzando senza problemi
• ma i DAG erano in un non Synchronzing / Non sano Stato

Dopo il panico iniziale, ho tentato le seguenti cose per sincronizzare nuovamente le cose nei DAG:

• Dal primario, mi sono fermato e ho ripreso il movimento dei dati. Questo non ha iniziato a sincronizzare i dati.
• Sul secondario (quello che ho appena patchato) ho eseguito ALTER DATABASE [<database] SET HADR RESUME;- che viene eseguito senza errori, ma non ha ripreso alcuna sincronizzazione

Il mio ultimo tentativo di sincronizzare nuovamente i dati è stato quello di accedere al secondario e riavviare manualmente il servizio SQL Server. Il riavvio manuale del servizio sembra un po 'estremo, poiché mi aspetto che il riavvio del server sarebbe stato sufficiente.

Qualcuno ha riscontrato questo problema in cui un DAG non inizia la sincronizzazione con un secondario dopo un riavvio? In tal caso, come è stato risolto?

Ho controllato sia il registro degli errori di SQL Server, sia il visualizzatore eventi sul server secondario, non c'era nulla di straordinario che potessi vedere.

Nota che questa non è una risposta definitiva, ma è la risposta migliore dopo aver chattato con Taryn .

Tuttavia, il primario stava mostrando una storia molto diversa. Stava segnalando che l'AG separato si stava sincronizzando senza problemi ma i DAG erano in uno stato Non sincronizzato / Non integro

Se i singoli database e le AG sottostanti all'ag distribuito dichiarano che sono integri e sincronizzati, ci sono buone probabilità che questo sia solo un singhiozzo nei DMV e / o nei dashboard SSMS. Poiché nel log degli errori non c'era nulla che suggerisse che la replica non si connettesse o fosse in uno stato disconnesso.

Sfortunatamente poiché il problema è stato risolto, è difficile dire esattamente cosa fosse ... ma in futuro se questo si verifica per qualcuno:

• Controlla sys.dm_hadr_database_replica_states su tutti i cluster alla ricerca di qualcosa che non sia salutare. Se tutto risulta integro, è possibile che il DMV non sia ancora stato aggiornato
• Se non è salutare, controlla il log degli errori / DMV per problemi di connettività (come non essere in grado di connettersi allo spedizioniere / primario globale)
• La risposta di Dan menziona i problemi che potrebbero derivare dall'avvio del database, anche se in questo caso l'istanza non può essere letta, quindi molto probabilmente non è stato un problema, ma potrebbe esserlo nel tuo caso
• Se il database è leggibile, test del fumo con una tabella / inserto fittizi o ...
• Sessione di eventi estesa utilizzando gli elementi del canale DEBUG sqlserver.hadr_dump_log_blocko sqlserver.hadr_apply_log_blockper vedere se il secondario sta effettivamente ricevendo / applicando i blocchi di registro o ...
• Oggetto Perfmon SQLServer:Database Replica\Log Bytes Received/sec

Se stai ricevendo dati su quel secondario ma l'agente distribuito mostra ancora che non è sincronizzato o non integro, lascerei perdere un po 'per vedere se i valori DMV cambiano poiché ovviamente riceve ed elabora blocchi di log.

Se, tuttavia, non lo è, dovremo indagare ulteriormente al di fuori dell'ambito della risposta.

Premetto tutto questo con l'avvertenza che non ho alcun DAG in produzione. Fondamentalmente, tuttavia, questo consiglio dovrebbe applicarsi sia tra AG che DAG.

La sincronizzazione è stata ripristinata dopo il riavvio del servizio? In tal caso, la mia ipotesi migliore sulla causa sarebbe il blocco sullo SPID rifatto. Se non si sta ancora sincronizzando anche dopo il riavvio, ecco cosa controllerei per primo:

Blocco di AG redo SPID

Generalmente si verificherà solo su un secondario leggibile. Per verificare, eseguire quanto segue:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Se vengono visualizzati SPID di blocco, è necessario ucciderli prima che il secondario possa riprendere (lo DB STARTUPSPID è ciò che gestisce le operazioni di ripristino). Suggerirei di rivedere in anticipo lo SPID di blocco per provare a determinare la causa (di solito un rapporto di lunga durata).

Se vuoi ulteriori informazioni su questo, c'è un ottimo articolo (incluso il monitoraggio di questo tipo di comportamento usando gli XE) qui .

Controlla i DMV

Se il movimento dei dati viene sospeso, è possibile fare riferimento ai DMV per ottenere ulteriori informazioni sul motivo della sospensione. Eseguire quanto segue:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

L' articolo BOL descrive un po 'di più il suspend_reason.

Il tuo gruppo di disponibilità distribuita (DAG) è suddiviso tra regioni diverse? In tal caso potresti avere il valore SESSION_TIMEOUT predefinito (10 secondi) troppo basso. Ciò significa che la latenza tra le due aree è troppo elevata per completare in modo affidabile la sincronizzazione.

A un normale gruppo di disponibilità può essere aumentato il valore SESSION_TIMEOUT per rendere più stabili le sessioni di sincronizzazione. Ho notato alla fine dell'anno scorso che il parametro SESSION_TIMEOUT dei DAG non poteva essere modificato. Ciò significava che i DAG erano fattibili solo per scenari a bassa latenza. Abbiamo registrato un ticket con Microsoft e all'inizio di quest'anno è stato rilasciato un aggiornamento rapido.

Miglioramento: configurare il valore SESSION_TIMEOUT per una replica del gruppo di disponibilità distribuita in SQL Server 2016 e 2017