SQL Server 2005 ile birlikte gelen pek çok özellikten biri ve ürünün süreklilik alanında en önemli artılarından biri Database Mirroring. Bu makalede Database Mirroring özelliğini detaylı olarak ele alarak adım adım bir Database Mirroring senaryosu geliştiriyor olacağız.
Database Mirroring?in sunduğu en önemli artı sistemimizde bir sorun olduğunda yedek veritabanının aktif hale gelme süresini son derece azaltan bir yapıya sahip olması ki bu özelliği cluster yapısındaki ayağa kalkma süresini düşündüğümüzde son derece düşük, bir kaç saniye şeklinde niteleyebileceğimiz bir süre.
Makalenin hazırlanması sırasında MSDN, çeşitli SQL Server MOC?u ve kitabı ve tabiki arama motorlarından faydalandım. Pek çok farklı kaynakta konu ile ilgili farklı ayrıntılar yer alıyor ve eminim burada ele almadığım bazı ufak ipuçları olacaktır. Makalede ele alacağımız konuları sıralamak gerekirse;
1. Database Mirroring Nedir?
2. Database Mirroring Mimarisinde yer alan roller
3. Sistemin Database Mirroring?e hazırlanması
4. Endpointlerin oluşturulması
5. Database Mirroring?in devreye alınması
6. Database Mirroring?in kaldırılması
Başlarken
Database Mirroring için herşeyden önce SQL Server 2005?in Standart veya Enterprise Edition sürümlerinden birine ihtiyacımız var. Bu noktada Database Mirroring için 3 ayrı bilgisayar kullanıyor olacağız ki neden 3 bilgisayar var, hangisi ne işe yarayacak ?Database Mirroring Mimarisinde yer alan roller? başlığında bu soruyu detaylı olarak cevaplıyor olacağım. Örnek senaryomuzu AdventureWorks örnek veritabanı üzerinden yapacağımız için bu veritabanının her üç SQL Server kurulumunda da olması gerekmekte.
Son ve önemli madde ise, Database Mirroring?in SQL Server 2005 RTM tarafından desteklenen standart bir özellik olmaması. Database Mirroring SQL Server 2005 Service Pack 1 ile standart olarak desteklenmeye başlamıştır (her ne kadar bu service pack yayınlanmadan önce ufak bir komut ile kullanabiliyor olsak da, resmen desteklenen bir özellik olması daha iyi). Sonuç olarak başlamadan önce SQL Server 2005 Service Pack 1?i yüklememiz gerekiyor.
Database Mirroring Nedir?
Database Mirroring Mimarisinde yer alan roller
Yeni olan her teknoloji gibi Database Mirroringde kendine özgü bazı terimleri hayatımıza taşıyor. Şimdi bu yeni terimleri ve anlamlarını, database mirroringde yer alan rolleri, bu rollerin görevlerini ve birbirleri ile etkileşimlerini ele alalım.
Database Mirroring iki zorunlu, bir opsiyonel rol ile çalışan bir yapıya sahiptir. Veritabanlarından birini ?principal? diğerini ise ?mirror? rolünde tanımlamamız gerekir. Opsiyonel olarak ana veritabanı (principal) devre dışı kaldığında yedek veritabanına (mirror) otomatik olarak geçişi sağlayacak witness server tanımlayabiliriz. Aşağıdaki grafik bu makalede gerçekleştireceğimiz database mirroring yapısının diyagramıdır.
Şekil 1:1 :: Database Mirroring YapısıPrincipal Rolü
Principal rolünde tanımladığımız veritabanı tüm transactionların kaynağıdır. Uygulamaların veri okuma ve yazma işlemini yapacağı veritabanıdır. Veritabanını bir database mirroring session?ına dahil etmek için full recovery model?i kullanmamız gerekir ki bu konuyu bir sonraki bölümde detaylı olarak ele alıyor olacağız.
Mirror Rolü
Mirror rolünde tanımladığımız veritabanı ana veritabanımızın aynısıdır, ortağıdır ve sürekli olarak principal veritabanından transactionlar alır. Database Mirroring prosesi sürekli olarak ana veritabanında gerçekleşen transactionların loglarını mirror veritabanının transaction log?una ve transaction log?u da data dosyalarına aktarır. Böylece bu mekanizma çalıştığı sürece mirror veritabanı, principal veritabanındakiler ile aynı verilere sahip olacaktır. Mirror veritabanı recovering modunda olduğu için herhangi bir bağlantıyı veya doğrudan yazma işlemini desteklememektedir ancak mirror veritabanından bir database snapshot oluşturarak kullanıcıların bu snapshot sayesinde read-only erişim elde etmelerini sağlayabiliriz.
Witness Server
Witness Server, database mirroring mimarisinin üçüncü ve kullanımı opsiyonel olan rolüdür. Bu serverı otomatik failover tespiti ve yedek veritabanının (mirror) otomatik olarak aktif hale getirilmesi için kullanırız. Witness serverı high availability operating mode?u kullanarak konfigure ederiz. Database Mirroring mimarisinde bir principal?ın sadece tek bir mirror?ı olabiliyorken (aynı şekilde bir mirror sadece tek bir principal?a bağlı çalışabiliyor), witness serber birden çok database mirroring yapısını monitör edebilir. Witness serverın hizmet verdiği her database mirroring yapısı sys.database_mirroring_witnesses catalog view?ında tek bir satırlık bilgi olarak yer alacaktır.
Özetlemek gerekirse witness server oluşturduğumuz database mirroring yapılarını monitör ederek, bir principal?ın devre dışı kalması halinde en kısa sürede mirror veritabanının primary rolüne getirilmesi ve sürekliliğin sağlanmasından sorumludur.
Witness server olarak kullanılacak SQL Server?da herhangi bir SQL Server sürümünü (Express Edition dahil) kullanabilirsiniz.
Veritabanlarının Database Mirroring?e Hazırlanması
Database Mirroringin konfigurasyonunu her veritabanında ayrı ayrı yapmamız gerekiyor. Bu bölümde hazırlık sürecinde yapmamız gerekenleri tek tek ele alacağız. Adımlarımız sırasıyla veritabanlarının full recovery model?da olmasını sağlamak, ana veritabanının yedeğini almak ve mirror sql serverda no recovery ile restore etmek ve son olarak ana veritabanındaki önemli sistem nesnelerini mirror veritabanına taşımak olacak.
Recovery Model
SQL Server veritabanları için üç recovery model sunmaktadır. Bunlar: Simple, Bulk-Logged ve Full. Simple recovery model transaction log?u, her checkpointte aktif olmayan bölümleri silerek yedekler. Bulk-Logged recovery modelda Bulk insert, bcp veya create index işlemlerinin tamamını yedeklemez. Database Mirroring'de hem ana hem yedek veritabanları birbirinin aynısı olacağından ki sadece veri anlamında değil, log sequence numbers gibi iç yapılarında birbirinin aynısı olacağından, simple ve bulk-logged recovery modelleri database mirroring için yetersiz kalacaktır. Bu nedenle database mirroringde kullanabileceğimiz tek recovery model, full recovery model?dır.
Backup ve Restore
Principal ve mirror veritabanları birbirinin kopyası olduğundan, her iki veritabanınında aynı state ile çalıştığından emin olmamızı sağlayacak bir mekanizmaya gereksinim duyarız. Burada initializasyonu yapacak proses principal veritabanının yedeğini alarak mirrora restore edecektir.
Veritabanının mirror?a restore edilmesi sırasında no recovery seçeneğini belirtmemiz çok önemlidir.
Database Mirroring konfigurasyonunda harcanan zamanın büyük bölümünü backup ve restore işlemlerinin aldığını farkedeceksiniz.
Sistem Nesnelerinin Kopyalanması
Database Mirroring veritabanı seviyesinde çalışan bir yapı olduğu için sistemdeki diğer nesneler bizim için önemli değildir ancak sistemi hata sırasında mirror veritabanını otomatik olarak aktif hale getirecek şekilde ayarlayabilecek olsak da, failover sonrasında uygulamaların çalışmaya devam edebilmesini sağlamak için diğer nesnelerinde mirror veritabanına taşınmasını isteyebiliriz.
Burada aklımıza gelecek ilk nesne türü elbette authentication ve authorization işlemlerinde kullanılan login nesneleridir. Login nesnelerine ek olarak lined serverlar, SQL Server Integration Services (SSIS) paketleri, SQL Server Agent jobları, özel hata mesajları ve diğer sunucu nesnelerini taşımak isteyebiliriz. Initialization işleminin son adımı bu nesnelerin kopyalanması olacak.
Örnek Senaryomuz
Makale boyunca sürdüreceğim örnekte masamdaki 3 pc?yi kullanıyor olacağım. Bu bilgisayarların networkteki isimleri ise aşağıdaki gibi. Database Mirroring senaryosundaki rol, makina adı, ip adresi:
- Principal: 192.168.170.82
- Mirror: 192.168.170.71
- Witness: 192.168.170.74
1. *82 ipli bilgisayarda yer alan adventureworks veritabanının yedeğini alarak işe başlıyoruz.
2. Aldığımız bu backup?ı no recovery seçeneği ile mirror veritabanının yer alacağı *74lü bilgisayara restore ediyoruz.
Endpoint?lerin Oluşturulması
SQL Server 2005, önceki sürümlere ve diğer rdms ürünlerine kıyasla çok daha güçlü, çok katmanlı bir güvenlik modeli sunmaktadır. Güvenliğin ilk katmanı bağlantı noktasında yer almaktadır. Endpointler ise instace?ın bağlantılarını yönetmektedir. Database Mirroring üç SQL Server 2005 instanceının iletişimine dayandığı için, bu instancelar arasında iletişimin sağlanması için endpointleri oluşturmamız gerekiyor.
Endpoint Türleri
SQL Server 2005?te iki farklı endpoint türü oluşturabiliriz: TCP veya HTTP. Database Mirroring'de iletişim için TCP endpoint kullanılırken, SOAP taleplerinin karşılanmasında HTTP Endpointler kullanılır.
Endpoint tür tanımlaması sırasında bir de payload belirtmeniz gerekir. TCP endpointler TSQL, SERVICE_BROKER veya DATABASE_MIRRORING türünden payload alabilir. Bir database mirroring oturumu için TCP endpointi DATABASE_MIRRORING payloadı ile oluştururuz. Payload?ı SQL Server?da instance seviyesinde oluştururuz, böylece her sql server instance?ında DATABASE_MIRRORING payloadı olan tek bir endpoint oluşturmamız yeterli olur.
Endpoint Güvenliği
Endpointler ihtiyaçlarımız doğrultusunda özelleştirebileceğimiz çok katmanlı bir güvenlik yapısı sunar. Güvenliğin ilk katmanı tür ve payload tanımlamasıdır. Database Mirroring için bir endpoint oluşturduğumuzda, bu endpoint database mirroring talepleri dışındaki talepleri cevaplamayaz ve HTTP, TSQL ve Service Broker taleplerini reddeder.
Güvenliğin ikinci katmanı, endpointin TCP konfigurasyonudur. Her TCP endpoint için bir port numarası belirtmemiz gerekir. TCP endpointlerde varsayılan port numarası 5022dir. Daha sonra TCP Endpoint için Listener IP belirtiriz. TCP Endpointler varsayılan olarak tüm geçerli IP adreslerinden gelen talepleri (ALL seçeneği) kabul ederler. Bu noktada sadece belirli bir ip adresinin talepleri dinlemesini sağlayabiliriz. Standart port numarası yerine farklı bir port numarası belirtmek güvenlik açısından faydalı bir önlem olacaktır.
Üçüncü ve dördüncü güvenlik katmanlarımız authentication metodu ve encryption seçeneğidir. Windows tabanlı kimlik doğrulama ve sertifikaları kullanabiliriz. Windows tabanlı kimlik doğrulama için NTLM, KERBEROS veya NEGOTIATE seçeneğini seçeriz. NEGOTIATE seçeneği instanceların authentication metodunu otomatik olarak seçmesini sağlar.
Endpointler arasındaki tüm iletişim şifrelenebilir ve şifreleme için hangi algoritmanın kullanılacağını seçebiliriz. Şifreleme için kullanılacak varsayılan algoritma RC4?tür ancak RC4?e göre çok daha güçlü bir alternatif olan AES algoritmasını da kullanabiliriz.
Şifreleme konusunda AES alternatifi kullanmamız halinde daha güçlü şifreleme elde edeceğimiz doğrudur ancak şifreleme için harcanacak kaynaklar artacak ve göze alınabilir oranda da olsa performans düşüşü olacaktır.
Güvenliğin Beşinci ve altınca katmanlarına gelecek olursak; bir bağlantının kurulabilmesi için endpointe CONNECT yetkisinin verilmesi gerekir. Ek olarak endpointin state özelliğini STARTED olarak belirlememiz gerekir. STOPPED veya DISABLED durumundaki bir endpoint her bağla ntı talebine bir hata mesajı ile cevap verecektir.
Database Mirroring Endpoint Türü
Database Mirroring desteği veren endpointler, TCP endpointlerin özelleştirilmiş bir versiyonudur ve aşağıdaki özelliklere sahiptir:
- TCP endpoint türü
- DATABASE_MIRRORING payload türü
- Her bir SQL Server Instance?ı için tek bir Database Mirroring endpointi desteklenir.
Database Mirroring endpointleri güvenliğin yedinci katmanını ROLE seçeneği ile sağlar. Bir endpointi PARTNER, WITNESS veya ALL olarak tanımlayabiliriz. PARTNER olarak tanımladığımız endpointler sadece principal veya mirror olabilir, WITNESS olarak tanımladığımız endpointler ise sadece WITNESS olarak rol alabilir. Bir endpointi ALL şeklinde tanımlarsak, her üç rolün özelliklerinide destekler.
Burada dikkat etmemiz gereken bir nokta olarak; SQL Server 2005 Express Editionda sadece WITNESS endpoint türünün desteklendiğidir. Dolayısıyla Express Edition?u mirror veya principal rolünde kullanamayız.
Database Mirroring Endpointi Oluşturmak İçin;
Aşağıdaki T-SQL ifadesini, database mirroring endpointi oluşturmakta kullanacağız:
CREATE ENDPOINT [Mirroring] AS TCP (LISTENER_PORT = 2012)
FOR DATA_MIRRORING (ROLE=PARTNER, ENCRYPTION = REQUIRED);
ALTER ENDPOINT [Mirroring] STATE = STARTED;
Bu kod 2012 numaralı porttan database mirroring servisi veren bir endpoint oluşturacaktır. PARTNER rolünde olduğu için bu endpoint kendi instanceı üzerindeki veritabanlarının RC4 şifreleme algoritması kullanarak sadece principal veya mirror rolünde bulunmasına izin verecektir.
Database Mirroringi SQL Server Management Studio ile, database properties ekranında, mirroring bölümünden konfigure ederiz. Bu ekranda Configure Database Mirroring Security Wizard?ı çalıştıracak olan Configure Security?i tıklarız. Bu wizardda yer alan adımları tamamladığımızda wizard database mirroring senaryosuna dahil ettiğiniz tüm SQL Server instancelarında iki adet CREATE ENDPOINT ve ALTER ENDPOINT ifadesi çalıştırır.
Şimdi senaryomuza geri dönerek endpointleri oluşturalım:
İlk olarak principal sunucumuzu konfigure ederek başlıyorum.
3. Principal olarak kullanacağımız SQL Server?a bağlanıyoruz. (Senaryomuzda bu sunucu tfs adlı bilgisayar)
4. Adventureworks veritabanını sağ tıklayarak Properties ekranını açıyoruz.
5. Mirroring ekranını açıyoruz.
6. Configure Database Mirroring Security Wizard?ı çalıştırmak için Mirroring ekranında yer alan Configure Security butonunu tıklıyoruz. Şimdi üç database mirroring rolü için endpoint tanımlamalarını yapacağız.
7. ?Include Witness Server? ekranında (wizardın ikinci adımı) Yes seçeneğini işaretliyoruz. Bunu yaparak database mirroring senaryomuzda bir witness server olacağını belirtmiş olduk.
8. ?Choose Servers to Configure? ekranında Principal Server seçeneği pasif durumdadır (bu wizardı principal serverdan çalıştırdığımız varsayılmasından kaynaklanmaktadır). Bu ekrandaki Mirror ve Witness server seçeneklerinide işaretleyerek Next butonunu tıklıyoruz.
9. ?Principal Server Instance? ekranında Principal Server instance?ı zaten seçilmiş durumdadır. Listener Port alanında kullanmak istediğimiz port numarasını, Endpoint Name alanında ise kullanacağımız endpoint için bir isim belirtiyoruz. Burada veri iletişiminin daha güvenli olmasını sağlamak için ?Encrypt data sent through this endpoint? seçeneğini de işaretliyoruz ve Next butonunu tıklıyoruz.
10. ?Mirror Server Instance? ekranında Connect butonunu tıklayarak mirror veritabanının bulunduğu SQL Server instance?ını ve bağlanmak için gerekli kullanıcı bilgilerini belirtiyoruz. Bu işlem mirror ile olan bağlantıyı oluşturacaktır. Kullanılacak port numarasını belirttikten sonra ?Encrypt data sent through this endpoint? seçeneğini yine işaretliyor ve Next butonunu tıklıyoruz.
11. ?Witness Server Instance? ekranında bir önceki adımda yaptığımız işlemleri witness server için gerçekleştiriyoruz.
12. ?Service Accounts? ekranında servislerin kullanacağı accountları belirtiyoruz. Bu seçenek opsiyoneldir. Tüm endpointlerde SQL Server servisi aynı servis accountu ile çalışıyorsa bu adımda yapmamız gereken herhangi bir şey yoktur. Farklı accountlar kullanıyorsak, gerekli değişiklikleri yaparak Next butonunu tıklıyoruz.
13. Complete Wizard ekranında yaptığımız seçimleri gözden geçirebilir, gerekli durumlarda geri dönerek seçimlerimizi değiştirebiliriz.
14. Finish butonunu tıkladığımızda Configuring Endpoints ekranı çıkar. Konfigurasyon durumunda oluşabilecek hata ve uyarıları buradan görebilirsiniz. Herşeyin yolunda gitmesi durumunda 3 adımda Success şeklinde sonuçlanır.
15. Endpoint konfigurasyonu tamamlandığında bir uyarı diyaloğu, Mirroringi manuel olarak başlatmamız gerekiyor. Database Mirroringi çıkan uyarı diyaloğu aracılığıyla veya Database Properties ekranında Mirroring ekranından başlatabiliriz. (ben Start Mirroring butonunu tıklayarak mirroringi hemen başlatıyorum)
Database Mirroring'de Desteklenen Çalışma Modları
Database Mirroring?i üç farklı çalışma modunda çalıştırabiliriz. Bunlar: High Availability, High Performance ve High Protection. Çalışma modu transactionların principal ve mirror veritabanları arasındaki iletişimini belirler. Bu başlık altında desteklenen çalışma modlarını, artı ve eksilerini ve database mirroring?in caching ve transparent client redirect özelliğini ele alıyor olacağız.
High Availability Operating Mode
Sql Server tüm transactionları öncelikle SQL Server için rezerve edilmiş olan bellek alanına yazar. Sistem daha sonra bellekte yer alan bu bilgileri transaction loga kaydeder ve sonrasında transaction logları baz alarak data dosyalarında gerekli ekleme/güncelleme/silme işlemlerini gerçekleştirir. SQL Server transaction loga bir transaction yazdığında, sistem database mirroringi transaction logları mirrora aktarması için tetikler. Uygulama transaction için bir commit komutu gönderdiğinde transaction önce mirror veritabanına işlenir, sonrasında principala, principal veritabanında commit işlemine izin veren bir bilgi mesajı gönderilir. Bu proses tüm transactionların hem principal hem de mirror veritabanının transaction loglarında yer almasını garanti eder.
Transaction hem principal hem de mirror veritabanının transaction loguna işlenmediği sürece SQL Server commit işleminin başarıyla tamamlandığını varsaymadığı için High Availability operating mode performans açısından en verimli çalışma modudur diyemeyiz ki Principal ve Mirror instanceları arasındaki fiziksel mesafeye orantılı olarak performans artacak veya azalacaktır.
High Availability operating mode failureları otomatik olarak tespit ederek mirror instanceı devreye almak için bir witness severa gereksinim duyar. Her ne kadar witness server principal serverın çalışıp çalışmadığını ping ile tespit etse de, bir veritabanı pek çok nedenden dolayı (aktif olmasına rağmen) erişilemez durumda olabilir. Database Mirroring bu gibi durumları failure olarak algılamaz. Sadece ping işleminin sonucu başarısız dönerse, mirror sunucuyu devreye alır.
Bir failure durumunda Database Mirroring principal ve mirror veritabanının rollerini ve aynı zamanda transaction logları değiştirir. Özellikle transaction logların da değiştiriliyor olması süreklilik açısından replikasyon ve log shippinge göre çok büyük bir artıdır.
Otomatik failover işleminde mirror veritabanı principal veritabanı olarak hizmet vermeye başlar ancak öncesinde witness serverın failovera karar vermesi ve principal ile mirror serverların rollerini değiştirmesi gerekir. Principal serverın fail olması ve mirror serverın witness servera bağlanamaması durumundaysa SQL Server mirror serverı principal olarak konfigure edemeyecektir.
Mirror serverın veritabanı servisi verip vermeyeceğine kendi karar verecek şekilde konfigure edilmişse, bir veritabanının birden fazla sunucu üzerinde erişilebilir halde olması (split-brain) gibi bir durumla karşılaşabiliriz.
High Availability Operating Mode failover sırasında aşağıdaki adımları izler.
1. Principal ve mirror serverlar sürekli olarak birbirlerine ping gönderir.
2. Witness server sürekli olarak principal ve mirror sunucularına ping gönderir.
3. Principal bir nedenden dolayı erişilemez hale gelir.
4. Mirror failure?ı tespit eder ve witness servera principal olarak hizmet vermek için talepte bulunur.
5. Witness principal servera ping gönderemiyorsa ancak mirror servera gönderebiliyorsa witness rollerin değişimine karar verir ve mirror serverı principal, principal serverı mirror server olarak konfigure eder.
6. Principal server tekrar aktif hale gelir ve mirror serverın principal olarak çalıştığını tespit eder.
Witness serverın bu süreç sırasında offline olması durumunda otomatik failover gerçekleşmeyecektir.
High Performance Operating Mode
Database Mirroring?in high performance operating modu principal ve mirror serverları kullanırken, witness servera gereksinim duymaz. Bu çalışma modu otomatik failover tespitini ve failoverı mümkün kılmayan warm standby konfigurasyonu sunar.
High performance operating mode uygulamanın transactionlarının mirror servera asenkron olarak iletilmesinden dolayı otomatik failoverı desteklemez. Transactionlar principal veritabanına commit edilir ve uygulamaya bilgi gönderilir. Ayrı bir proses ise transactionları mirrora aktarır ki bu işlem gecikmeye neden olur ve proses SQL Server?ın tüm transactionları mirrora aktardığından emin olamayacağı için database mirroring oturumunun otomatik failover yapmasına izin vermez.
Transfer asenkron olduğundan, high performance operating mode uygulamanın performansını etkilemez ve principal ve mirror sunucular arasındaki mesafe, sistemin performansını daha az etkiler. Ancak bu çalışma modu gecikmeyi arttırır ve primary veritabanının fail olması halinde daha yüksek veri kaybına neden olabilir.
High Protection Operating Mode
High protecting operating mode, high availability operating mode ile hemen hemen aynı özelliklere sahipken witness server konfigurasyonu yapılmaması ile bu moddan ayrılır. SQL Server transactionları principal ve mirror arasında senkron olarak transfer eder ancak (witness server olmadığı için) failover, manuel gerçekleştirilmek zorundadır.
High protection çalışma modunun senkron transferi uygulama performansını etkilerken otomatik failover desteği sunmamasından dolayı bu çalışma modunun sadece mevcut witness serverın değiştirilmesi gerektiği durumlarda kullanılması, değişiklik sonrasında çalışma modunu tekrar high availability operating mode?a dönüştürmeniz önerilir.
Transparent Client Redirection
Log shipping ve replikasyon kullanırken karşılaştığımız en büyük sorun uygulama bağlantılarıydı. Birincil sunucu devre dışı kaldığı için uygulamalar çalışmaya devam edebilmeleri için ikinci sunucuya yönlendirilmeliler. Database mirroring bu sorunu farklı bir çözüm ile ortadan kaldırmaktadır.
Visual Studio 2005 ile gelen yeni MDAC sürümü database mirroringe özgü, Transparent Client Redirect adında bir connection nesnesi sunar. Principala bir bağlantı yapıldığında connection nesnesi principal ile birlikte mirrorı da cacheler. Bu caching transparenttır ve developerın bu özelliği kullanmak için herhangi bir kod yazmasına gerek yoktur.
Database mirroring oturumunun bir uygulama bağlıyken failover gerçekleştirmesi durumunda, bağlantı kesilecek ve connection nesnesi istemciye bir hata mesajı dönecektir. Bu noktada istemcinin sadece yeniden bağlanması gerekecektir ve bu bağlantı sırasında MDAC bağlantıyı otomatik olarak mirror servera yönlendirecektir. Uygulama bu süreçte asıl sunucuya bağlandığını zannedecek ancak aslında bağlandığı farklı bir server olacaktır.
Çalışma Modunun Konfigurasyonu
Database Mirroringin çalışma modunu konfigure etmek için aşağıdaki adımları izleriz:
1. Principal serverda Adventureworks veritabanını sağ tıklayarak Properties à Mirroring ekranını açın.
2. Principal, Mirror ve witness için endpointleri belirleyin. (Bu noktada oluşturduğumuz endpointleri hatırlamıyorsak sys.database_mirroring.endpoints viewı ile endpointleri öğrenebilirsiniz.)
3. Synchronous With Automatic Failover (High Availability) çalışma modunun seçili olduğundan emin olun.
4. Start Mirroring?i tıklayın. Mirroring tamamlandığında OK butonunu tıklayarak ekranı kapatın.
Bu işlem arkaplanda ALTER DATABASE SET PARTNER ve ALTER DATABASE SET WITNESS komutlarını çalıştırmaktadır. Bu işlemi Management Studio?da wizardlar aracılığıyla yapmak yerine T-SQL ifadeleri ile de yapabilirsiniz.
Database Mirroring?in devreye alınması
Database Mirroring oturumunu High Availability modunda konfigure ettimizde principalda gerçekleşecek bir failure mirror sunucunun devreye alınması için otomatik olarak tetikleme gerçekleştirecektir. Ancak ya o anda witness server aktif değilse? Bununla birlikte high performance ve high protection modlarında çalışırken failover işlemini manuel olarak gerçekleştirmemiz gerekir. Bunlardan dolayı database mirroringi uygularken manuel failoverın nasıl yapılacağını mutlaka biliyor olmalıyız.
Failoverı manuel olarak gerçekleştirmek için principal serverda aşağıdaki kodu çalıştırmamız gerekir:
ALTER DATABASE X SET PARTNER FAILOVER
High performance ve high protection modlarında principalda yaşanacak bir failover mirror serverın restoring modunda kalmasına ve transactionlar tarafından erişilemez olmasına neden olacaktır. Bu durumda mirror servera bağlanarak bu serverda manual failover yapmanız gerekir.
Failover nasıl başlatılır?
Failoverın başlatılması için en sık kullanılan yöntem, başlatma işleminin mirror üzerinden gerçekleştirilmesidir ancak veritabanı restoring modunda olduğu için bu işlemi management studio aracılığıyla Database Properties ekranından (veritabanı erişilemez olduğu için) gerçekleştiremeyiz. Management Studioyu kullanarak failover yapabileceğimiz tek senaryo principal veritabanının aktif olduğu durumlardır ki principal online durumdayken failover gerçekleştirmek çok sık karşılaşılacak bir istek olmayacaktır. Sonuç olarak principal online değilken failover işlemini mirror server üzerinden ALTER DATABASE komutu ile gerçekleştirmemiz gerekir. Mirror veritabanı üzerinde çalıştıracağımız ALTER DATABASE komutu aşağıdaki gibidir:
ALTER DATABASE <mirror veritabanı> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
Failoverın manuel tetiklenmesi veri kaybına neden olabilir. Asıl principal erişilebilir değilken database mirroring senaryosunun diğer üyeleri iletişim kuramayacak ve veritabanının senkronizasyonu duracaktır. Asıl principal server yeniden online olana kadar database mirroring oturumu suspend olacaktır.
Burada çok önemli bir not olarak, mirror serverdan manul failover tetikleyeceğimiz zaman witness server mutlaka kapalı ve principal erişilemez durumda olmalıdır.
Database Mirroring?in kaldırılması
Öncelikle database mirroringi neden kaldırmak isteyebiliriz sorusunu cevaplayalım.
Elbette artık ihtiyacımız olmaması database mirroringi kaldırmak istememiz için ilk nedenimiz olabilir. İkinci bir neden olaraksa principal serverın tüm yapının yeniden oluşturmanın daha kolay ve sağlıklı olacağını düşündürecek kadar hasar görmüş olmasını düşünebiliriz.
Database mirroringi principal serverda Database Properties à Mirroring ekranından Stop Mirroring butonunu tıklayarak durdurabiliriz. Bu buton arkaplanda aşağıdaki komutu çalıştıracaktır:
ALTER DATABASE <veritabanı adı> SET PARTNER OFF
Bu yöntemin yerine principal ve mirror veritabanında yukarıdaki komutu ayrı ayrı çalıştırabiliriz.
Database Mirroring?in sunduğu en önemli artı sistemimizde bir sorun olduğunda yedek veritabanının aktif hale gelme süresini son derece azaltan bir yapıya sahip olması ki bu özelliği cluster yapısındaki ayağa kalkma süresini düşündüğümüzde son derece düşük, bir kaç saniye şeklinde niteleyebileceğimiz bir süre.
Makalenin hazırlanması sırasında MSDN, çeşitli SQL Server MOC?u ve kitabı ve tabiki arama motorlarından faydalandım. Pek çok farklı kaynakta konu ile ilgili farklı ayrıntılar yer alıyor ve eminim burada ele almadığım bazı ufak ipuçları olacaktır. Makalede ele alacağımız konuları sıralamak gerekirse;
1. Database Mirroring Nedir?
2. Database Mirroring Mimarisinde yer alan roller
3. Sistemin Database Mirroring?e hazırlanması
4. Endpointlerin oluşturulması
5. Database Mirroring?in devreye alınması
6. Database Mirroring?in kaldırılması
Başlarken
Database Mirroring için herşeyden önce SQL Server 2005?in Standart veya Enterprise Edition sürümlerinden birine ihtiyacımız var. Bu noktada Database Mirroring için 3 ayrı bilgisayar kullanıyor olacağız ki neden 3 bilgisayar var, hangisi ne işe yarayacak ?Database Mirroring Mimarisinde yer alan roller? başlığında bu soruyu detaylı olarak cevaplıyor olacağım. Örnek senaryomuzu AdventureWorks örnek veritabanı üzerinden yapacağımız için bu veritabanının her üç SQL Server kurulumunda da olması gerekmekte.
Son ve önemli madde ise, Database Mirroring?in SQL Server 2005 RTM tarafından desteklenen standart bir özellik olmaması. Database Mirroring SQL Server 2005 Service Pack 1 ile standart olarak desteklenmeye başlamıştır (her ne kadar bu service pack yayınlanmadan önce ufak bir komut ile kullanabiliyor olsak da, resmen desteklenen bir özellik olması daha iyi). Sonuç olarak başlamadan önce SQL Server 2005 Service Pack 1?i yüklememiz gerekiyor.
Database Mirroring Nedir?
Database Mirroring Mimarisinde yer alan roller
Yeni olan her teknoloji gibi Database Mirroringde kendine özgü bazı terimleri hayatımıza taşıyor. Şimdi bu yeni terimleri ve anlamlarını, database mirroringde yer alan rolleri, bu rollerin görevlerini ve birbirleri ile etkileşimlerini ele alalım.
Database Mirroring iki zorunlu, bir opsiyonel rol ile çalışan bir yapıya sahiptir. Veritabanlarından birini ?principal? diğerini ise ?mirror? rolünde tanımlamamız gerekir. Opsiyonel olarak ana veritabanı (principal) devre dışı kaldığında yedek veritabanına (mirror) otomatik olarak geçişi sağlayacak witness server tanımlayabiliriz. Aşağıdaki grafik bu makalede gerçekleştireceğimiz database mirroring yapısının diyagramıdır.
Şekil 1:1 :: Database Mirroring Yapısı
Principal rolünde tanımladığımız veritabanı tüm transactionların kaynağıdır. Uygulamaların veri okuma ve yazma işlemini yapacağı veritabanıdır. Veritabanını bir database mirroring session?ına dahil etmek için full recovery model?i kullanmamız gerekir ki bu konuyu bir sonraki bölümde detaylı olarak ele alıyor olacağız.
Mirror Rolü
Mirror rolünde tanımladığımız veritabanı ana veritabanımızın aynısıdır, ortağıdır ve sürekli olarak principal veritabanından transactionlar alır. Database Mirroring prosesi sürekli olarak ana veritabanında gerçekleşen transactionların loglarını mirror veritabanının transaction log?una ve transaction log?u da data dosyalarına aktarır. Böylece bu mekanizma çalıştığı sürece mirror veritabanı, principal veritabanındakiler ile aynı verilere sahip olacaktır. Mirror veritabanı recovering modunda olduğu için herhangi bir bağlantıyı veya doğrudan yazma işlemini desteklememektedir ancak mirror veritabanından bir database snapshot oluşturarak kullanıcıların bu snapshot sayesinde read-only erişim elde etmelerini sağlayabiliriz.
Witness Server
Witness Server, database mirroring mimarisinin üçüncü ve kullanımı opsiyonel olan rolüdür. Bu serverı otomatik failover tespiti ve yedek veritabanının (mirror) otomatik olarak aktif hale getirilmesi için kullanırız. Witness serverı high availability operating mode?u kullanarak konfigure ederiz. Database Mirroring mimarisinde bir principal?ın sadece tek bir mirror?ı olabiliyorken (aynı şekilde bir mirror sadece tek bir principal?a bağlı çalışabiliyor), witness serber birden çok database mirroring yapısını monitör edebilir. Witness serverın hizmet verdiği her database mirroring yapısı sys.database_mirroring_witnesses catalog view?ında tek bir satırlık bilgi olarak yer alacaktır.
Özetlemek gerekirse witness server oluşturduğumuz database mirroring yapılarını monitör ederek, bir principal?ın devre dışı kalması halinde en kısa sürede mirror veritabanının primary rolüne getirilmesi ve sürekliliğin sağlanmasından sorumludur.
Witness server olarak kullanılacak SQL Server?da herhangi bir SQL Server sürümünü (Express Edition dahil) kullanabilirsiniz.
Veritabanlarının Database Mirroring?e Hazırlanması
Database Mirroringin konfigurasyonunu her veritabanında ayrı ayrı yapmamız gerekiyor. Bu bölümde hazırlık sürecinde yapmamız gerekenleri tek tek ele alacağız. Adımlarımız sırasıyla veritabanlarının full recovery model?da olmasını sağlamak, ana veritabanının yedeğini almak ve mirror sql serverda no recovery ile restore etmek ve son olarak ana veritabanındaki önemli sistem nesnelerini mirror veritabanına taşımak olacak.
Recovery Model
SQL Server veritabanları için üç recovery model sunmaktadır. Bunlar: Simple, Bulk-Logged ve Full. Simple recovery model transaction log?u, her checkpointte aktif olmayan bölümleri silerek yedekler. Bulk-Logged recovery modelda Bulk insert, bcp veya create index işlemlerinin tamamını yedeklemez. Database Mirroring'de hem ana hem yedek veritabanları birbirinin aynısı olacağından ki sadece veri anlamında değil, log sequence numbers gibi iç yapılarında birbirinin aynısı olacağından, simple ve bulk-logged recovery modelleri database mirroring için yetersiz kalacaktır. Bu nedenle database mirroringde kullanabileceğimiz tek recovery model, full recovery model?dır.
Backup ve Restore
Principal ve mirror veritabanları birbirinin kopyası olduğundan, her iki veritabanınında aynı state ile çalıştığından emin olmamızı sağlayacak bir mekanizmaya gereksinim duyarız. Burada initializasyonu yapacak proses principal veritabanının yedeğini alarak mirrora restore edecektir.
Veritabanının mirror?a restore edilmesi sırasında no recovery seçeneğini belirtmemiz çok önemlidir.
Database Mirroring konfigurasyonunda harcanan zamanın büyük bölümünü backup ve restore işlemlerinin aldığını farkedeceksiniz.
Sistem Nesnelerinin Kopyalanması
Database Mirroring veritabanı seviyesinde çalışan bir yapı olduğu için sistemdeki diğer nesneler bizim için önemli değildir ancak sistemi hata sırasında mirror veritabanını otomatik olarak aktif hale getirecek şekilde ayarlayabilecek olsak da, failover sonrasında uygulamaların çalışmaya devam edebilmesini sağlamak için diğer nesnelerinde mirror veritabanına taşınmasını isteyebiliriz.
Burada aklımıza gelecek ilk nesne türü elbette authentication ve authorization işlemlerinde kullanılan login nesneleridir. Login nesnelerine ek olarak lined serverlar, SQL Server Integration Services (SSIS) paketleri, SQL Server Agent jobları, özel hata mesajları ve diğer sunucu nesnelerini taşımak isteyebiliriz. Initialization işleminin son adımı bu nesnelerin kopyalanması olacak.
Örnek Senaryomuz
Makale boyunca sürdüreceğim örnekte masamdaki 3 pc?yi kullanıyor olacağım. Bu bilgisayarların networkteki isimleri ise aşağıdaki gibi. Database Mirroring senaryosundaki rol, makina adı, ip adresi:
- Principal: 192.168.170.82
- Mirror: 192.168.170.71
- Witness: 192.168.170.74
1. *82 ipli bilgisayarda yer alan adventureworks veritabanının yedeğini alarak işe başlıyoruz.
2. Aldığımız bu backup?ı no recovery seçeneği ile mirror veritabanının yer alacağı *74lü bilgisayara restore ediyoruz.
Endpoint?lerin Oluşturulması
SQL Server 2005, önceki sürümlere ve diğer rdms ürünlerine kıyasla çok daha güçlü, çok katmanlı bir güvenlik modeli sunmaktadır. Güvenliğin ilk katmanı bağlantı noktasında yer almaktadır. Endpointler ise instace?ın bağlantılarını yönetmektedir. Database Mirroring üç SQL Server 2005 instanceının iletişimine dayandığı için, bu instancelar arasında iletişimin sağlanması için endpointleri oluşturmamız gerekiyor.
Endpoint Türleri
SQL Server 2005?te iki farklı endpoint türü oluşturabiliriz: TCP veya HTTP. Database Mirroring'de iletişim için TCP endpoint kullanılırken, SOAP taleplerinin karşılanmasında HTTP Endpointler kullanılır.
Endpoint tür tanımlaması sırasında bir de payload belirtmeniz gerekir. TCP endpointler TSQL, SERVICE_BROKER veya DATABASE_MIRRORING türünden payload alabilir. Bir database mirroring oturumu için TCP endpointi DATABASE_MIRRORING payloadı ile oluştururuz. Payload?ı SQL Server?da instance seviyesinde oluştururuz, böylece her sql server instance?ında DATABASE_MIRRORING payloadı olan tek bir endpoint oluşturmamız yeterli olur.
Endpoint Güvenliği
Endpointler ihtiyaçlarımız doğrultusunda özelleştirebileceğimiz çok katmanlı bir güvenlik yapısı sunar. Güvenliğin ilk katmanı tür ve payload tanımlamasıdır. Database Mirroring için bir endpoint oluşturduğumuzda, bu endpoint database mirroring talepleri dışındaki talepleri cevaplamayaz ve HTTP, TSQL ve Service Broker taleplerini reddeder.
Güvenliğin ikinci katmanı, endpointin TCP konfigurasyonudur. Her TCP endpoint için bir port numarası belirtmemiz gerekir. TCP endpointlerde varsayılan port numarası 5022dir. Daha sonra TCP Endpoint için Listener IP belirtiriz. TCP Endpointler varsayılan olarak tüm geçerli IP adreslerinden gelen talepleri (ALL seçeneği) kabul ederler. Bu noktada sadece belirli bir ip adresinin talepleri dinlemesini sağlayabiliriz. Standart port numarası yerine farklı bir port numarası belirtmek güvenlik açısından faydalı bir önlem olacaktır.
Üçüncü ve dördüncü güvenlik katmanlarımız authentication metodu ve encryption seçeneğidir. Windows tabanlı kimlik doğrulama ve sertifikaları kullanabiliriz. Windows tabanlı kimlik doğrulama için NTLM, KERBEROS veya NEGOTIATE seçeneğini seçeriz. NEGOTIATE seçeneği instanceların authentication metodunu otomatik olarak seçmesini sağlar.
Endpointler arasındaki tüm iletişim şifrelenebilir ve şifreleme için hangi algoritmanın kullanılacağını seçebiliriz. Şifreleme için kullanılacak varsayılan algoritma RC4?tür ancak RC4?e göre çok daha güçlü bir alternatif olan AES algoritmasını da kullanabiliriz.
Şifreleme konusunda AES alternatifi kullanmamız halinde daha güçlü şifreleme elde edeceğimiz doğrudur ancak şifreleme için harcanacak kaynaklar artacak ve göze alınabilir oranda da olsa performans düşüşü olacaktır.
Güvenliğin Beşinci ve altınca katmanlarına gelecek olursak; bir bağlantının kurulabilmesi için endpointe CONNECT yetkisinin verilmesi gerekir. Ek olarak endpointin state özelliğini STARTED olarak belirlememiz gerekir. STOPPED veya DISABLED durumundaki bir endpoint her bağla ntı talebine bir hata mesajı ile cevap verecektir.
Database Mirroring Endpoint Türü
Database Mirroring desteği veren endpointler, TCP endpointlerin özelleştirilmiş bir versiyonudur ve aşağıdaki özelliklere sahiptir:
- TCP endpoint türü
- DATABASE_MIRRORING payload türü
- Her bir SQL Server Instance?ı için tek bir Database Mirroring endpointi desteklenir.
Database Mirroring endpointleri güvenliğin yedinci katmanını ROLE seçeneği ile sağlar. Bir endpointi PARTNER, WITNESS veya ALL olarak tanımlayabiliriz. PARTNER olarak tanımladığımız endpointler sadece principal veya mirror olabilir, WITNESS olarak tanımladığımız endpointler ise sadece WITNESS olarak rol alabilir. Bir endpointi ALL şeklinde tanımlarsak, her üç rolün özelliklerinide destekler.
Burada dikkat etmemiz gereken bir nokta olarak; SQL Server 2005 Express Editionda sadece WITNESS endpoint türünün desteklendiğidir. Dolayısıyla Express Edition?u mirror veya principal rolünde kullanamayız.
Database Mirroring Endpointi Oluşturmak İçin;
Aşağıdaki T-SQL ifadesini, database mirroring endpointi oluşturmakta kullanacağız:
CREATE ENDPOINT [Mirroring] AS TCP (LISTENER_PORT = 2012)
FOR DATA_MIRRORING (ROLE=PARTNER, ENCRYPTION = REQUIRED);
ALTER ENDPOINT [Mirroring] STATE = STARTED;
Bu kod 2012 numaralı porttan database mirroring servisi veren bir endpoint oluşturacaktır. PARTNER rolünde olduğu için bu endpoint kendi instanceı üzerindeki veritabanlarının RC4 şifreleme algoritması kullanarak sadece principal veya mirror rolünde bulunmasına izin verecektir.
Database Mirroringi SQL Server Management Studio ile, database properties ekranında, mirroring bölümünden konfigure ederiz. Bu ekranda Configure Database Mirroring Security Wizard?ı çalıştıracak olan Configure Security?i tıklarız. Bu wizardda yer alan adımları tamamladığımızda wizard database mirroring senaryosuna dahil ettiğiniz tüm SQL Server instancelarında iki adet CREATE ENDPOINT ve ALTER ENDPOINT ifadesi çalıştırır.
Şimdi senaryomuza geri dönerek endpointleri oluşturalım:
İlk olarak principal sunucumuzu konfigure ederek başlıyorum.
3. Principal olarak kullanacağımız SQL Server?a bağlanıyoruz. (Senaryomuzda bu sunucu tfs adlı bilgisayar)
4. Adventureworks veritabanını sağ tıklayarak Properties ekranını açıyoruz.
5. Mirroring ekranını açıyoruz.
6. Configure Database Mirroring Security Wizard?ı çalıştırmak için Mirroring ekranında yer alan Configure Security butonunu tıklıyoruz. Şimdi üç database mirroring rolü için endpoint tanımlamalarını yapacağız.
7. ?Include Witness Server? ekranında (wizardın ikinci adımı) Yes seçeneğini işaretliyoruz. Bunu yaparak database mirroring senaryomuzda bir witness server olacağını belirtmiş olduk.
8. ?Choose Servers to Configure? ekranında Principal Server seçeneği pasif durumdadır (bu wizardı principal serverdan çalıştırdığımız varsayılmasından kaynaklanmaktadır). Bu ekrandaki Mirror ve Witness server seçeneklerinide işaretleyerek Next butonunu tıklıyoruz.
9. ?Principal Server Instance? ekranında Principal Server instance?ı zaten seçilmiş durumdadır. Listener Port alanında kullanmak istediğimiz port numarasını, Endpoint Name alanında ise kullanacağımız endpoint için bir isim belirtiyoruz. Burada veri iletişiminin daha güvenli olmasını sağlamak için ?Encrypt data sent through this endpoint? seçeneğini de işaretliyoruz ve Next butonunu tıklıyoruz.
10. ?Mirror Server Instance? ekranında Connect butonunu tıklayarak mirror veritabanının bulunduğu SQL Server instance?ını ve bağlanmak için gerekli kullanıcı bilgilerini belirtiyoruz. Bu işlem mirror ile olan bağlantıyı oluşturacaktır. Kullanılacak port numarasını belirttikten sonra ?Encrypt data sent through this endpoint? seçeneğini yine işaretliyor ve Next butonunu tıklıyoruz.
11. ?Witness Server Instance? ekranında bir önceki adımda yaptığımız işlemleri witness server için gerçekleştiriyoruz.
12. ?Service Accounts? ekranında servislerin kullanacağı accountları belirtiyoruz. Bu seçenek opsiyoneldir. Tüm endpointlerde SQL Server servisi aynı servis accountu ile çalışıyorsa bu adımda yapmamız gereken herhangi bir şey yoktur. Farklı accountlar kullanıyorsak, gerekli değişiklikleri yaparak Next butonunu tıklıyoruz.
13. Complete Wizard ekranında yaptığımız seçimleri gözden geçirebilir, gerekli durumlarda geri dönerek seçimlerimizi değiştirebiliriz.
14. Finish butonunu tıkladığımızda Configuring Endpoints ekranı çıkar. Konfigurasyon durumunda oluşabilecek hata ve uyarıları buradan görebilirsiniz. Herşeyin yolunda gitmesi durumunda 3 adımda Success şeklinde sonuçlanır.
15. Endpoint konfigurasyonu tamamlandığında bir uyarı diyaloğu, Mirroringi manuel olarak başlatmamız gerekiyor. Database Mirroringi çıkan uyarı diyaloğu aracılığıyla veya Database Properties ekranında Mirroring ekranından başlatabiliriz. (ben Start Mirroring butonunu tıklayarak mirroringi hemen başlatıyorum)
Database Mirroring'de Desteklenen Çalışma Modları
Database Mirroring?i üç farklı çalışma modunda çalıştırabiliriz. Bunlar: High Availability, High Performance ve High Protection. Çalışma modu transactionların principal ve mirror veritabanları arasındaki iletişimini belirler. Bu başlık altında desteklenen çalışma modlarını, artı ve eksilerini ve database mirroring?in caching ve transparent client redirect özelliğini ele alıyor olacağız.
High Availability Operating Mode
Sql Server tüm transactionları öncelikle SQL Server için rezerve edilmiş olan bellek alanına yazar. Sistem daha sonra bellekte yer alan bu bilgileri transaction loga kaydeder ve sonrasında transaction logları baz alarak data dosyalarında gerekli ekleme/güncelleme/silme işlemlerini gerçekleştirir. SQL Server transaction loga bir transaction yazdığında, sistem database mirroringi transaction logları mirrora aktarması için tetikler. Uygulama transaction için bir commit komutu gönderdiğinde transaction önce mirror veritabanına işlenir, sonrasında principala, principal veritabanında commit işlemine izin veren bir bilgi mesajı gönderilir. Bu proses tüm transactionların hem principal hem de mirror veritabanının transaction loglarında yer almasını garanti eder.
Transaction hem principal hem de mirror veritabanının transaction loguna işlenmediği sürece SQL Server commit işleminin başarıyla tamamlandığını varsaymadığı için High Availability operating mode performans açısından en verimli çalışma modudur diyemeyiz ki Principal ve Mirror instanceları arasındaki fiziksel mesafeye orantılı olarak performans artacak veya azalacaktır.
High Availability operating mode failureları otomatik olarak tespit ederek mirror instanceı devreye almak için bir witness severa gereksinim duyar. Her ne kadar witness server principal serverın çalışıp çalışmadığını ping ile tespit etse de, bir veritabanı pek çok nedenden dolayı (aktif olmasına rağmen) erişilemez durumda olabilir. Database Mirroring bu gibi durumları failure olarak algılamaz. Sadece ping işleminin sonucu başarısız dönerse, mirror sunucuyu devreye alır.
Bir failure durumunda Database Mirroring principal ve mirror veritabanının rollerini ve aynı zamanda transaction logları değiştirir. Özellikle transaction logların da değiştiriliyor olması süreklilik açısından replikasyon ve log shippinge göre çok büyük bir artıdır.
Otomatik failover işleminde mirror veritabanı principal veritabanı olarak hizmet vermeye başlar ancak öncesinde witness serverın failovera karar vermesi ve principal ile mirror serverların rollerini değiştirmesi gerekir. Principal serverın fail olması ve mirror serverın witness servera bağlanamaması durumundaysa SQL Server mirror serverı principal olarak konfigure edemeyecektir.
Mirror serverın veritabanı servisi verip vermeyeceğine kendi karar verecek şekilde konfigure edilmişse, bir veritabanının birden fazla sunucu üzerinde erişilebilir halde olması (split-brain) gibi bir durumla karşılaşabiliriz.
High Availability Operating Mode failover sırasında aşağıdaki adımları izler.
1. Principal ve mirror serverlar sürekli olarak birbirlerine ping gönderir.
2. Witness server sürekli olarak principal ve mirror sunucularına ping gönderir.
3. Principal bir nedenden dolayı erişilemez hale gelir.
4. Mirror failure?ı tespit eder ve witness servera principal olarak hizmet vermek için talepte bulunur.
5. Witness principal servera ping gönderemiyorsa ancak mirror servera gönderebiliyorsa witness rollerin değişimine karar verir ve mirror serverı principal, principal serverı mirror server olarak konfigure eder.
6. Principal server tekrar aktif hale gelir ve mirror serverın principal olarak çalıştığını tespit eder.
Witness serverın bu süreç sırasında offline olması durumunda otomatik failover gerçekleşmeyecektir.
High Performance Operating Mode
Database Mirroring?in high performance operating modu principal ve mirror serverları kullanırken, witness servera gereksinim duymaz. Bu çalışma modu otomatik failover tespitini ve failoverı mümkün kılmayan warm standby konfigurasyonu sunar.
High performance operating mode uygulamanın transactionlarının mirror servera asenkron olarak iletilmesinden dolayı otomatik failoverı desteklemez. Transactionlar principal veritabanına commit edilir ve uygulamaya bilgi gönderilir. Ayrı bir proses ise transactionları mirrora aktarır ki bu işlem gecikmeye neden olur ve proses SQL Server?ın tüm transactionları mirrora aktardığından emin olamayacağı için database mirroring oturumunun otomatik failover yapmasına izin vermez.
Transfer asenkron olduğundan, high performance operating mode uygulamanın performansını etkilemez ve principal ve mirror sunucular arasındaki mesafe, sistemin performansını daha az etkiler. Ancak bu çalışma modu gecikmeyi arttırır ve primary veritabanının fail olması halinde daha yüksek veri kaybına neden olabilir.
High Protection Operating Mode
High protecting operating mode, high availability operating mode ile hemen hemen aynı özelliklere sahipken witness server konfigurasyonu yapılmaması ile bu moddan ayrılır. SQL Server transactionları principal ve mirror arasında senkron olarak transfer eder ancak (witness server olmadığı için) failover, manuel gerçekleştirilmek zorundadır.
High protection çalışma modunun senkron transferi uygulama performansını etkilerken otomatik failover desteği sunmamasından dolayı bu çalışma modunun sadece mevcut witness serverın değiştirilmesi gerektiği durumlarda kullanılması, değişiklik sonrasında çalışma modunu tekrar high availability operating mode?a dönüştürmeniz önerilir.
Transparent Client Redirection
Log shipping ve replikasyon kullanırken karşılaştığımız en büyük sorun uygulama bağlantılarıydı. Birincil sunucu devre dışı kaldığı için uygulamalar çalışmaya devam edebilmeleri için ikinci sunucuya yönlendirilmeliler. Database mirroring bu sorunu farklı bir çözüm ile ortadan kaldırmaktadır.
Visual Studio 2005 ile gelen yeni MDAC sürümü database mirroringe özgü, Transparent Client Redirect adında bir connection nesnesi sunar. Principala bir bağlantı yapıldığında connection nesnesi principal ile birlikte mirrorı da cacheler. Bu caching transparenttır ve developerın bu özelliği kullanmak için herhangi bir kod yazmasına gerek yoktur.
Database mirroring oturumunun bir uygulama bağlıyken failover gerçekleştirmesi durumunda, bağlantı kesilecek ve connection nesnesi istemciye bir hata mesajı dönecektir. Bu noktada istemcinin sadece yeniden bağlanması gerekecektir ve bu bağlantı sırasında MDAC bağlantıyı otomatik olarak mirror servera yönlendirecektir. Uygulama bu süreçte asıl sunucuya bağlandığını zannedecek ancak aslında bağlandığı farklı bir server olacaktır.
Çalışma Modunun Konfigurasyonu
Database Mirroringin çalışma modunu konfigure etmek için aşağıdaki adımları izleriz:
1. Principal serverda Adventureworks veritabanını sağ tıklayarak Properties à Mirroring ekranını açın.
2. Principal, Mirror ve witness için endpointleri belirleyin. (Bu noktada oluşturduğumuz endpointleri hatırlamıyorsak sys.database_mirroring.endpoints viewı ile endpointleri öğrenebilirsiniz.)
3. Synchronous With Automatic Failover (High Availability) çalışma modunun seçili olduğundan emin olun.
4. Start Mirroring?i tıklayın. Mirroring tamamlandığında OK butonunu tıklayarak ekranı kapatın.
Bu işlem arkaplanda ALTER DATABASE SET PARTNER ve ALTER DATABASE SET WITNESS komutlarını çalıştırmaktadır. Bu işlemi Management Studio?da wizardlar aracılığıyla yapmak yerine T-SQL ifadeleri ile de yapabilirsiniz.
Database Mirroring?in devreye alınması
Database Mirroring oturumunu High Availability modunda konfigure ettimizde principalda gerçekleşecek bir failure mirror sunucunun devreye alınması için otomatik olarak tetikleme gerçekleştirecektir. Ancak ya o anda witness server aktif değilse? Bununla birlikte high performance ve high protection modlarında çalışırken failover işlemini manuel olarak gerçekleştirmemiz gerekir. Bunlardan dolayı database mirroringi uygularken manuel failoverın nasıl yapılacağını mutlaka biliyor olmalıyız.
Failoverı manuel olarak gerçekleştirmek için principal serverda aşağıdaki kodu çalıştırmamız gerekir:
ALTER DATABASE X SET PARTNER FAILOVER
High performance ve high protection modlarında principalda yaşanacak bir failover mirror serverın restoring modunda kalmasına ve transactionlar tarafından erişilemez olmasına neden olacaktır. Bu durumda mirror servera bağlanarak bu serverda manual failover yapmanız gerekir.
Failover nasıl başlatılır?
Failoverın başlatılması için en sık kullanılan yöntem, başlatma işleminin mirror üzerinden gerçekleştirilmesidir ancak veritabanı restoring modunda olduğu için bu işlemi management studio aracılığıyla Database Properties ekranından (veritabanı erişilemez olduğu için) gerçekleştiremeyiz. Management Studioyu kullanarak failover yapabileceğimiz tek senaryo principal veritabanının aktif olduğu durumlardır ki principal online durumdayken failover gerçekleştirmek çok sık karşılaşılacak bir istek olmayacaktır. Sonuç olarak principal online değilken failover işlemini mirror server üzerinden ALTER DATABASE komutu ile gerçekleştirmemiz gerekir. Mirror veritabanı üzerinde çalıştıracağımız ALTER DATABASE komutu aşağıdaki gibidir:
ALTER DATABASE <mirror veritabanı> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
Failoverın manuel tetiklenmesi veri kaybına neden olabilir. Asıl principal erişilebilir değilken database mirroring senaryosunun diğer üyeleri iletişim kuramayacak ve veritabanının senkronizasyonu duracaktır. Asıl principal server yeniden online olana kadar database mirroring oturumu suspend olacaktır.
Burada çok önemli bir not olarak, mirror serverdan manul failover tetikleyeceğimiz zaman witness server mutlaka kapalı ve principal erişilemez durumda olmalıdır.
Database Mirroring?in kaldırılması
Öncelikle database mirroringi neden kaldırmak isteyebiliriz sorusunu cevaplayalım.
Elbette artık ihtiyacımız olmaması database mirroringi kaldırmak istememiz için ilk nedenimiz olabilir. İkinci bir neden olaraksa principal serverın tüm yapının yeniden oluşturmanın daha kolay ve sağlıklı olacağını düşündürecek kadar hasar görmüş olmasını düşünebiliriz.
Database mirroringi principal serverda Database Properties à Mirroring ekranından Stop Mirroring butonunu tıklayarak durdurabiliriz. Bu buton arkaplanda aşağıdaki komutu çalıştıracaktır:
ALTER DATABASE <veritabanı adı> SET PARTNER OFF
Bu yöntemin yerine principal ve mirror veritabanında yukarıdaki komutu ayrı ayrı çalıştırabiliriz.
