Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Ağustos 2017  >>
PaSaÇaPeCuCuPa
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Keywords

SQL Server 2012 AlwaysOn availability group kuruluşu yaparken aşağıdaki hatayı alaiblirsiniz.

Msg 41131, Level 16, State 0, Line 2
Failed to bring availability group 'availability_group' online. The operation timed out. Verify that the local Windows Server Failover Clustering (WSFC) node is online. Then verify that the availability group resource exists in the WSFC cluster. If the problem persists, you might need to drop the availability group and create it again.

[more]

Aynı Availability group kuruluşunu TSQL ile yaparsanız hata şu şekilde olacaktır.

Msg 41066, Level 16, State 0, Line 1
Cannot bring the Windows Server Failover Clustering (WSFC) resource (ID '8d0cd20e-f78b-413e-b4e4-b293e52630bd') online (Error code 5018).  The WSFC service may not be running or may not be accessible in its current state, or the WSFC resource may not be in a state that could accept the request.  For information about this error code, see "System Error Codes" in the Windows Development documentation.
Msg 41160, Level 16, State 0, Line 1
Failed to designate the local availability replica of availability group 'AGContoso1' as the primary replica.  The operation encountered SQL Server error 41066 and has been terminated.  Check the preceding error and the SQL Server error log for more details about the error and corrective actions.
Msg 41152, Level 16, State 2, Line 1
Failed to create availability group 'AGContoso1'.  The operation encountered SQL Server error 41160 and has been rolled back.  Check the SQL Server error log for more details.  When the cause of the error has been resolved, retry CREATE AVAILABILITY GROUP command.

SQL Server Error Log’da ilgili hatalara baktığınızda ise şu mesajları göreceksiniz;

2013-06-26 20:43:26.86 spid59      The state of the local availability replica in availability group 'AGContoso1' has changed from 'NOT_AVAILABLE' to 'RESOLVING_NORMAL'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log.
2013-06-26 20:43:27.01 Logon       Error: 18456, Severity: 14, State: 5.
2013-06-26 20:43:27.01 Logon       Login failed for user 'CORP\CONTOSOSQL2$'. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]
2013-06-26 20:43:27.05 spid59      The state of the local availability replica in availability group 'AGContoso1' has changed from 'RESOLVING_NORMAL' to 'NOT_AVAILABLE'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log.

Hatanın sebebi [NT AUTHORITY\SYSTEM] account’unun SQL Server login listesinde bulunmamasıdır. Bu account’u aşağıdaki makalede anlatıldığı gibi tüm Availability Group replica’larda create edersiniz yukarıdaki hatalardan kurtulabilirsiniz.

http://support.microsoft.com/kb/2847723/en-us

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


12 Eylül 2012 Çarşamba günü yapacağım webcast’in duyurusunu yapmak istiyorum.

SQL Server 2012 ile beraber gelen yeni High Availability çözümü olan AlwaysOn üzerine konuşacağımız bu webcast 10:00’da başlayacak.

Kayıt olmak için aşağıdaki linki kullanabilirsiniz.

Başlangıcı: 12 Eylül 2012 Çarşamba 10:00
Saat dilimi: (GMT+02:00)
Süre: 1 saat 30 dakika
Kayıt Linki : https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032527839&Culture=TR-TR&community=0

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bildiğiniz gibi 8 Mart 2012 tarihinde SQL Server sanal lansmanı tüm dünya ile aynı anda Türkiye’de de gerçekleştirildi.

Lansman kapsamında ben de “SQL Server 2012 Yüksek Erişilebilirlik-AlwaysOn” konulu bir sunum yaptım.

Bu sunumun video kaydına aşağıda erişebilirsiniz.

Lansman kapsamındaki diğer sunumlara ise aşağıdaki url’den erişebilirsiniz.

http://www.sqlserverlaunch.com/tur/ww_Agenda

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2011 Denali ile beraber gelen en büyük yenilik gruplarından biri yeni High Availability and Disaster Recovery seçenekleri. Bu yeni seçenekler ile beraber daha yüksek erişebilirlik sunulabilecek ayrıca daha güvenilir disaster recovery çözümleri kullanılabilecektir. Ayrıca yeni gelen bu özellik grubuna Always On’da denilmektedir.

[more]

Hali hazırda SQL Server’ın sunduğu High Availability and Disaster Recovery çözümleri aşağıdaki gibidir.

  • Failover Cluster Instance
  • Database Mirroring
  • Log Shipping

Bu çözümler bir çok işimizi çözmekle beraber sektörde daha iyi bir high availability beklentisi vardı. Microsoft’ta Denali’de sunduğu HADR çözümleri ile bu istekleri karşılamış gibi gözüküyor.

