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. [sql]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.
Hocam; ALTER DATABASE Alerter
SET PARTNER = N’TCP://mirrorserver.test.local:5001′ komutu PRINCIPLE uzerinde çalıştırdıgımda aşağıdaki hatayı alıyorum, telnet ile ilgili portu sorguladıgımda cevap alıyorum..sıkıntı ne olabilir..Error mesajı:
Msg 1418, Level 16, State 1, Line 1
The server network address “TCP://mirrorserver.test.local:5001¨ can not be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational.
Bora,eğer network anlamında sunucu ayakta ve post yayında ise bütük ihtimalle mirror server üzerindeki database mirroring işlemine hazır hale getirilmemiştir. Principle sunucuya full backup ve en az 1 tane transaction log backup With Norecovery seçeneğiyle mirror server üzerinde restore etmek lazım. Hala bağlanılamıyorsa port değişikliği yapmanı ve tüm endpoint’leri yeniden oluşturmanı tavsiye ederim.
Hocam bilgileriniz için teşekkürler.
Benim sorunum şu :Uzak sunucumu mirror olarak kullanmak istiyorum.örnek olarak :
Herhangi bir domaine bağlı olmayan uzak mirror sunucum için:uzak sunucu ip : 81.212.XXX.XX
uzak sql sunucu ismi : HPSERVER
PORT: 5001bu durumda nasil bir tcp:// ayarı yazılması gerekiyor.Genelde makaleler ve görsel videolar , aynı lokasyonda yapılmıs. Ben sadece principal ve mirror server yapıcam.Kime sorduysam cevap alamadım ?Rica etsem yanıtlayabilirmisiniz.
Merhaba,farklı domainler arasında Mirror dediğiniz gibi network erişimi yönüyle sorun yaratabiliyor. Bununla ilgili çözümleri aşağıdaki adreste bulabilirsiniz. Benim fikrim bu tür durumlarda Log Shipping kurmanızdır.http://madebysql.blogspot.com/2011/06/database-mirroring-between-server-in.htmlhttp://blog.sqlauthority.com/2010/03/18/sql-server-mirroring-configured-without-domain-the-server-network-address-tcpsqlservername5023-can-not-be-reached-or-does-not-exist/
merhabalar hocam,
cross database transaction kullanan veya filestream içeren database yapılarında mirroring tavsiye edilmez deniliyor bu iki terim ne anlama geliyor ? ve neden tavsiye edilmiyor ?