Makale Özeti

Merhabalar, Bu yazı dizimizde sizlere SQL Server 2005’de High Availability (Yüksek Erişilebilirlilik) seçeneklerinden bahsedeceğim.

Makale

Merhabalar,

Bu yazı dizimizde sizlere SQL Server 2005’de High Availability (Yüksek Erişilebilirlilik) seçeneklerinden bahsedeceğim.

 

Öncelikle yüksek erişilebilirlilik konusunun öneminden ve neler sağladığından bahsetmekte yarar var.

Eğer kullanmış olduğumuz sistem, sürekli ayakta olması gereken, sürekli yüksek performansta çalışması gereken bir

sistemse ve üzerinde çalışılan bu sistemin herhangi bir nedenle erişilemez veya kullanılamaz olması durumunda çok

kısa bir süre içerisinde tekrar sunulan hizmetin başlatılması gerekiyorsa; en azından yüksek erişilebilirlilik yöntemlerinden

bir tanesinin uygulanmış olması doğru olacaktır.

 

İşte bu yazı dizimizde sizlere sırasıyla, SQL Server 2005 üzerinde uygulayabileceğimiz yüksek erişilebilirlilik

yöntemlerinden bahsedeceğim.

 

Uygulanabilecek yüksek erişilebilirlilik yöntemleri şöyledir.

 

·         Database Mirroring,

·         Failover Clustering,

·         Peer-to-Peer Replication (P2P),

·         Log Shipping

 

Bu yazımızda Database Mirroring konusunu ele alacağız.

 

Database Mirroring

Aslında Failover Clustering çözümüne alternatif olan bu yöntemin, otomatik failover özelliğini desteklemesi ve

buna karşılık ekstra bir donanıma ihtiyaç duymaması, Database mirroring (aynalama) yönteminin daha çok tercih
edilmesini sağlamaktadır. İsminden de anlaşıldığı gibi bu yöntem, canlı sistemdeki veritabanının bir görüntüsünü
(kopyasını, yansımasını, yedeğini, benzerini) başka bir instance(SQL Server servisi) üzerinde tutmaktır. Bu şekilde,
canlı sistemin herhangi bir nedenle erişilemez olduğu anda, diğer ilgili SQL Server servisinin bu görevi devralması
amaçlanmaktadır. Tabiki burada dikkat edilmesi gereken önemli bir nokta vardır; SQL Server instance’larının aynı
makinada olması önerilmez. Ancak ayn makina üzerinde de çalıştırılabildiğini de belirtmeliyim. Önerilmemesini nedeni
aslında, makinadan kaynaklanan sebeplerden dolayı oluşacak bir erişilememe durumunda, zaten diğer servis de
erişilemez olacağı için mümkün olduğunca farklı makinalardaki servisleri kullanmakta yarar vardır. Ancak bu yazımızda
yapacağımız örneğimizin lokal makinedeki farklı servisler arasında yapılacağını da belirtmemde yarar var.

 

 

         Database mirroring uygulamasını gerçekleştirebilmek için öncelikle bazı gereksinimlerin sağlanmış olması gerekir.

İlk olarak mirroring işleminde kullanılacak veritabanın bulunduğu makina ile, yani Principal Server adı verilen makine ile
 bir mirrorig işlemi için kullanılacak Mirror Server adı verilen iki makinanın birbirlerini gören makinalar olması gerekmektedir.

Principal Server olarak kullanılan sistem, canlı sistem olarak kullanılan ve donanımsal olarak da güçlü bir sistemdir.
Mirror Server ise, izlenecek stratejiye göre değişiyor olmasına rağmen, genelde üzerinde işlem yapılmayan bir sistemdir.
Ancak canlı sistem ayakta iken, yükü dağıtmak adına, mirror server’ı raporlama amacıyla kullanabilme şansımız da vardır.
Dediğim gibi bu noktada izlenen strateji önemlidir.

 

Database Mirroring işlemi sırasında farklı teknikler kullanma şansımızın olduğunu da belirtmeliyim. Bu nedenle de bu
senaryolardan bazıların Principal ve Mirror server’ların yanında, sistemin doğru çalışması için bir tane daha servise
ihtiyaç duyulmaktadır. Bu servisin olduğu makine de, Witness Server (Şahit) olarak isimlendirilmektedir.
Witness Server, diğer iki makinayı kontrol eden, onların ayakta olup olmadıklarını izleyen, üzerinde iş yükü olmayan
bir server’dır.

 

 

 

Principal ve Mirror Server’lar hangi yöntem olursa olsun, mutlaka olmak zorundalardır. Witness Server ise; tüm
yöntemlerde kullanılamamaktadır. İşte bu farklı yöntemleri şöyle açıklayabiliriz.

 

