SQL Server AlwaysOn ortamlarında otomatik yük devretme sorunlarını giderme

Bu makale, Microsoft SQL Server'da otomatik yük devretme sırasında oluşan sorunları çözmenize yardımcı olur.

Özgün ürün sürümü: SQL Server
Özgün KB numarası: 2833707

Özet

SQL Server AlwaysOn kullanılabilirlik grupları otomatik yük devretme için yapılandırılabilir. Birincil çoğaltmayı barındıran SQL Server örneğinde bir sistem durumu sorunu algılanırsa, birincil rol otomatik yük devretme ortağına (ikincil çoğaltma) geçirilebilir. Ancak, ikincil çoğaltma her zaman birincil role geçirilemiyor. Bazı durumlarda yalnızca role geçirilebilir RESOLVING . Bu durumda, birincil çoğaltma sağlıklı duruma dönmediği sürece hiçbir çoğaltma birincil role sahip olmaz. Ayrıca kullanılabilirlik veritabanlarına erişilemez.

Bu makalede başarısız otomatik yük devretmenin bazı yaygın nedenleri listelenir ve bu hataların nedenini tanılamak için izleyebileceğiniz adımlar açıklanır.

Otomatik yük devretmenin başarıyla tetiklendiğinde ortaya çıkarsa belirtiler

Birincil çoğaltmayı barındıran SQL Server örneğinde otomatik yük devretme tetiklendiğinde, ikincil çoğaltma role ve ardından birincil role geçiş gerçekleştirirRESOLVING. İşlem başarılı olsa da, hata girişleri aşağıdaki metne benzeyen SQL Server günlük raporuna kaydedilir:

The state of the local availability replica in availability group '\<Group name>' has changed from 'RESOLVING_NORMAL' to 'PRIMARY_PENDING'  
The state of the local availability replica in availability group '\<Group name>' has changed from 'PRIMARY_PENDING' to 'PRIMARY_NORMAL'

Otomatik yük devretme başarısız olursa belirtiler

Otomatik yük devretme olayı başarılı olmazsa, ikincil çoğaltma birincil role başarıyla geçiş yapmaz. Bu nedenle, kullanılabilirlik çoğaltması bu çoğaltmanın bir RESOLVING durumda olduğunu bildirir. Ayrıca, kullanılabilirlik veritabanları durumlarını NOT SYNCHRONIZING bildirir ve uygulamalar bu veritabanlarına erişemez.

Örneğin, aşağıdaki görüntüde SQL Server Management Studio otomatik yük devretme işlemi ikincil çoğaltmayı birincil role geçiremediğinden ikincil çoğaltmanın bir durumda olduğunu RESOLVING bildirir.

Aşağıdaki bölümlerde otomatik yük devretmenin başarılı olmamasının çeşitli olası nedenleri ve her nedenin nasıl tanılanabileceği açıklanmaktadır.

Olay 1: "Belirtilen DönemdeKi En Fazla Hata Sayısı" değeri tükendi

Kullanılabilirlik grubu, Belirtilen Dönem özelliğindeki En Fazla Hata sayısı gibi Windows kümesi kaynak özelliklerine sahiptir. Bu özellik, birden çok düğüm hatası oluştuğunda kümelenmiş kaynağın süresiz taşınmasını önlemek için kullanılır.

Başarısız yük devretmenin nedeninin bu olup olmadığını araştırmak ve tanılamak için Windows küme günlüğünü (Cluster.log) gözden geçirin ve ardından özelliği denetleyin.

1. Adım: Windows küme günlüğündeki verileri gözden geçirme (Cluster.log)

1. Birincil çoğaltmayı barındıran küme düğümünde Windows küme günlüğünü oluşturmak için Windows PowerShell kullanın. Bunu yapmak için, birincil çoğaltmayı barındıran SQL Server örneğindeki yükseltilmiş bir PowerShell penceresinde aşağıdaki cmdlet'i çalıştırın:

   Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
   

   

   [! NOTLAR]

   • -TimeSpan 15 Bu adımdaki parametre, tanılanan sorunun önceki 15 dakika içinde oluştuğu varsayılır.
   • Varsayılan olarak, günlük dosyası %WINDIR%\cluster\reports içinde oluşturulur.