HADR ile gelen çözümleri şu anki klasik mirroring yapısının iyileştirilmesi gibi düşünebiliriz. Şimdi isterseniz HADR ile beraber neler geliyor madde madde bakalım.

HADR Altyapısı

HADR kullanmak için hepinizin tahmin edebileceği gibi birden fazla node gerekmekte. Bu node’lar üzerinde Windows Server Failover Cluster (WSFC) kurulu olmalı.

SQL Server tipi olarak cluster kurulum yapma zorunluluğu yok. Standalone SQL Server kurulumları ile de HADR kullanılabilmekte.

Multi-Database Failover

Şu anki mirror yapısı tek bir database seviyesinde tanımlanmakta. Mirror yapılan bu database’de bir sıkıntı oluştuğunda mirror database’den çalışmalara devam edilebilmekte.

Yani burada tek bir database’in failover yapmasından bahsediyoruz.

HADR ile gelen Availability Groups ile database grupları tanımlayabilir ve bu grubun içinde 1 database fail etse dahi grubun tamamını diğer sunucudan çalışır hale getirebileceğiz. Yani grup’un tamamı failover edebilecek.

Böyle bir ihtiyacın neden olabileceği üzerine konuşalım. Örneğin bir ticari program yaptınız ve müşteri bilgilerini bir database’de, satış bilgilerini de bir başka database’de tutuyorsunuz. Satış bilgilerini tuttuğunuz database’de de bazı SP’ler var ve bu SP’ler müşteri DB’sine giderek müşteri bilgilerini getirmekte. Böyle bir yapıda SP’lerin hata vermemesi için 2 DB’nin de aynı sunucu üzerinde bulunması gerekmekte. İşte böyle bir durumda örneğin müşteri DB’si fail edip diğer server’a giderken satış DB’si eski server’da kalmaya devam ederse bahsettiğimiz bu SP’ler hata verip çalışmayacaktır. İşte HADR ile beraber gelen Availability Groups seçeneği ile bu 2 DB’yi aynı grubun içine koyuyoruz ve bu 2 DB’den hangisi fail ederse etsin 2 sini birden mirror sunucudan kullanmaya başlıyoruz.

Şu anki CTP1 sürümündede Availability Groups içinde sadece 2 server bulundurulabilmekte.

Multiple Secondaries

Klasik mirroring çözümünde bir tane secondary yani mirror database bulundurabiliyorduk. HADR ile beraber gelen özelliklerden biri olan Multiple Secondaries yani birden fazla secondary bulundurabilme özelliği ile daha yüksek bir High Availability çözümü sağlamış olacağız.

Active Secondaries for Reporting

Belkide HADR ile beraber gelen en önemli özelliklerden biride secondary database’leri rapor amacı ile kullanabilmek. Bildiğiniz gibi şu anki klasik mirroring çözümünde mirror database’ler herhangi bir şekilde erişebilir durumda değildi  ve atıl olarak kalmaktaydı. Gerçi synonym ve snapshot ile bazı çözümler sunulmuş olmasına rağmen pek istediğimiz gibi çalışmamaktaydı.

HADR ile beraber artık secondary sunucularımızı kullanabilir yapıdayız. Bu durumda primary sunucuyu OLTP işlemleri için, synchronous yada asynchronous olarak beslenen secondary database’ide reporting amacı ile kullanarak ana server’daki yükü bölmemiz mümkün.

hadr

Bu arada CTP1’de sadece asynchronous mode desteklenmektedir.

Fast Client Connection Redirection

Gene klasik mirror yapısında primary database’den secondary database’e geçiş yapıldıktan sonra webconfig bilgilerimizi yeni sunucuya göre ayarlamamız gerekmekteydi. HADR ile beraber sağlanan virtual network name vasıtasıyla sunucular arasında database geçiş yaptıktan sonra herhangi bir connection string değişikliği yapmamız gerekmemekte. Bu yapıyı failover cluster sistemindeki virtual network name ile aynı şekilde düşünebilirsiniz.

Backup on Secondary Server

Backup’lama işlemi primary sunucudan yapılabileceği gibi secondary sunucudan da yapılabilir. Backup’ları secondary sunucudan alarak backup load’ını primary sunucunuzda kaldırabilirsiniz.

Primary’den alınan backup secondary için kullanılabilir, aynı şekilde secondary sunucudan alınan backup’ın da primary sunucu için kullanılması mümkündür.

AlwaysOn Dashboard

Bu kadar gelen yeni özellikle beraber bu özellikleri monitor etmek amacıyla yeni bir dashboard oluşturulmuş durumda. Tek bir ekrandan yeni HADR seçeneklerini monitor etmemiz mümkün.

 

Denali ile gelen/gelmesi planlanan yeni HADR özellikler bu şekilde. Daha sonraki yazılarımda bu özelliklerin teknik detaylarınada inmeye çalışacağım.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan