|
|
Database Mirroring
Merhaba,
Bu makalemde, Database Mirroring çözümünün nerede, ne zaman
ve nasýl kullanýlabileceðinden bahsedeceðim.
Bundan önceki yazýmda SQL Server Failover Clustering konusundan
bahsetmiþtim. Sürekli Kullanýlabilirlik seçenekleri olarak SQL Server Fileover Clustering
ve SQL Server 2005 SP1 ile birlikte gelen Database Mirroring en çok kullanýlan seçeneklerdir.
Aslýnda Database Mirroring, SQL Server 2005’ in RTM (Release to Manufacturer) versiyonunda
da vardý. Fakat Microsoft tarafýndan sadece test amaçlý kullanýlmasý öneriliyordu.
SQL Server 2005’ in birinci Servis Paketi ile herkes tarafýndan kullanýlabilir olduðu
açýklandý ve kullanýlmasý teþvik edildi. Database Mirroring özelliði sadece SQL
Server’ ýn Standard ve Enterprise Edition’ larýnda kullanýlabilir durumdadýr. SQL
Server Express Edition ise, Þahit Rolü için kullanýlabilir.
Database Mirroring’ in özelliklerinden bahsettikten sonra Database
Mirroring’ in, SQL Server Failover Clustering’ e karþý eksileri ve artýlarý konusundan
da bahsedeceðim. Meselâ Failover Clustering yerine, neden ve ne zaman Database Mirroring
Kullanabiliriz? Database Mirroring’ in, Failover Clustering’ e karþý avantajlarý
ve dezavantajlarý nelerdir?
Database Mirroring’ in Çalýþma Biçimleri:
Database Mirroring’ in üç adet çalýþma biçimi bulunmaktadýr.
Bunlar:
- High Availibility Mode
- High Performance Mode
- High Protection Mode’ dur.
Her çalýþma biçimi, deðiþik durumlara göre uygulanabilir. Bununla
birlikte, High Protection Mode, Microsoft tarafýndan çok gerekmedikçe önerilmiyor.
Nedenini konu baþlýklarýndan bahsederken anlatacaðým. Þimdi çalýþma biçimlerinden
biraz daha ayrýntýlý bahsedelim.
1- High Availibility Mode: Otomatik Geçiþ özelliði
sadece bu çalýþma biçiminde bulunmaktadýr. Bu çalýþma biçiminin çalýþma mantýðýný
aþaðýdaki Þekil 1’ de betimlemeye çalýþtým:
Þekil 1
Þekil 1’ de de gösterdiðim gibi, High Availibility Mode’ da,
tüm sunucular sürekli birbirleriyle haberleþiyorlar. Bu topolojide, etkin olarak
kullanýlan veritabaný Birincil SQL Server’ dadýr. Fakat Birincil sunucudaki veritabanýnda
bir deðiþiklik yapýlýrken, ayný deðiþikliðin Kopya SQL Server’ daki veritabanýnda
da yapýldýðýndan emin olunur. Bu da senkron bir sistem demektir. Sistem, ayný iþlemin
iki veritabanýnda da yapýlmasýndan emin olmak zorundadýr. Bu nedenle, Birincil veritabaný,
ancak iþlemin Kopya veritabanýnda da gerçekleþtirildiðinden emin olduktan sonra
diðer iþlemleri iþlemeye baþlayabilir.Bu senkronizasyon zorunluðu nedeniyle de bazý
performans sorunlarý yaþanabilir. Bu, kesinlikle dikkate alýnmalýdýr.
SQL Server Express Edition’ ýn, Þahit Rolü için kullanýlabileceðinden
önceden bahsetmiþtim. Fakat Birincil ve Kopya sunucularda SQL Server’ ýn Standard
veya Enterprise Edition’ larýnýn yüklü olmasý gerekmektedir.
Þahit, sunucularýn çalýþtýðýndan emin olmak için kullanýlýr.
Otomatik Geçiþ iþlemi, Þahit sayesinde gerçekleþtirilir. Þahit, Birincil ve Kopya
rollerini üstlenen sunuculara belirli aralýklarla PING atar. Böylece çalýþýp çalýþmadýklarýný
kontrol eder. Þayet Birincil sunucudan attýðý PING’ e cevap alamazsa, bu rolü otomatik
olarak Kopya sunucuya devreder ve eskiden Kopya rolünü oynayan sunucu, artýk Birincil
rolü alýr ve kullanýcýlar da bu veritabanýný kullanmaya baþlarlar. Peki kullanýcýlar,
daha doðrusu, kullanýcýlarýn kullandýðý program bunu nereden bilecek? SQL Server
Native Client ve ADO.Net 2.0 bunu hallediyor.
Peki, eski Birincil sunucu tekrar ayaða kaldýrýldýðýnda ne mi
oluyor? Þu oluyor, eski Birincil sunucu, artýk Kopya sunucu rolünü üstleniyor ve
yeni Birincil sunucu ile eþleþiyorlar. Tabii ki illa da eski Birincil sunucuyu kullanacaðým
derseniz, bu sunucuyu ayaða kaldýrdýktan sonra ve eþleþtirmeyi (senkronizasyon)
de tamamladýktan sonra el ile Geçiþ yapabilirsiniz. Böylece eski Birincil sunucunuz
yine Birincil sunucu olur.
2- High Performance Mode: Bu çalýþma biçiminde
Otomatik Geçiþ özelliði yoktur. Sadece elle geçiþ yapabilirsiniz. Ayrýca bu, asenkron
bir moddur. Aþaðýda gene bir þekil yaptým, onun üzerinden anlatmaya çalýþayým.
Þekil
2
Görüldüðü gibi, bu çalýþma biçiminde bir Þahit bulunmamaktadýr.
Sadece iki rol söz konusudur. Ayrýca, High Availibility Mode’ dan farklý olarak,
senkron deðil, asenkron bir iþlem süreci söz konusudur. Bunu bir örnekle açýklayayým:
Meselâ kullanýcýlar Birincil sunucuda bir iþlem yaptýklarýnda, Birincil sunucu,
bu iþlemi gerçekleþtirmek için Kopya sunucudan gelecek teyidi beklemez. Bu da herhangi
bir performans sorununa neden olmayacak demektir. Fakat bununla birlikte, Kopya
sunucunun, Birincil sunucu ile ne derecede eþleþmiþ olduðunu da takip edemeyeceksiniz.
Yani Kopya sunucusunda veri kaybý söz konusu olabilir.
Veri kaybýnýn söz konusu olmasý, ayrýca Otomatik Geçiþ niteliðinin
de bulunmamasý nedeniyle, “üretim” ortamlarýnda bu çalýþma biçiminin kullanýlmasýný
þahsen önermiyorum.
3- High Protection Mode: Bu çalýþma biçimi
bazý yönleriyle High Availibility Mode’ a benzer. Hatta tek farklýlýklarý, bu çalýþma
biçiminin Otomatik Geçiþ özelliðinin olmamasý da diyebiliriz.
Bu çalýþma biçiminde de Þahit bulunmamaktadýr. Gene Birincil
ve Kopya rollerini üstlenen suncular birbirleriyle haberleþirker. Senkron bir çalýþma
söz konusudur. Birincil’ e gelen iþlem, Kopya’ da da iþlenmeden Birincil’ deki diðer
iþlemlere geçilmez.
Bu açýdan, eðer bu çalýþma biçimini kullanacaksanýz hem performans
yükünü hem de Otomatik Geçiþ özelliðinin olmamasýný kabul edeceksiniz demektir.
Madem olasý performans yükü göze alýnýyor, o zaman High Availibility Mode’ u kullanmanýz
çok daha iþe yarar olacaktýr. |
Sonraki sayfa >
|
|