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 atabileceğiniz adımlar açıklanır.

Otomatik yük devretmenin başarıyla tetiklendiğinde görülen 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çirilir RESOLVING . İşlem başarılı olsa da, SQL Server günlük raporunda aşağıdaki metne benzer hata girişleri günlüğe 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'

Not

İkincil çoğaltma, bir RESOLVING_NORMAL durumdan bir duruma PRIMARY_NORMAL başarıyla geçirildi.

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 RESOLVING durumda olduğunu 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çıklanmıştır.

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

Kullanılabilirlik grubu, Belirtilen Dönemdeki En Fazla Hata sayısı özelliği 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ğini 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 ardından 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 yapılmadı

   

2. Adım: Belirtilen Dönem özelliğinde En Fazla Hata Sayısı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ğerinde En Fazla Hata Sayısı'nı 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 3 olan failoverCount değerinin 2'nin computedFailoverThreshold 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ünürlük

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

Not

Bu değerin artırılması sorunu çözmeyebilir. Kullanılabilirlik grubunun kısa bir süre içinde birçok kez başarısız olmasına neden olan daha kritik bir sorun olabilir. Varsayılan olarak, bu süre 15 dakikadır. Bu değerin artırılması, kullanılabilirlik grubunun daha fazla kez başarısız olmasına ve başarısız durumda kalmasına neden olabilir. Otomatik yük devretmenin neden devam ettiğini belirlemek için agresif sorun giderme kullanmanızı öneririz.

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:

• Kullanılabilirlik Grubunu Değiştirme
• SQL'i bağlama
• Sunucu durumunu görüntüleme

NT AUTHORITY\SYSTEM Oturum açma hesabında otomatik yük devretme iş 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çemez. Nedeninin bu olup olmadığını araştırmak ve tanılamak için Windows küme günlüğünü gözden geçirin. Bunun için aşağıdaki adımları izleyin:

1. Küme düğümünde Windows küme günlüğünü oluşturmak için Windows PowerShell'i 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ştirmek için 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 kaynaklandı.

Çözünürlük

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 devretme yapmak 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şulu karşılanmalıdır. 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, Otomatik Yük Devretme için gerekli koşullar bölümüne bakın 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 benzeyen 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 iş ortağındaki (ikincil çoğaltma) küme DLL'i 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ı istemci yapılandırmasında yanlışlıkla ayarlandıysa, 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 İstemci 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 izleme, SQL Server sistem 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'ın kendisi SQL Server Ağ Yapılandırması bölümündeki SQL Server Yapılandırma Yöneticisi Şifrelemeleri Zorlamak üzere yapılandırılmışsa etkinleştirilmelidir. 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. 
   

   Yük devretme, meşgul bir iş yüküne sahip olan bir SQL Server ikincil çoğaltmasına yapılırsa bu durum oluşabilir. Bu, SQL Server'ın 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'yu 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 çıktısı aşağıda verilmiştir:

   GeçerliTarih	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'ın geçerli iş yüküne zamanında hizmet veremezseniz gösterir.

Çözünürlük

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şlem 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ş yapılan SQL Server örneğine yerel olarak bağlamanız gerekir.

Bu makalede ele alınan 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ü (yük devredemediğiniz çoğaltma) gözden geçirin:

1. Küme düğümünde Windows Kümesi günlüğü 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. Son 60 dakikalık etkinlik için bir Küme günlüğü oluşturulur.

   Get-ClusterLog -Node <SQLServerNodeName> -TimeSpan 60
   

2. Windows Küme günlüğünü gözden geçirmek için not defteri'nde Cluster.log dosyasını açın.

3. Başarısız yük devretme olayı sırasında denk gelen "SQL Server'a 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'a Bağlan" araması gösterilmektedir. Ayrıca 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österilmektedir.

Ö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ünürlük

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ünürlük

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ünürlük

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