2. Windows küme günlüğünü gözden geçirmek için Not Defteri'nde Cluster.log dosyasını açın.

3. Not Defteri'nde Bul'u Düzenle'yi> seçin ve dosyanın sonundaki "failoverCount" dizesini arayın. Sonuçlarda, aşağıdaki iletiye benzer bir ileti bulmanız gerekir:

   Grup <kaynak adı>, yük devretmecount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2 yük devretmesi değil

   

2. Adım: Belirtilen Dönem özelliğinde En Fazla Hata Olup Olmadığını Denetleyin

1. Yük Devretme Kümesi Yöneticisi'ni başlatın.

2. Gezinti bölmesinde Roller'i seçin.

3. Roller bölmesinde, kümelenmiş kaynağa sağ tıklayın ve özellikler'i seçin.

4. Yük Devretme sekmesini seçin ve Belirtilen Dönem değerindeki En Fazla Hata'yı seçin.

   

   Not

   Varsayılan davranış, kümelenmiş kaynağın altı saat içinde üç kez başarısız olması durumunda başarısız durumda kalması gerektiğini belirtir. Kullanılabilirlik grubu için bu, çoğaltmanın durumunda bırakıldığını RESOLVING gösterir.

Sonuç

Günlüğü analiz ettikten sonra, 3olan yük devretmeSayısı değerinin 2'nincomputedFailoverThreshold değerinden büyük olduğunu fark edebilirsiniz. Bu nedenle, Windows kümesi kullanılabilirlik grubu kaynağının yük devretme iş ortağına yük devretme işlemini tamamlayamaz.

Çözüm

Bu sorunu çözmek için Belirtilen Dönem değerindeki En Fazla Hata Sayısını artırın.

Olay 2: Yetersiz NT Yetkilisi\SYSTEM hesabı izinleri

SQL Server Veritabanı Altyapısı kaynak DLL'i, sistem durumunu izlemek için ODBC kullanarak birincil çoğaltmayı barındıran SQL Server örneğine bağlanır. Bu bağlantı için kullanılan oturum açma kimlik bilgileri yerel SQL Server NT AUTHORITY\SYSTEM oturum açma hesabıdır. Varsayılan olarak, bu yerel oturum açma hesabına aşağıdaki izinler verilir:

• Herhangi Bir Kullanılabilirlik Grubunu Değiştirme
• SQL'e Bağlanma
• Sunucu durumunu görüntüleme

NT AUTHORITY\SYSTEM Oturum açma hesabında otomatik yük devretme ortağında (ikincil çoğaltma) bu izinlerden herhangi biri yoksa, otomatik yük devretme gerçekleştiğinde SQL Server sistem durumu algılamayı başlatamaz. Bu nedenle, ikincil çoğaltma birincil role geçiş yapamaz. Nedeninin bu olup olmadığını araştırmak ve tanılamak için Windows küme günlüğünü gözden geçirin. Bunu yapmak için şu adımları uygulayın:

1. Küme düğümünde Windows küme günlüğünü oluşturmak için Windows PowerShell kullanın. Bunu yapmak için, birincil role geçiş yapmayan ikincil çoğaltmayı barındıran SQL Server örneğinde yükseltilmiş bir PowerShell penceresinde aşağıdaki cmdlet'i çalıştırın:

   Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
   

   

2. Windows küme günlüğünü gözden geçirmek için Not Defteri'nde Cluster.log dosyasını açın.

3. Aşağıdaki metne benzeyen hata girdisini bulun:

   Tanılama komutu çalıştırılamadı. Kullanıcının bu eylemi gerçekleştirme izni yok.

   

Sonuç

Cluster.log dosyası, SQL Server tanılama komutunu çalıştırdığında bir izin sorunu olduğunu bildirir. Bu örnekte hata, otomatik yük devretme çiftinin ikincil çoğaltmasını barındıran SQL Server örneğindeki oturum açma hesabından Sunucu durumunu görüntüle izninin NT AUTHORITY\SYSTEM kaldırılmasından kaynaklanmıştır.

Çözüm

