Banco de dados do Grupo de Disponibilidade bloqueado no modo Não Sincronizando / Recuperação Pendente

Durante a atualização do armazenamento em uma instância do SQL Server 2014 SP1 (12.0.4422.0), encontramos um problema em que dois bancos de dados não iniciavam no secundário após reiniciar o SQL Server. O servidor ficou offline por algumas horas enquanto instalamos novos SSDs (maiores) e copiamos os arquivos de dados para o novo volume. Quando reiniciamos o SQL Server, todos os bancos de dados, exceto dois, começaram a sincronizar novamente. Os outros dois foram exibidos no SSMS como Não sincronizando / recuperação pendente .

Tendo tido um problema semelhante de Não sincronizando / em recuperação antes, verifiquei o status na seção Grupos de disponibilidade -> Bancos de dados de disponibilidade, mas eles exibiram um X vermelho:

e até tentar suspender o movimento de dados gerou uma mensagem de erro:

Falha ao suspender a movimentação de dados no banco de dados 'StackExchange.Bycycles.Meta', que reside na réplica de disponibilidade 'ny-sql03' no grupo de disponibilidade 'SENetwork_AG'. (Microsoft.SqlServer.Smo)

Informações adicionais: Ocorreu uma exceção ao executar uma instrução ou lote transact-SQL. (Microsoft.SqlServer.ConnectionInfo)

O banco de dados 'StackExchange.Bycycles.Meta' não pode ser aberto devido a arquivos inacessíveis ou memória insuficiente ou espaço em disco. Consulte o log de erros do SQL Server para obter detalhes. (Microsoft Sql Server, erro: 945)

Eu verifiquei e os arquivos existiam e não tinham problemas de permissão. Também verifiquei os logs do SQL Server no SSMS em Gerenciamento, mas não vi nada sobre recuperação pendente ou problemas com os dois bancos de dados.

Procurando ajuda, encontrei dois artigos diferentes que diziam que os bancos de dados precisavam ser restaurados.

Existe alguma maneira de retomar a replicação de dados em um secundário quando um banco de dados está preso em Recuperação pendente?

Como o servidor ficou offline por um tempo, pensamos que ele poderia ter saído da janela de recuperação do primário. Decidimos tentar aplicar os logs de transações mais recentes no banco de dados para ver se isso iniciaria o processo de recuperação:

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

Depois de executar o procedimento acima no servidor secundário, nos dois bancos de dados, eles puderam iniciar a sincronização novamente.

ATUALIZAÇÃO: Tivemos um problema semelhante em que, após um failover manual do AG, um dos bancos de dados da nova réplica primária ficou preso no modo Não sincronizando (alternado para Não sincronizando / recuperação pendente após reiniciar o SQL Server) e as etapas acima funcionaram para resolver esse problema. questão também.

Você pode remover o DB do AAG, no nó primário, faça um backup completo e o backup da transação, restaure esses dois backups no DB do nó secundário e adicione novamente o DB ao AAG. No momento, isso pode indicar que o DB do nó secundário não está sincronizando, mas apenas fazendo o que é sugerido na segunda resposta (compre da maneira que foi penalizada -2), quero dizer, movendo o nó secundário para o primário, ele será corrigido.

Da próxima vez, tente fazer o failover do primário para o secundário 'não sincronizando' e vice-versa. O secundário agora deve estar sincronizado.