SQL Server ASP.NET C# Kitabı

SQL Server 2005, sistemin sürekliliği için sunduğu yöntemlerden biri de Database Mirroring yöntemidir. Service Pack 1 ile birlikte sunulmuş olan bu yöntem iki sunucu arasında log transaction kayıtlarını taşıyarak bu sunucuların senkronize olmasını sağlar. Database Mirroring, standard, enterprise veya developer sürümleri tarafından desteklenir. Bu yazıda bu modelin nasıl kurulacağını örneklendireceğiz.

Database Mirroring modelini önemli kılan özellikleri şunlardır;

• Tam yedekleme yaparak ikinci sunucunun daima hazır olmasını saÄŸlar.(Hot standby)
• Sistemde bir hatanın oluÅŸması durumunda otomatik geçiÅŸ (automatic failover) zamanın kısa olmasıdır.
• Database failover’da veri kaybının yok denecek kadar az olması
• Standart sunucular ve depolama aygıtlarıyla birlikte çalışır.

Database mirroring modelinde principal (ana veritabanı), mirror (yedek veritabanı) ve witness (şahit sunucu) olmak üzere aktör bulunur. Principal ve mirror sunucuları zorunlu witness sunucusu ise seçmeli olarak kurulur. Principal rolündeki sunucu merkezi sistem olup ana transactionların çalıştırıldığı yerdir. Bu sunucu üzerinde çalışan her transaction mirror servisi tarafından mirror rolündeki yedek sunucu üzerinde de çalıştırılır. Böylece her iki sunucu veri ve şema anlamında eşleşmiş olur. Witness rolündeki sunucu ana ve yedek sunucuların ayakta olup olmadığını kontrol eden, ana sunucu devre dışı olduğu zaman sistemi yedek sunucuya otomatik olarak geçiren bağımsız bir sunucudur. Herhangi bir SQL Server sürümünü witness sunucu olarak kullanabiliriz. Witness sunucu birden fazla mirroring oturumuna destek verebilir. Aşağıdaki şekilde bu temel kavramlar ve gerektiğinde automatic failover sürecinin nasıl gerçekleşeceği gösterilmiştir.

Database mirroring modelinde sadece bir principal ve ona ait bir mirror veritabanı/sunucu olabilir.

Database mirroring işlemi veritabanı bazında yapılır. Hangi veritabanının yedeği alınacaksa öncelikle recovery modelini full olarak işaretlemeliyiz. Diğer önemli adım diğer yöntemlerde olduğu gibi SQL Server Agent kullanıcı yetkilerini uygun şekilde düzenlemeliyiz. Örnek senaryomuzda aynı makine üzerinde koşan üç sunucuyu kullanacağız.
Principal: AHMETKAYMAZ\AHMETKAYMAZ1
Mirror: AHMETKAYMAZ\AHMETKAYMAZ2
Witness: AHMETKAYMAZ

AHMETKAYMAZ1 sunucu üzerindeki KAYNAK veritabanını AHMETKAYMAZ2 üzerinde yedekleyeceÄŸiz. Bunun için ilk adım olarak kaynak veritabanının full backup’ını alıp karşı makineye restore etmemiz gerekir. Yedek alma iÅŸlemini Management Studio üzerinden yapabileceÄŸimiz gibi T-SQL Script ile de yapabiliriz.

BACKUP DATABASE Kaynak TO DISK='C:\Kaynak_full.BAK'

İkinci adım olarak bu full backup karşı makineye restore edeceğiz. Aynı şekilde işlemi Management Studio üzerinden yapabileceğimiz gibi T-SQL script ile de yapabiliriz. Bizim senaryoda tüm sunucular aynı makine üzerinde olduğu için ikinci sunucuda mdf ve ldf dosyalarına farklı bir konum vermek gerekir.

RESTORE DATABASE Kaynak
	FROM DISK='C:\Kaynak_full.BAK' WITH NORECOVERY,
		MOVE 'Kaynak' TO 'C:\Kaynak.mdf',
		MOVE 'Kaynak_Log' TO 'C:\Kaynak.ldf'

Database Mirroring modelinde baÅŸlangıç adımı olarak kaynak veritabanına ait full backup’tan sonra bir log backup’ın yedek sunucuya restore edilmesi gerekir. Bunun için full backup sonrası bir log backup alalım.

Backup Log Kaynak to Disk='C:\Kaynak_log.bak'

Bu log backup yedek sunucuya restore edelim.

Restore Log Kaynak from Disk='C:\Kaynak_log.bak' with NORECOVERY

Burada dikkat edilemesi gereken konu yedekler yedek sunucuya NORECOVERY seçeneÄŸiyle restore edilmesidir. Bu da çalışma anında yedek sunucu üzerinde sorgulama yapılamayacağı anlamına geliyor. Bu özellike mirroring’in diÄŸer yöntemlere göre bir dejavantajı olarak karşımızı çıkmaktadır.