Bu sorunu çözmek için, SQL Server Veritabanı Altyapısı kaynak DLL'sinin NT AUTHORITY\SYSTEM sistem durumu algılaması için oturum açma hesabına yeterli izinler verin.

Olay 3: Kullanılabilirlik veritabanları EŞITLENMİ DURUMDA değil

Otomatik olarak yük devretmek için, kullanılabilirlik grubunda tanımlanan tüm kullanılabilirlik veritabanları birincil çoğaltma ile ikincil çoğaltma arasında bir SYNCHRONIZED durumda olmalıdır. Otomatik yük devretme gerçekleştiğinde, veri kaybı olmadığından emin olmak için bu eşitleme koşulunun karşılanması gerekir. Bu nedenle, kullanılabilirlik grubundaki bir kullanılabilirlik veritabanı eşitleme veya NOT SYNCHRONIZED durumdaysa, otomatik yük devretme ikincil çoğaltmayı birincil role başarıyla geçirmez.

Otomatik yük devretme için gerekli koşullar hakkında daha fazla bilgi için Bkz. Otomatik Yük Devretme için gerekli koşullar ve Zaman Uyumlu işleme çoğaltmalarıYük Devretme ve Yük Devretme Modlarının (AlwaysOn Kullanılabilirlik Grupları) iki ayar bölümünü destekler.

Başarısız yük devretmenin nedeninin bu olup olmadığını araştırmak ve tanılamak için SQL Server hata günlüğünü gözden geçirin. Aşağıdaki metne benzer bir hata girdisi bulmanız gerekir:

Bir veya daha fazla veritabanı eşitlenmemiş veya kullanılabilirlik grubuna katılmamış.

Kullanılabilirlik veritabanlarının SYNCHRONIZED durumunda olup olmadığını denetlemek için şu adımları izleyin:

1. İkincil çoğaltmaya bağlanın.

2. Yük devretme yapmayan is_failover_ready kullanılabilirlik grubundaki tüm kullanılabilirlik veritabanlarının değerini denetlemek için aşağıdaki SQL betiğini çalıştırın.

   Not

   Kullanılabilirlik veritabanlarından herhangi biri için sıfır değeri otomatik yük devretmeyi engelleyebilir. Bu değer kullanılabilirlik veritabanının olmadığını SYNCHRONIZEDgösterir.

   SELECT database_name, is_failover_ready FROM sys.dm_hadr_database_replica_cluster_states WHERE replica_id IN (SELECT replica_id FROM sys.dm_hadr_availability_replica_states)
   

   

Sonuç

Kullanılabilirlik grubunun başarılı bir otomatik yük devretmesi, tüm kullanılabilirlik veritabanlarının SYNCHRONIZED durumunda olmasını gerektirir. Kullanılabilirlik modları hakkında daha fazla bilgi için bkz . AlwaysOn kullanılabilirlik gruplarında kullanılabilirlik modları.

Olay 4: İkincil çoğaltmadaki (hedef birincil) istemci protokolleri için "Protokol Şifrelemesini Zorla" yapılandırması seçilir ancak çoğaltma şifreleme için yapılandırılmamış

Yük devretme sırasında, birincil sunucu bir sistem durumu sorunu algıladığında, yük devretme ortağındaki küme DLL'i (ikincil çoğaltma) sistem durumu izlemeyi başlatmak için yerel çoğaltmaya bağlanmaya çalışır. Bu, birincil role geçişin bir parçasıdır. İkincil çoğaltma şifreleme için yapılandırılmamışsa ancak protokol şifrelemesini zorla ayarı yanlışlıkla istemci yapılandırmasında ayarlanmışsa, bağlantı başarısız olur ve yük devretme gerçekleşemez.

Bu yapılandırmayı denetlemek için:

1. SQL Server Yapılandırma Yöneticisi'ni başlatın.
2. Sol bölmede SQL Yerel İstemcisi 11.0 Yapılandırması'na sağ tıklayın ve özellikler'i seçin.
3. İletişim kutusunda Protokol Şifrelemesini Zorla ayarını işaretleyin. Evet olarak ayarlandıysa, değeri Hayır olarak değiştirin.
4. Yük devretmeyi yeniden test edin.

Sonuç

