Baza danych grupy dostępności utknęła w trybie braku synchronizacji / odzyskiwania w toku

Podczas aktualizacji magazynu w wystąpieniu SQL Server 2014 SP1 (12.0.4422.0) napotkaliśmy problem polegający na tym, że dwie bazy danych nie uruchamiałyby się na dodatkowej po zrestartowaniu SQL Server. Serwer był offline przez kilka godzin, podczas gdy instalowaliśmy nowe (większe) dyski SSD i kopiowaliśmy pliki danych na nowy wolumin. Kiedy ponownie uruchomiliśmy SQL Server, wszystkie bazy danych oprócz dwóch zaczęły się ponownie synchronizować. Pozostałe dwa zostały wyświetlone w SSMS jako Nie w trakcie synchronizacji / odzyskiwania .

Miałem wcześniej podobny problem z brakiem synchronizacji / odzyskiwania , sprawdziłem status w sekcji Grupy dostępności -> Bazy danych dostępności, ale wyświetliły czerwony znak X:

a nawet próba zawieszenia przenoszenia danych wygenerowała komunikat o błędzie:

Nie można zawiesić przenoszenia danych w bazie danych „StackExchange.Bycycles.Meta”, która znajduje się w replice dostępności „ny-sql03” w grupie dostępności „SENetwork_AG”. (Microsoft.SqlServer.Smo)

Informacje dodatkowe: Wystąpił wyjątek podczas wykonywania instrukcji lub partii Transact-SQL. (Microsoft.SqlServer.ConnectionInfo)

Nie można otworzyć bazy danych „StackExchange.Bycycles.Meta” z powodu niedostępnych plików lub niewystarczającej ilości pamięci lub miejsca na dysku. Szczegółowe informacje zawiera dziennik błędów programu SQL Server. (Serwer Microsoft Sql, błąd: 945)

Sprawdziłem, a pliki istniały i nie miałem żadnych problemów z uprawnieniami. Sprawdziłem także dzienniki programu SQL Server w SSMS w obszarze Zarządzanie, ale nie widziałem nic o oczekującym odzyskiwaniu ani żadnych problemów z dwiema bazami danych.

W poszukiwaniu pomocy znalazłem dwa różne artykuły, które mówiły, że bazy danych będą musiały zostać przywrócone.

Czy istnieje sposób na wznowienie replikacji danych na serwerze pomocniczym, gdy baza danych utknęła w toku odzyskiwania?

Ponieważ serwer był przez pewien czas w trybie offline, myśleliśmy, że mógł wyjść poza okno odzyskiwania podstawowego. Postanowiliśmy spróbować zastosować najnowsze dzienniki transakcji w bazie danych, aby sprawdzić, czy spowoduje to rozpoczęcie procesu odzyskiwania:

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

Po uruchomieniu powyższego na serwerze pomocniczym dla obu baz danych mogli ponownie rozpocząć synchronizację.

AKTUALIZACJA: Mieliśmy podobny problem polegający na tym, że po ręcznym przełączeniu awaryjnym AG jedna z baz danych na nowej replice podstawowej utknęła w trybie braku synchronizacji (przełączono na tryb braku synchronizacji / odzyskiwania w toku po ponownym uruchomieniu programu SQL Server), a powyższe kroki pracowały, aby rozwiązać ten problem problem również.

Możesz usunąć DB z AAG, w węźle podstawowym wykonaj pełną kopię zapasową i kopię zapasową transakcji, przywróć te dwie kopie zapasowe w DB drugiego węzła, a następnie ponownie dodaj DB do AAG. W tym momencie może to oznaczać, że DB węzła pomocniczego nie synchronizuje się, ale po prostu robi to, co sugeruje druga odpowiedź (Kup sposób, w jaki został ukarany -2), mam na myśli przeniesienie węzła pomocniczego do pierwotnego, to go naprawi.

Następnym razem spróbuj przełączyć serwer główny na „niesynchronizujący” serwer dodatkowy i ponownie. Wtórne powinno teraz zostać zsynchronizowane