Modeldeki sunucuların rollerini tanımlamadan önce Endpoint’leri tanımlamamız gerekir. SQL Server 2005′te EndPoint (Uç Nokta) kavramı harici kaynaklar ile SQL Server arasındaki iletiÅŸimi güvenlik kılmak için oluÅŸturulan bir yönetim mekanizmasıdır. Endpoint, uzaktan eriÅŸilen sunucunun içerdeki bir yordamı güvenli bir ÅŸekilde çağırmasını saÄŸlar.

SQL Server üzerinde TCP ve HTTP olmak üzere iki tür endpoint yaratılabilir. TCP endpoint’ler, database mirroring iletiÅŸimi için kullanılırken HTTP point’ler SOAP tabanlı talepler için kullanılır. SQL Server 2005′in XML web servisi desteÄŸi HTTP endpoint’ler aracılığıyla gerçekleÅŸir. Sunucu üzerindeki Http dinleyicisi (Http Listener – HTTP.sys) gelen talepleri SQL Server üzerinde tanımlı endpoint’lere iletir. Endpoint’ler aracılığıyla SQL Server 2005 üzerindeki bir function veya stored procedure’in http üzerinde gelen talepleri yanıtlanması saÄŸlanmıştır. Bir endpoint oluÅŸturulurken baÅŸlangıç durumu (Started, Stoped veya Disabled), hangi iletiÅŸim protokolü (Tcp, Http) üzerinden servis vereceÄŸi, dışarıdan eriÅŸim için url adresi ve portu, endpoint’in yer aldığı veritabanı gibi bilgiler baÅŸta belirtilir. Endpoint nesneleri diÄŸer nesneler gibi CREATE, ALTER, DROP ifadeleriyle yönetilir. Endpoint’lerle ilgili ek parametreler için “CREATE ENDPOINT” ifadesini bakılabilir. Her Bir SQL Server sunucu için tek bir database mirroring endpoint’i oluÅŸturulabilir. Konumuza tekrar dönecek olursak ana sunucu için Kaynak veritabanı üzerinde bir endpoint tanımlayalım.

Create Endpoint Mirroring_Endpoint
	State= Started as TCP (Listener_Port=5001)
	For Database_Mirroring (Role=Partner);

Aynı komutu yedek sunucu üzerinde de çalıştıralım. Burada dikkat edilmesi gereken konu mirror, principal ve witness noktaları aynı sunucu üzerinde tanımlı olacaksa her birinin hizmet verdiği portun farklı olması gerekir. Bu yüzden principal için 5001, mirror için 5002 ve witness için 5003 portunu girelim. Witness rolündeki sunucu için yukarıdaki komutu (Role=Partner) ifadesini (Role=Witness) ile değiştirerek çalıştıralım.

Create Endpoint Mirroring_Endpoint
	State= Started as TCP (Listener_Port=5003)
	For Database_Mirroring (Role=Witness);

Bu ifadeyle birlikte her sunucu üzerinde o sunucunun rolüne uygun olarak 5001 portunda hizmet veren bir endpoint tanımlanmış oldu. Bir endpoint’in aynı anda mirror, principal ve witness olarak çalışabilmesi için yukarıdaki komutta (Role=ALL) olarak tanımlanmalıdır. Sunucu üzerinde tanımlı endpoint bilgileri sys.endpoints, sys.database_mirroring_endpoints, sys.http_endpoints, sys.tcp_endpoints, sys.soap_endpoints katalog tablolarında tutulur. Tanımlı olan endpoint’i kaldırmak için aÅŸağıdaki satır kullanılır.

Drop Endpoint 

Sonraki adım olarak sunucuların dışarıdan gelecek istekleri dinleyecek protokol ve portlarını tanımlıyoruz. Sunucular üzerinde database mirroring oturumlarını başlatmak için aşağıdaki komut kullanılır. Öncelikle yedek sunucu üzerinde database mirroring session açalım. Yedek sunucuda aşağıdaki satırı çalıştıralım.

ALTER DATABASE [Kaynak]
SET PARTNER = N'TCP://Ahmetkaymaz:5001'

Ardından ana sunucuya geçip bu sunucu üzerinde oturumu başlatalım.

ALTER DATABASE [Kaynak]
Set Partner= 'TCP://Ahmetkaymaz:5002';

EÄŸer bu iÅŸlemler esnasında Database “Kaynak” is not configured for database mirroring. hata mesajıyla karşılaşırsak iÅŸlemleri buradaki sıralamaya uygun yapmadığımız anlamına gelir.

