La base de datos del grupo de disponibilidad se atascó en modo Sin sincronización / Recuperación pendiente

Al actualizar el almacenamiento en una instancia de SQL Server 2014 SP1 (12.0.4422.0) nos encontramos con un problema en el que dos de las bases de datos no se iniciarían en el secundario después de reiniciar SQL Server. El servidor había estado desconectado durante unas horas mientras instalamos SSD nuevos (más grandes) y copiamos los archivos de datos al nuevo volumen. Cuando reiniciamos SQL Server, todas las bases de datos menos dos comenzaron a sincronizarse nuevamente. Los otros dos se mostraron en SSMS como Sin sincronización / Pendiente de recuperación .

Después de haber tenido un problema similar de No sincronizar / Recuperar antes, verifiqué el estado en la sección Grupos de disponibilidad -> Bases de datos de disponibilidad, pero mostraron una X roja:

e incluso intentar suspender el movimiento de datos generó un mensaje de error:

Error al suspender el movimiento de datos en la base de datos 'StackExchange.Bycycles.Meta', que reside en la réplica de disponibilidad 'ny-sql03' en el grupo de disponibilidad 'SENetwork_AG'. (Microsoft.SqlServer.Smo)

Información adicional: Se produjo una excepción al ejecutar una instrucción o lote de Transact-SQL. (Microsoft.SqlServer.ConnectionInfo)

La base de datos 'StackExchange.Bycycles.Meta' no se puede abrir debido a archivos inaccesibles o memoria insuficiente o espacio en disco. Consulte el registro de errores de SQL Server para más detalles. (Servidor SQL de Microsoft, error: 945)

Lo verifiqué y los archivos existieron y no tuve ningún problema de permiso. También verifiqué los registros de SQL Server en SSMS en Administración, pero no vi nada sobre la recuperación pendiente ni ningún problema con las dos bases de datos.

En busca de ayuda, encontré dos artículos diferentes que decían que las bases de datos tendrían que restaurarse.

¿Hay alguna forma de reanudar la replicación de datos en un secundario cuando una base de datos está atascada en Recuperación pendiente?

Dado que el servidor había estado desconectado durante un tiempo, pensamos que podría haber salido de la ventana de recuperación de la primaria. Decidimos intentar aplicar los últimos registros de transacciones en la base de datos para ver si eso iniciaría el proceso de recuperación:

-- 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;

Después de ejecutar lo anterior en el servidor secundario para ambas bases de datos, pudieron comenzar a sincronizar nuevamente.

ACTUALIZACIÓN: Tuvimos un problema similar en el que después de una conmutación por error manual de AG, una de las bases de datos en la nueva réplica principal estaba atascada en el modo Sin sincronización (cambiado a Sin sincronización / Recuperación pendiente después de reiniciar SQL Server), y los pasos anteriores funcionaron para resolver eso problema también.

Puede eliminar la base de datos de AAG, en el nodo primario haga una copia de seguridad completa y una copia de seguridad de la transacción, restaure estas dos copias de seguridad en la base de datos del nodo secundario y luego vuelva a agregar la base de datos a la AAG. En este momento puede indicar que el DB del nodo secundario no se está sincronizando, pero solo haciendo lo que se sugiere en la segunda respuesta (Compre la forma en que fue penalizado -2), me refiero a mover el nodo secundario al primario, lo solucionará.

La próxima vez, intente conmutar por error el primario al secundario 'no sincronizado' y vuelva a intentarlo. El secundario ahora debería estar sincronizado.