Database Mirroring (Sürekli Kullanılabilirlik - 2)

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.


Database Mirroring’ in Kurulumu:

Database Mirroring sistemini kurmak çok kolay bir işlemdir. T-SQL dili kullanılarak yapılabildiği gibi, doğrudan SQL Server Management Studio kullanılarak da yapılabilir. Gözönünde bulundurulması gereken bazı şartlar vardır. Genel olarak bunları aşağıda yazdım.

Bir veritabanı, sadece bir Database Mirroring işleminde kullanılabilir.

Database Mirroring işlemi uygulanacak veritabanlarının Recovery Model’ larının da FULL olması gerekmektedir.

Database Mirroring işlemi uygulamak istediğiniz veritabanınının bir yedeğini aldıktan sonra, bu yedeği Kopya rolünü üstlenecek olan SQL Server’ da açın. Yalnız, yedeği konuşlandırırken Recovery State’ inin (Onarım Durumu) NORECOVERY olmasına dikkat edin. Bu, Database Mirroring için zorunlu bir ayardır.

Not: Sistem veritabanlarına (master, msdb, model, tempdb) Database Mirroring işlemi uygulayamazsınız.


Database Mirroring’ in, Failover Clustering’ e karşı avantajları:

- Database Mirroring’ te, Failover Clustering’ te gerekli olan ek donanıma ihtiyaç yoktur (SAN, HBA vb.). Eldeki normal donanımlarla da Database Mirroring sistemi kurulabilir.

- Failover (geçiş) işlemini çok daha erken tamamlar. Bu süre yaklaşık olarak 2-3 saniyedir. Meselâ Failover Clustering kullanıldığında geçiş işlemi ortalama 13-17 sn. arasında bir zamanda tamamlanır. (Not: Failover Clustering’ te, hata durumuna düşen sistemdeki servisler kapanır ve bu servisler diğer çalışan düğümde çalıştırılmaya başlanır.)

- SQL Server Failover Clusterin’ te sadece sürekli kullanılabilirlik vaadedilirken, Database Mirroring’ te hem sürekli kullanılabilirlik, hem de veritabanının canlı bir kopyasının yedeği vaadedilmektedir.


Database Mirroring’ in, Failover Clustering’ e karşı dezavantajları:

- Database Mirroring, sadece High Availability Mode kullanıldığında otomatik geçiş (Automatic Failover) yapabilir. Bu mod da senkron bir mod olduğundan dolayı veritabanına karşı yapılan işlemlerin işlenişinde ek performans yüküne neden olabilir. İşlem akışı, ihtiyaçlara göre iyi analiz edilmelidir.

- Database Mirroring’ te kullanılan Kopya rolündeki veritabanı NORECOVERY durumunda olduğu için, raporlama amacıyla doğrudan kullanılamaz. Ancak, Database Snapshot kullanılmak suretiyle raporlama için kullanılabilir. Database Snapshot özelliği ise sadece SQL Server Enterprise Edition’ da bulunmaktadır. (Developer Edition’ da da bulunmaktadır, fakat bu sürümü üretim ortamında kullanmanız yasa dışıdır.)

- Bir veritabanına sadece bir kere Database Mirroring işlemi uygulanabilir. Yani sadece bir kopyası başka bir sunucu üzerinde Database Mirroring kullanılarak tutulabilir.


Özet

Aşağıdaki koşullar oluştuğunda Database Mirroring’ i kullanmanızı tavsiye edebilirim.

- Eğer iki adet sunucunuz varsa ve bir tane makineyle de Şahit görevini kullanabilecekseniz,

- Ek donanım almak için yeterli bütçeniz yok ise,

- İkincil sunucunuzda tuttuğunuz veritabanının yedeğini raporlama için kullanmayacaksanız veya sürekli güncel bir şekilde raporlama bilgisi gerekmeyecekse, (Burayı biraz daha açmakta yarar var. Raporlama bilgisinin güncelliğinden kastettiğim şu; hatırlarsanız raporlama için Database Snapshot kullanmanız gerekir demiştim ve bu da sadece Enterprise Edition’ da vardı. Burada Database Snapshot’ tan bahsetmeyeceğim, çünkü konumuz dışında bir konu. Ama veritabanındaki güncel bilgiye ulaşmak için Database Snapshot’ ı ara ara güncellemeniz gerekir. Bu da ek iş gücü demektir. Hem de daha yüksek lisans ücreti).



--
Ekrem Önsoy