SQL Server Always On sistem durumu izlemesi, SQL Server durumunu izlemek için yerel bir ODBC bağlantısı kullanır. Protokol Şifrelemesini Zorla SQL Server Yapılandırma Yöneticisi İstemci Yapılandırması bölümünde yalnızca SQL Server kendisi SQL Server SQL Server Yapılandırma Yöneticisi'de Şifrelemeleri Zorlamak üzere yapılandırılmışsa etkinleştirilmelidir Ağ Yapılandırması bölümü. Daha fazla bilgi için bkz . Veritabanı Altyapısına şifreli bağlantıları etkinleştirme.

Olay 5: İkincil çoğaltma veya düğümdeki performans sorunları Always On sistem durumu denetimlerinin başarısız olmasına neden oluyor

Birincil çoğaltmadan ikincil çoğaltmaya yük devretmeden önce, SQL Server Veritabanı Altyapısı kaynak DLL'i çoğaltmanın durumunu belirlemek için ikincil çoğaltmaya bağlanır. İkincil çoğaltmadaki performans sorunları nedeniyle bu bağlantı başarısız olursa otomatik yük devretme gerçekleşmez.

Nedeninin bu olup olmadığını araştırmak ve tanılamak için şu adımları izleyin:

1. "Sunucu bağlantısını açma gecikmesi nedeniyle oturum açma işlemi tamamlanamadı" hata iletisini denetlemek için ikincil çoğaltmadaki Küme günlüğünü gözden geçirin.

   0000110c.00002bcc::2020/08/06-01:17:54.943 INFO  [RCM] move of group AOCProd01AG from CO2ICMV3SQL09(1) to CO2ICMV3SQL10(2) of type MoveType::Manual is about to succeed, failoverCount=3, lastFailoverTime=2020/08/05-02:08:54.524 targeted=true 
   00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]Unable to complete login process due to delay in opening server connection (0) 
   00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Could not connect to SQL Server (rc -1) 
   00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] SQLDisconnect returns following information 
   00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08003] [Microsoft][ODBC Driver Manager] Connection not open (0) 
   00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Failed to connect to SQL Server 
   00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RHS] Online for resource AOCProd01AG failed. 
   

   Bu durum, yük devretmenin meşgul bir iş yüküne sahip SQL Server ikincil çoğaltmaya yapılması durumunda ortaya çıkabilir. Bu, SQL Server HADR sistem durumu bağlantı isteği girişimine yanıtını geciktirebilir ve başarılı bir yük devretme girişimini engelleyebilir.

2. Sistem zamanlayıcıları üzerinde baskı olup olmadığını belirlemek için SQL Server Management Studio kullanarak ikincil çoğaltmada aşağıdaki betiği çalıştırın:

   USE MASTER 
   GO  
   WHILE 1=1 
   BEGIN 
   PRINT convert(varchar(20), getdate(),120) 
   DECLARE @max INT; 
   SELECT @max = max_workers_count 
   FROM sys.dm_os_sys_info; 
   SELECT GETDATE() AS 'CurrentDate',  
          @max AS 'TotalThreads',  
          SUM(active_Workers_count) AS 'CurrentThreads',  
          @max - SUM(active_Workers_count) AS 'AvailableThreads',  
          SUM(runnable_tasks_count) AS 'WorkersWaitingForCpu',  
          SUM(work_queue_count) AS 'RequestWaitingForThreads' 
          --SUM(current_workers_count) AS 'AssociatedWorkers' 
   FROM sys.dm_os_Schedulers 
   WHERE STATUS = 'VISIBLE ONLINE'; 
   wait for delay '0:0:15' 
   END
   

   Yukarıdaki sorgunun örnek çıkışı aşağıda verilmiştir:

   CurrentDate	TotalThreads	CurrentThreads	AvailableThreads	WorkersWaitingForCpu	RequestWaitingForThreads
   2020-10-06 01:27:01.337	1216	361	855	33	0
   2020-10-06 01:27:08.340	1216	1412	-196	22	76
   2020-10-06 01:27:15.340	1216	1304	-88	2	161
   2020-10-06 01:27:22.340	1216	1242	-26	21	185
   2020-10-06 01:27:29.343	1216	1346	-130	19	476
   2020-10-06 01:27:36.350	1216	1350	-134	9	630
   2020-10-06 01:27:43.353	1216	1346	-130	13	539
   2020-10-06 01:27:50.360	1216	1378	-162	5	328
   2020-10-06 01:27:57.360	1216	197	1019	0	0

   için WorkersWaitingForCpu bildirilen yüksek değerler ve RequestWaitingForThreads zamanlama çekişmesi oluştuğunu ve SQL Server geçerli iş yüküne zamanında hizmet verilemeyeceklerini gösterir.

