Database del gruppo di disponibilità bloccato in modalità In attesa di non sincronizzazione / recupero

Durante l'aggiornamento dell'archiviazione in un'istanza di SQL Server 2014 SP1 (12.0.4422.0) ci siamo imbattuti in un problema in cui due dei database non si avviavano sul secondario dopo il riavvio di SQL Server. Il server è rimasto offline per alcune ore durante l'installazione di nuovi SSD (più grandi) e la copia dei file di dati nel nuovo volume. Quando abbiamo riavviato SQL Server, tutti i database tranne due hanno ricominciato a sincronizzarsi. Gli altri due sono stati visualizzati in SSMS come Non sincronizzato / Ripristino in sospeso .

Avendo avuto un simile problema Non sincronizzare / In Recovery prima, ho controllato lo stato nella sezione Gruppi di disponibilità -> Database di disponibilità ma hanno visualizzato una X rossa:

e anche il tentativo di sospendere lo spostamento dei dati ha generato un messaggio di errore:

Impossibile sospendere lo spostamento dei dati nel database "StackExchange.Bycycles.Meta", che risiede nella replica di disponibilità "ny-sql03" nel gruppo di disponibilità "SENetwork_AG". (Microsoft.SqlServer.Smo)

Informazioni aggiuntive: si è verificata un'eccezione durante l'esecuzione di un'istruzione o batch transact-SQL. (Microsoft.SqlServer.ConnectionInfo)

Impossibile aprire il database "StackExchange.Bycycles.Meta" a causa di file inaccessibili o spazio di memoria o disco insufficiente. Vedere il registro degli errori di SQL Server per i dettagli. (Microsoft SQL Server, errore: 945)

Ho controllato ed esistevano i file e non c'erano problemi di autorizzazione. Ho anche controllato i log di SQL Server in SSMS in Gestione, ma non ho visto nulla sul recupero in sospeso o eventuali problemi con i due database.

In cerca di aiuto ho trovato due diversi articoli in cui si diceva che i database avrebbero dovuto essere ripristinati.

C'è un modo per riprendere la replica dei dati su un secondario quando un database è bloccato in Recovery Pending?

Dal momento che il server era offline da un po ', abbiamo pensato che potrebbe essere andato fuori dalla finestra di recupero del primario. Abbiamo deciso di provare ad applicare gli ultimi registri delle transazioni sul database per vedere se ciò avrebbe avviato il processo di recupero:

-- Remove database from Availability Group:    
Alter Database [StackExchange.Bicycles.Meta] SET HADR OFF;

-- Apply t-logs to catch up. This can be done manually in SSMS or via:
RESTORE LOG [StackExchange.Bicycles.Meta] FROM DISK = '\\ny-back01\backups\SQL\_Trans\SENetwork_AG\StackExchange.Bicycles.Meta\StackExchange.Bicycles.Meta_LOG_20160217_033201.trn' WITH NORECOVERY;

-- Re-join database to availability group
ALTER DATABASE [StackExchange.Bicycles.Meta] SET HADR AVAILABILITY GROUP = [SENetwork_AG];
ALTER DATABASE [StackExchange.Bicycles.Meta] SET HADR RESUME;

Dopo aver eseguito quanto sopra sul server secondario per entrambi i database, sono stati in grado di riavviare la sincronizzazione.

AGGIORNAMENTO: si è verificato un problema simile in cui dopo un failover AG manuale uno dei database nella nuova replica primaria era bloccato in modalità Non sincronizzazione (passato a Non sincronizzazione / Ripristino in sospeso dopo il riavvio di SQL Server) e i passaggi precedenti hanno funzionato per risolverlo problema pure.

È possibile rimuovere il DB da AAG, sul nodo primario eseguire un backup completo e un backup delle transazioni, ripristinare questi due backup sul DB del nodo secondario, quindi aggiungere nuovamente il DB all'AAG. In questo momento potrebbe indicare che il nodo secondario DB non si sta sincronizzando, ma semplicemente facendo ciò che è suggerito nella seconda risposta (acquista il modo in cui è stato penalizzato -2), intendo spostare il nodo secondario in primario, lo risolverà.

La prossima volta, prova a eseguire il failover dal primario al secondario "non sincronizzato" e viceversa. Il secondario ora dovrebbe essere sincronizzato.