500 veritabanına sahip SQL Server 2017 - CU9'dan bu yana sık sık AG bağlantısı kesiliyor

Herkese merhaba ve yardımlarınız için şimdiden teşekkür ederiz. SQL Server 2017 Kullanılabilirlik Gruplarıyla sorunlar yaşıyoruz.

Arka fon

Şirket perakende B2B arka uç yazılımdır. Yaklaşık 500 tek kiracı veritabanı ve tüm kiracılar tarafından kullanılan 5 paylaşılan veritabanı. İş yükü karakteristiği çoğunlukla okunur ve veritabanlarının çoğunluğu çok düşük aktiviteye sahiptir.

Ortak yerde barındırılan fiziksel üretim sunucuları yakın zamanda paylaşılan bir SAN / FCI yapılandırmasında Windows Server 2012'de SQL Server 2014 Enterprise'dan, 2 soket / 32 çekirdekli / 768 GB RAM ve yerelde Windows Server 2016'da SQL Server 2017 Enterprise'a yükseltildi. AlwaysOn AG kullanan SSD sürücüler. AG trafiği, çapraz kablo bağlantılı özel 10G NIC bağlantı noktaları kullanır.

Gereksinimleri, tüm veritabanlarının yük devretmesi için hepsini tek bir AG'ye koymak zorundaydı. Aynı sunucudaki tek, okunamayan bir eşzamanlı çoğaltmadır.

Yeni sunucular Haziran 2018'den beri üretilmektedir. En son CU (o sırada CU7) ve windows güncellemeleri yüklendi ve sistem iyi çalışıyordu. Yaklaşık bir ay sonra, sunucuları 7 PB'den 9 PB'ye güncelledikten sonra, öncelik sırasına göre listelenen aşağıdaki zorlukları fark etmeye başladılar.

Sunucuları SQL Sentry kullanarak izliyoruz ve hiçbir fiziksel darboğaz gözlemlemedik. Tüm önemli göstergeler iyi görünüyor. CPU ortalama% 20, G / Ç süreleri tipik olarak 1 ms'den az, RAM tam olarak kullanılmıyor ve ağ <% 1.

Zorluklar

Yük devretme işleminden sonra belirtiler iyileşiyor gibi görünüyor, ancak hangi sunucunun birincil olduğuna bakılmaksızın birkaç gün içinde geri geliyor - belirtiler her iki sunucuda da aynı.

1. Sporadik istemci zaman aşımları ve gibi bağlantı hataları

   ... bağlantı kurulurken hata oluştu ...

   veya

   Yürütme zaman aşımı süresi doldu

   Bazen bunlar 40 saniyeye kadar devam eder ve sonra düşer.

2. İşlem günlüğü yedekleme işinin tamamlanması öncekinden 10 kat daha uzun sürer. Önceden 500 veritabanının günlüklerini yedeklemek 2-3 dakika sürüyordu, şimdi 15-25 sürüyor. Yedeklemenin kendisinin iyi bir iş hacmiyle iyi çalıştığını doğruladık. Ancak, bir günlük yedeklemesini tamamladıktan ve sonraki günlüğü başlatmadan önce küçük bir gecikme olur. çok düşük başlar, ancak bir veya iki gün içinde 2-3 saniyeye ulaşır. 500 veritabanı ile çarpılır ve fark vardır.

3. Bazen, rastgele görünen bazı veritabanları manuel yük devretme sonrasında "Senkronize edilmiyor" durumunda takılı kalıyor. Bunu çözmenin tek yolu, ikincil çoğaltmada SQL Server hizmetini yeniden başlatmak veya kaldırmak ve bu veritabanlarını AG'ye yeniden eklemektir.