1- High Availability Mode

Bu moda witness server’ın kullanıldığı, otomatik failover’ın aktif olduğu, ve kopyalama ya da mirror server üzerinde
yedekleme işleminin yapıldığının garanti altına alındığı bir moddur. Transaction’ların principal server üzerinde işletilmesinin
ardından senkron bir şekilde bu bilgiler Mirror Server’a aktarılmakta ve bu server üzerinde de kaydedildiği onayı 
principal server’a gönderilmektedir. Principal server, bu onay bilgisini aldıktan sonra, diğer transaction’ları işlemeye
başlamaktadır. Bu nedenle aslında, bu mod güvenli ve yedek sistemin çok kısa bir şekilde ayağa kalkmasını sağladığı için
 tercih edilmektedir. Ancak dikkat edilmesi gereken nokta ise; senkron erişim ve onay mekanizmasından dolayı performans
 kaybına neden olmasıdır. Tabiki otomatik failover yanında manual failover desteği de vardır.

Bu modda, principal server erişilemez olursa; witness server hemen mirror server’ı principal olarak devreye alır.
Eğer Mirror server erişilemez olursa; principal server ile witness server arasındaki bağlantı korunur ve sistem çalışmaya
devam eder.

 

2- High Protection Mode

Bu modda witness server kullanılmamaktadır. Ancak high availability mode’ da olduğu gibi yine senkron bir eşleme yani
 transaction’ların kaydının yapıldığını gösteren onay mekanizması bulunmaktadır.

Bu modda, Principal server erişilemez olursa; mirror server’ın bu görevi üstlenmesi işlemi manual olarak gerçekleştirilir.
Yani manual failover geçerlidir. Eğer Mirror Server erişilemez hale gelirse; principal server, veri kaybını önlemek için
offline moda geçer.

 

3- High Performance Mode

Bu modda transaction güvenliği yoktur. Principal ver Mirror server’lar arasındaki eşleme asenkron olarak yapılmaktadır.
 Principal server, Mirror server’ın işlemi yaptığı onayını beklemeden sıradaki işleme geçmektedir. Bu durum performans
 artışı sağlasa da, veri tutarlılığı ve erişilebilirlilik adına kayıp oluşmasına yol açabilir.

Bu modda, Principal server  erişilemez olursa; yine high prtection mode’da olduğu gibi manual failover senaryosu
uygulanmak zorundadır. Ayrıca bu noktada, principal server tarafından commit edilen transaction’lar, henüz mirror
tarafından işlenmemiş olabilir ve veri bu nedenle de veri kaybına neden olabilir.

Eğer Mirror server erişilemez ya da hataya düşerse; principal server bu durumdan etkilenmez. Ancak mirroring işlemi
doğru ilerlememiş olur.

 

 

 

Mirroring işlemi için neler gereklidir?

Öncelikle database mirroring işleminin gerçekleştirileceği SQL Server 2005 sürümlerinin, Standart veya Enterprise
olması gerekmektedir. Ancak witness server olarak kullanılacak SQL Server’ın Express Editon olması sorun
oluşturmayacaktır. Bu senaryolarla ilgili (SQL Server 2000 witness olarak kullanılabilirmi?) örneklerimizi bir sonraki
yazımızda adım adım açıklıyor olacağız. Ancak Database mirroring uygulaması yapılabilmesi için, SQL Server 2005 SP1’in
kurulu olması gerekir. Aslında öncesinde de deneme amaçlı kullanma şansı verilmiştir, fakat SP1 ile özellikle kullanılabilir
olduğu belirtilmiştir.

 

Ardından daha önce de bahsettiğimiz gibi, hangi modun kullanılacağı ve tabiki de buna bağlı olarak kaç makinanın
kullanılacağına karar verilmelidir. Bu noktada, witness server için ayrılacak makinanın çok güçlü özelliklere sahip olması
gerekmemektedir. (Hatta demo larımızı yaparken tek makina kullanacağımızı, ve bunun mümkün olduğunu daha önce
belirtmiştim)

 

Ve Database mirroring işleminin Database seviyesinde yapıldığını yani ilgili veritabanının bire-bir bir kopyasının elde
edildiğinin unutulmaması gerekir. Ancak sistem database’leri üzerinde database mirroring işlemi yapılamayacağını
da unutmamalıyız.

 

Giriş niteliğinde olan bu yazımızda Database mirroring mimarisini genel hatarıyla tanımış olduk. Devam eden yazılarımızda,
örnek mirroring senaryoları, farklı modların uygulanışı, felaket senaryoları (principal erişilemez, mirror erişilemez) ve belki
de en çok sıkıntı yaşanan noktaları yani Mirroring işleminden sonra veritabanı yönetimi konularını ele alacağız.