Üçüncü adım olarak witness server üzerinde oturumu başlatalım. Ana sunucu üzerinde aşağıdaki komutu çalıştırarak mirroring modelinde kimin şahitlik yapacağını bildirelim.

ALTER DATABASE [Kaynak]
SET WITNESS = N'TCP://Ahmetkaymaz:5003'

Bu komutla birlikte Kaynak veritabanını ve diğer sunucuları database mirroring için yapılandırmış olduk.

EÄŸer bu aÅŸamada “Database mirroring is disabled by default. Database mirroring is currently provided for evaluation purposes only and is not to be used in production environments . . .” hata mesajı alınırsa sunucunun üzerinde SP1′in kurulu olmadığı anlamına gelir. SQL Server 2005 RTM sürümü (9.0.1399) varsayılan olarak database mirroring iÅŸlemine kapalıdır. EÄŸer “Database Mirroring Transport is disabled in the endpoint configuration.” hata mesajı oluÅŸursa sunucu üzerinde mirroring endpoint’lerin yaratılmadığı anlamına gelir.

Sunucular üzerinde mirroring oturumlarını açtığımız için otomatik olarak mirroring işlemi başlatılmış olur. Nitekim Management Studio içerisinde ana ve yedek sunucuların durumları aşağıdaki gibi görünür.

Database mirroring geçici olarak durdurmak için aşağıdaki komut yapısı kullanılır.

ALTER DATABASE [Kaynak] SET PARTNER SUSPEND

Süreci kaldığı yerden devam ettirmek için aşağıdaki komut yapısı kullanılır.

ALTER DATABASE [Kaynak] SET PARTNER RESUME

Bundan böyle ana veritabanı üzerinde yapılan değişiklikler otomatik olarak yedek sunucuya da gönderilir. Witness sunucu kısa aralıklar her iki sunucunun ayakta olup olmadığını denetler. Herhangi bir şekilde ana sunucunun erişilmemesi durumunda yedek sunucuyu devreye sokar ve ona principal rolünü verir. Özellikle Witness sunucunun erişilmedi durumlarda otomatik geçişini manual yapmak gerekebilir. Bunun için birinci sunucuda aşağıdaki komut satırı kullanılır.

ALTER DATABASE Kaynak SET PARTNER FAILOVER

Bu durumda ana veritabanı ikinci sunucu üzerine geçirilmiş olur. Nitekim Management Studio içerisinden baktığımızda rollerin değiştiğini görebiliriz.

Aynı senaryoyu birinci sunucunun SQL Server servisini durdurarak ta gerçekleştirebilirdik.

Burada failover işlemini principal veritabanı üzerinde başlattık. Fakat bazı durumlarda bu veritabanı erişilemiyor olabilir. Bu durumda failover işlemini mirror veritabanı üzerinden başlatmak daha doğru olacaktır. Bunun için de aşağıdaki komut satırı kullanılır.

ALTER DATABASE Kaynak SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Aslında eğer ortada bir witness sunucu varsa telaşlanmamıza gerek yok çünkü ana veritabanının failure olması durumunda yedek sunucu otomatik olarak tetiklenecektir. Eğer witness sunucu yoksa veya aktif değilse o zaman geçiş işlemini önceki iki komutla manual yapmak gerekir.

Åžu ana kadar komut sistemiyle anlattığımız tüm iÅŸlemler Management Studio aracında görsel olarak daha kolayca hazırlanabilir. Bunun için yapılması gereken ÅŸey backup ve restore iÅŸlemlerini yaptıktan sonra ana veritabanını saÄŸ tıklayıp “Tasks » Mirror” menüsüyle Properties penceresindeki Mirroring bölümünü açmaktır.

Bu bölümde database mirroring ayarları, durumu görülebilir ve gerekirse durdurma, baÅŸlatma, failover gibi iÅŸlemler buradan yapılır. Bu penceredeki “Configure Security” düğmesi tıklanarak yoksa endpointler ve roller tanımlanır. Tanımlanmış olan roller penceredeki “Server network addresses” bölümünde listelenir.

Database mirroring bu penceredeki “Stop Mirroring” düğmesiyle kapatılabileceÄŸi gibi aÅŸağıdaki komut satırıyla da iptal edilebilir.

ALTER DATABASE [Kaynak] SET PARTNER OFF

Database Mirroring Çalışma Modları

Database mirroring yönteminin High Performance (Yüksek Performans), High Availability (Yüksek Erişilebilirlik) ve High Protection (Yüksek Koruma) olmak üzere üç temel operasyon modeli mevcuttur.