4. CU10 tarafından getirilen başka bir sorun (ve CU11'de çözülmedi): master.sys.databases öğesinde engelleme ve hatta ikincil çoğaltma için SSMS nesne gezgini kullanamama durumunda ikincil zaman aşımına bağlantılar. Kök neden aşağıdaki sorguyu veren Microsoft SQL Server VSS yazıcı tarafından engelleniyor gibi görünüyor:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases

Gözlemler

Sigara tabancasını hata günlüklerinde bulduğuma inanıyorum. Hata günlükleri, 'yalnızca bilgi amaçlı' olarak etiketlenen AG iletileriyle doludur, ancak normal görünmüyor gibi görünmektedir ve sıklıklarının uygulama hatalarıyla çok güçlü bir korelasyonu vardır.

Hatalar birkaç tiptedir ve diziler halinde gelir:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• AlwaysOn Kullanılabilirlik Çoğaltma kimliğine sahip 'DB' çoğaltma çoğaltması için birincil veritabanı 'XYZ' için ikincil veritabanı ile bağlantı kesildi: {GUID}. Bu yalnızca bilgi amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.

• AlwaysOn Kullanılabilirlik Çoğaltma kimliğine sahip 'DB' çoğaltma çoğaltması için birincil veritabanı 'ABC' için oluşturulan ikincil veritabanı ile bağlantı grupları: {GUID}. Bu yalnızca bilgi amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.

Bazı günler on binlerce kişi var.

Bu makalede , SQL 2016'da aynı tür hata dizisi anlatılmakta ve burada anormal olduğu belirtilmektedir. Bu aynı zamanda yük devretme sonrasındaki 'senkronize olmayan' olgusunu da açıklar. Tartışılan konu 2016 içindi ve bu yılın başlarında bir CU'da düzeltildi. ancak, AG zaten kurulmuş olduğu için burada olması gerekmeyen otomatik başlangıç ​​tohumlama mesajlarına referanslar dışında, ilk 2 mesaj türü için bulabildiğim tek ilgili referanstır.

İşte PRIMARY'da tür başına> 10K hata içeren günler için geçen hafta günlük hataların bir özeti (ikincil gösteriler 'birincil ile bağlantı kesiliyor ...'):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Ayrıca zaman zaman "garip" mesajlar da görüyoruz:

Yansıtma oturumu veya kullanılabilirlik grubu rol eşitlemesi nedeniyle başarısız olduğu için kullanılabilirlik grubu veritabanı "DB", rolleri "SECONDARY" yerine "SECONDARY" olarak değiştiriyor. Bu yalnızca bilgi amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.

... "SEKONDER" den "ÇÖZME" ye kadar değişen bir dizi devlet arasında.

Manuel yük devretme işleminden sonra, sistem bu türlerden tek bir mesaj olmadan birkaç gün sürebilir ve aniden, belirgin bir neden olmadan, bir kerede binlerce tane alırız, bu da sunucunun yanıt vermemesine ve uygulamaya neden olur. bağlantı zaman aşımları. Bazı uygulamaları bir yeniden deneme mekanizması içermediğinden bu nedenle kritik bir hatadır ve bu nedenle veri kaybedebilir. Böyle bir hata patlaması meydana geldiğinde, aşağıdaki bekleme türü gökyüzü-rokettir. Bu, AG'nin tüm veritabanlarıyla bağlantısını bir anda kaybetmiş gibi göründükten hemen sonraki beklemeleri gösterir:

Yaklaşık 30 saniye sonra, beklemeler açısından her şey normale döner, ancak AG mesajları, hata günlüklerini değişen oranlarda ve günün farklı saatlerinde, yoğun olmayan saatler de dahil olmak üzere rastgele görünen sürelerle doldurmaya devam eder. Bu hata patlamaları sırasında iş yükündeki eşzamanlı artış, elbette işleri daha da kötüleştirir. Yalnızca birkaç veritabanının bağlantısı kesilirse, bağlantı kendiliğinden yeterince hızlı çözüldüğü için bağlantı zaman aşımına neden olmaz.

Sorunu başlatan gerçekten CU9 olduğunu doğrulamaya çalıştık, ancak her iki düğümü de yalnızca 9 CU'ya indirebildik. Her iki düğümü de CU8'e düşürme girişimleri, düğümün günlükte aynı hatayı gösteren 'Çözümleniyor' durumunda takılı kalmasına neden oldu:

Her zaman Açık kullanılabilirlik grubunun karşılık gelen kaynak kimliğine sahip kalıcı yapılandırması okunamıyor '…. Kalıcı yapılandırma, birincil kullanılabilirlik çoğaltmasını barındıran daha yüksek sürüm bir SQL Server tarafından yazılır. Yerel kullanılabilirlik çoğaltmasının ikincil bir çoğaltma olmasına izin vermek için yerel SQL Server örneğini yükseltin.

Bu, her iki düğümü de aynı anda CU8'e düşürmek için çalışmama süresini tanıtmamız gerektiği anlamına gelir. Bu ayrıca AG'de yaşadıklarımızı açıklayabilecek bazı önemli güncellemeler olduğunu göstermektedir.

Zaten max_worker_threads değerini varsayılan olarak 0'dan ( bu makaleye dayanarak kutumuzda = 960 ) ayarlamayı, hatalar üzerinde gözlenen bir etki olmadan 2.000'e kadar kademeli olarak ayarlamayı denedik .

Bu AG bağlantı kesintilerini çözmek için ne yapabiliriz? Dışarıda benzer sorunlar yaşayan var mı? Bir AG'de çok sayıda veritabanına sahip diğer kişiler, SQL hata günlüğünde CU9 veya CU8 ile başlayan benzer iletileri görebilir mi?

Herhangi bir yardım için şimdiden teşekkürler!

Güncelleme:

1. Sık Kullanılabilirlik Grubu bağlantı kesimlerinin CU9 tarafından getirilen bir gerileme olduğu doğrulandı ve CU12 yüklendikten sonra çözüldü.

2. İkincil çoğaltmadaki engelleme sorunlarının, CU10'da tanıtılan VSS yazıcı kodunda yapılan bir güncellemeyle ilgili bir sorun olduğu doğrulandı. Umarım CU 13'te çözülecektir. Geçici çözüm, VSS yazıcı DLL'lerini Pre-CU10 DLL'leri ile manuel olarak değiştirmek ...

   BEGIN RANT-SACTION;

   Ne yazık ki, Microsoft sürekli olarak sadece Windows 10 güncellemelerini değil, SQL Server gibi kurumsal görev kritik yazılımlarını da düzgün bir şekilde başarısız hale getirmektedir.

   Daha önceki hizmet paketleri stratejisini çok tercih ettim, en azından yarı pişmiş güncellemelerin dikkatsiz yayınlanmasıyla müşterilere üretim krizi ve veri kaybı yaşamadan önce bunları düzgün bir şekilde test etmek için yeterli zamanları vardı.

   COMMIT RANT-SACTION;

İşçi konularını kontrol ettiniz mi? Normalde her zaman çalışmak için daha fazla işçi iplik kullanın ve nornally varsayılan değer yeterli değil. Ben her zaman üzerinde 600 veritabanları ile aynı sorunu vardı, Bu yüzden örnek parametre üzerinde daha fazla iş parçacığı eklemek ve bu bizim sorunumuzu düzeltti. Bu yardımcı olur umarım!