Çözüm

Bu sorunla karşılaşırsanız, ikincil çoğaltmadaki iş yükünü yeniden dengeleyin veya bu iş yüklerini çalıştıran bilgisayarlarda işleme gücünü artırmayı (işlemcileri eklemeyi) düşünün.

Diğer başarısız yük devretme olaylarının sorunlarını giderme

Yük devretme sırasında yeni birincil çoğaltmanın durumunu izlemek için AlwaysOn sistem durumu izlemesini birincil role geçiş yapan SQL Server örneğine yerel olarak bağlamanız gerekir.

Bu makalede açıklanan daha yaygın nedenlere ek olarak, bu bağlantı girişiminin başarısız olmasının birçok başka nedeni de vardır. Başarısız bir yük devretme girişimini daha fazla araştırmak için yük devretme ortağındaki Küme günlüğünü gözden geçirin (yük devredemediğiniz çoğaltma):

1. Küme düğümünde Windows Kümesi günlüğünü oluşturmak için Windows PowerShell kullanın. Bunu yapmak için, birincil role geçiş yapmayan ikincil çoğaltmayı barındıran SQL Server örneğinde yükseltilmiş bir PowerShell penceresinde aşağıdaki cmdlet'i çalıştırın. Etkinliğin son 60 dakikası için bir Küme günlüğü oluşturulur.

   Get-ClusterLog -Node <SQLServerNodeName> -TimeSpan 60
   

2. Windows Kümesi günlüğünü gözden geçirmek için Cluster.log dosyasını Not Defteri'nde açın.

3. Başarısız yük devretme olayı sırasında denk gelen "SQL Server bağlan" dizesini arayın.

4. Oturum açma olayıyla ilgili olayları ilişkilendirmek için iş parçacığı kimliğini kullanarak sonraki oturum açma iletilerini gözden geçirin (aşağıdaki ekran görüntüsüne bakın). Aşağıdaki örnekte "SQL Server bağlan" araması gösterilmektedir. Bağlantı girişiminin neden başarısız olduğunu açıklayan diğer tanılamaları bulmak için iş parçacığı kimliğini (sol taraf) kullanmayı da gösterir.

   

Aşağıdaki örneklerde yeni birincil çoğaltmaya yönelik bağlantı hataları gösterilir.

Örnek Küme 1

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: No client protocols are enabled and no protocol was specified in the connection
string [xFFFFFFFF]. (268435455)

Çözüm

SQL Server Yapılandırma Yöneticisi başlatın ve SQL Yerel İstemci Yapılandırması için İstemci Protokolleri altında Paylaşılan Bellek veya TCP/IP'nin etkinleştirildiğini doğrulayın.

Örnek Küme 2

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: Server doesn't support requested protocol [xFFFFFFFF]. (268435455)

Çözüm

SQL Server Yapılandırma Yöneticisi başlatın ve SQL Yerel İstemci Yapılandırması için İstemci Protokolleri altında Paylaşılan Bellek veya TCP/IP'nin etkinleştirildiğini doğrulayın.

Örnek Küme 3

000010b8.00001764::2020/12/02-16:52:49.808 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot alter the availability
group 'ag', because it does not exist or you do not have permission. (15151)
000010b8.00000fd0::2020/12/02-17:01:14.821 ERR [RES] SQL Server Availability Group: [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]The user does not have permission to perform this action. (297)
000010b8.00001838::2020/12/02-17:10:04.427 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user
'SQLREPRO\NODE2$'. Reason: The account is disabled. (18470)

Çözüm

Olay 2: Yetersiz NT Yetkilisi\SYSTEM hesabı izinlerini gözden geçirin.