High performance (asynchronous) Witness sunucuya gerek duyulmayan bu modelde transactionlar öncelikle ana veritabanı üzerinde commit edilir ardından baÅŸka bir proses tarafından yedek sunucu tarafına transfer edilir. Yani birinci sunucu kendisi üzerinde çalıştırılan bir transaction’nın yedek sunucuda da commit edilmesini beklemez hatta ondan haberdar olmaz. Asekron çalışması bu demektir. Performansın önemli olduÄŸu bu modelde otomatik geçiÅŸ iÅŸlemi sunulmaz yalnızca manual failover yapılabilir bu yüzden principal sunucu eriÅŸilemez olduÄŸu zaman mirror sunucuya ancak warm standby (read-only) olarak eriÅŸilebilir. Database yöneticisi mirror sunucunun yukarıda bahsettiÄŸimiz komutları kullanarak rolünü deÄŸiÅŸtirmelidir. Ayrıca transactionlar asenkron iÅŸlendiÄŸi için ana veritabanının fail olması durumunda veri kaybı fazla olabilir.

High safety without automatic failover (synchronous)/High-Protection Önceki modelden farkı bu modelde tüm commit edilmiş transactionların mirror sunucunun diskine de yazıldığı garanti edilir. Transactionlar mirror sunucu tarafında onaylandıktan sonra birinci sunucu tarafında onaylanır. Aynı şekilde bir witness sunucu bulunmaz ve principal sunucu erişilemez olduğu zaman mirror sunucu da fakat kendisine warm standby olarak erişilebilir.

High safety with automatic failover (synchronous)/High-Availability Önceki model ile aynı olup tek farkı bir witness sunucunun olmasını zorunlu kılması ve bunun sayesinde automatic failover desteğini vermesidir. Yüksek erişim sunan bu modelde aynı şekilde tüm transactionlar hem principal hem de mirror üzerinde commit edilir. Ana sunucunun erişilemez olması durumunda witness sunucu yedek sunucuya otomatik olarak geçiş yapar. Bu seçeneğin seçilmesi durumunda Replikasyon ve Log Shipping yöntemlerine göre daha yüksek bir erişilebilirlik sağlanmış olur.

Bu seçenekler en son ÅŸekilde verilmiÅŸ olan “Database Properties” penceresindeki Mirroring bölümünden seçilebilir. Sunucuları düzenlerken Witness server seçmemiz otomatik olarak “High-Availability” modelini seçtirir.

Transparent Client Redirect (Şeffaf İstemci Yönlendirme)

Transparent Client Redirect, Database Mirroring ile iliÅŸkili bir özellik olup primary sunucu eriÅŸilemez olduÄŸu zaman istemcilerin otomatik olarak mirror sunucuya yönlendirilmesini saÄŸlar. SQL Server 2005 MDAC’e eklenmiÅŸ olan bu özellik sayesinde istemcinin veri eriÅŸim katmanında herhangi bir kod deÄŸiÅŸikliÄŸi yapılmaya gerek kalmamaktadır. Ä°lk principal baÄŸlantısında istemci kütüphanesi mirror sunucu adını ön belleÄŸe alır. MDAC primary sunucuyla olaran baÄŸlantısını kaybettiÄŸi zaman primary sunucuya yeniden baÄŸlanmayı dener eÄŸer baÅŸarılı olmazsa bu sefer yönünü mirror sunucuya döndürür. Bir anlamda MDAC, primary ve mirror sunucular arasında middleware olarak çalışır. Bu için connection string içerisinde ana sunucuyla birlikte yedek sunucunun adresi de verilir. Connection string içerisine eklenecek “Failover Partner” anahtar sözcüğü aracılığıyla birincil veritabanıyla baÄŸlantı kurulamadığı anlarda ek bir kodlama veya yapılandırmaya gerek kalmadan ikinci veritabanına yönlendirme yapılır. AÅŸağıdaki cümlede belirlenmiÅŸ connection süresinde eÄŸer birinci veritabanı (initial partner) olan “DW1″ sunucuyla baÄŸlantı kurulamazsa onun yansıması olarak yapılandırılmış olan ikinci veritabanıyla (failover partner) “DW2″ ile baÄŸlantı kurulmaya çalışılır.

Data Source=DW1;Failover Partner=DW2;Initial Catalog=Kaynak;Integrated Security=True;

Sonuç olarak eriÅŸilebilirlik ve performans açısından database mirroring’in iyi bir çözüm olduÄŸunu ve failover clustering ile kıyaslandığında otomatik geçiÅŸ süresinin daha kısa olduÄŸunu, ek donanıma ihtiyaç duymadığını ve en önemlisi failover clustering gibi sadece yüksek eriÅŸilebilirlik saÄŸlamadığını bu en ek olarak yüksek performans ve koruma saÄŸladığını da söyleyebiliriz. Bununla birlikte yedek sunucunun NORECOVERY modunda olması ve bir veritabanına ait sadece bir mirror’un olması bir dejavantaj olarak deÄŸerlendirilebilir.