Kullanılabilirlik Grup veritabanı Eşitleme / Kurtarma Beklemede modunda takılı kaldı

Bir SQL Server 2014 SP1 (12.0.4422.0) örneğinde depolamayı yükseltirken, SQL Server yeniden başlatıldıktan sonra veritabanlarından ikisinin ikincilde başlamaması sorunuyla karşılaştık. Yeni (daha büyük) SSD'leri yüklerken ve veri dosyalarını yeni birime kopyalarken sunucu birkaç saat çevrimdışı kaldı. SQL Server'ı yeniden başlattığımızda, veritabanlarının ikisi hariç tümü yeniden senkronize edilmeye başlandı. Diğer ikisi SSMS'de Senkronizasyon / Kurtarma Beklemede olarak görüntülendi .

Daha önce benzer bir Eşitleme Yapmama / Kurtarma İşleminde sorun yaşadım, durumu Kullanılabilirlik Grupları -> Kullanılabilirlik Veritabanları bölümü altında kontrol ettim ancak kırmızı bir X görüntülediler:

ve hatta Veri Hareketini Askıya Almayı denemek bir hata mesajı verdi:

'SENetwork_AG' kullanılabilirlik grubundaki 'ny-sql03' kullanılabilirlik kopyasında bulunan 'StackExchange.Bycycles.Meta' veritabanındaki veri hareketi askıya alınamadı. (Microsoft.SqlServer.smo)

Ek Bilgi: Bir transact-SQL deyimi veya toplu işlemi yürütülürken kural dışı durum oluştu. (Microsoft.SqlServer.ConnectionInfo)

'StackExchange.Bycycles.Meta' veritabanı erişilemeyen dosyalar veya yetersiz bellek veya disk alanı nedeniyle açılamıyor. Ayrıntılar için SQL Server hata günlüğüne bakın. (Microsoft Sql Server, Hata: 945)

Kontrol ettim ve dosyalar vardı ve herhangi bir izin sorunu yoktu. Ayrıca Yönetim altında SSMS SQL Server günlükleri kontrol, ancak bekleyen kurtarma veya iki veritabanı ile ilgili herhangi bir sorun görmedim.

Yardım arama Veritabanlarının geri yüklenmesi gerektiğini söyleyen iki farklı makale buldum .

Bir veritabanı Kurtarma Beklemede sıkıştığında ikincil veri çoğaltmasını sürdürmenin bir yolu var mı?

Sunucu bir süredir çevrimdışı olduğundan, birincil pencerenin kurtarma penceresinin dışına çıkmış olabileceğini düşündük. Kurtarma işlemine başlayıp başlamayacağını görmek için veritabanına en son işlem günlüklerini uygulamayı denemeye karar verdik :

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

Her iki veritabanı için de yukarıdaki işlemleri ikincil sunucuda çalıştırarak tekrar senkronize etmeye başlayabilirler.

GÜNCELLEME: Manuel AG Yük Devretme işleminden sonra yeni birincil eşlemedeki veritabanlarından birinin Senkronizasyon Yok modunda ( SQL Server yeniden başlatıldıktan sonra Senkronizasyon / Kurtarma Beklemede değil olarak değiştirildi) takıldığı ve yukarıdaki adımların bu sorunu çözmeye çalıştığı benzer bir sorun yaşadık . sorunu da.

DB'yi AAG'den kaldırabilir, birincil düğümde tam yedekleme ve işlem yedeklemesi yapabilir, bu iki yedeklemeyi ikincil düğümün DB'sine geri yükleyebilir, ardından DB'yi AAG'ye tekrar ekleyebilirsiniz. Şu anda İkincil düğüm DB'sinin senkronize olmadığını gösterebilir, ancak sadece ikinci cevapta önerdiğini yapıyor (Cezalandırılma şeklini satın alın -2), Yani İkincil düğümü birincil konuma taşımak, düzeltecektir.

Bir dahaki sefere, birincil 'tekrar senkronize edilmiyor' ikincil ve tekrar başarısız. İkincil artık senkronize edilmelidir.