Home / MAKALELER / Veri Tabanı / SQL Server Database Mirroring-3

SQL Server Database Mirroring-3

Merhaba, Bu makalede önceki 2 makalede anlattığım ve gerçeklediğim SQL Server 2008 de Database Mirroring olayınının testlerini, monitoring olayını ve Database Failovering yapısını anlatacağım.

4.Mirroring testi ve Monitoring

Mirroring yapıldığı zaman Principal database de bulunan dataların aynısı anlık olarak Mirror database de de bulunduğunu aşağıdaki gibi örnekle göstereceğim. Mirror database e Restore modda olduğu için read modda değildir. Database girmeye çalıştığım zaman aşağıdaki hatayı alıyorum.

 

Mirror database e erişim için bu database in snapshot ını alıp snapshot üzerinden read yapabiliriz. Snapshot işlemini management studiodan yapamıyoruz bunun için gerekli TSQL kodu aşağıdaki gibidir. Bu kodu mirror database için çalıştırdım.

CREATE DATABASE TestDatabaseSnapshot  ON
( NAME = TestDatabase, FILENAME = 'D:\Mirroring\TestDatabase_Snapshot.ss' )
AS SNAPSHOT OF TestDatabase;
GO

Çalıştırdıktan sonra Databases sekmesi altında Database Snapshot sekmesi altında Snapshot database i aşağıdaki gibi görüyor olmalıyız.

 

Mirroring Test

Principal ve Mirror database de aşağıdaki sorguyu çalıştırdığınız zaman aynı dataların çekildiğini ve kayıt sayılarının da aynı olduğunu göreceksiniz böylece Principal ve Mirror database in sync olduğu ortaya çıkacaktır. Bu arada aşağıdaki sorgu çalıştırılmadan önce yukarda örnek data girdiğim T-SQL kodu halen çalışmaktaydı. Transaction akışını durdurup Mirror da tekrar snapshot aldım ve aşağıdaki sorguyu öylece çalıştırdım. Aksi takdirde principal da transaction devam ederken mirror da her an aynı datayı gösteremiyor olacaktım. Dataların aynı olduğunu ispatlamam için Principal a gelen transactionları durdurmak gerekiyor.

Principal:

select * from TestDatabase.dbo.testtable order by col2 desc

 

 

Mirror Database

select * from TestDatabaseSnapshot.dbo.testtable order by col2 desc

Mirroring Monitoring

Diğer yandan Mirroring i monitör etmek için Mirroring yapılan Principal database gelip aşağıdaki gibi Mirroring eylemini monitör edebilirsiniz.

 

 

Database Mirroring Monitor bölümünde mirroring yapılan Sunucuların durumları aşağıdaki gibi belirtiliyor.

Burdan Mirroring yapılıyormu yapılmıyor mu, Witness ın durumu ve Bu sunucuların O anki Rolleri Status kısmından anlaşılır.

Ayrıca Principal log ve Mirror Log başlığı altında bulunan alanda ise Principal ve Mirror database üzerinde Gönderilmeyen Transaction log lar, En eski gönderilmeyen Transaction lar ve Gönderilen Transaction log ların Ortalama büyüklüğü gibi bilgiler burdan incelenebilir.

 

 

Aşağıdaki Warnings sekmesi altında ise Uyarıların Threshold değerleri ayarlanıp ona göre uyarıların gelmesi ayarlanır.

 
5.Database Failovering

Makalenin başında Mirroring olayının en çok disaster durumlarında high availability sağlaması için kullanıldığını söylemiştim. Disaster durumu sadece Sunucu Down olduğu zaman değil SQL Server Service sinin beklenmedik bir durumda durduğu an içinde kullanılır. Kısaca Veritabanı herhangi bir nedenden dolayı hizmet veremiyorsa eğer o Veritabanı Disaster durumundadır.Şimdi örnek bir disaster senaryosu üzerinden bu durumu açıklayacağım. Principal ve Mirror database lerin 2 si de Aynı bilgisayarda bulunduğu için örnek senaryo için Sunucu Down olma durumunu kullanamayacağım. Bu durumda Principal database in bulunduğu SQL Server Instance sına ait Servisleri durduracağım. SQL Server servislerini durdurmak demek o database in hizmet vermemesi anlamına gelir.
Şimdi Principal database servislerini durdurmadan önce Son kez Mirroring durumuna bakalım. Aşağıdaki Mirroring Monitoring ekranında göründüğü gibi iki database de Synchorized durumda. Failover olmadan önceki Rol durumları da göründüğü gibi Principal olarak MSSQLSERVER default instance sı yani D1010984, Mirroring rolü olarak ta MYTESTINSTANCE instance sı gözükmektedir. Mirroring State kolonundan da Mirroring in şuan yapıldığını görüyoruz.

 

 

 

Principal role de bulunan SQL Server Servisini Configuration Manager dan aşağıdaki gibi Stop ediyorum.

Başlangıçta Witness durumunu seçtiğim için DEVINSTANCE instance sı otomatik olarak rol değişimi yapacak ve Mirror olan database i Principal rolüne atayacaktır.

 

Bu durumda Failover olayının gerçekleşip Principal Role ün MYTESTINSTANCE a geçmesi gerekiyor.

Aşağıdaki gibi Mirroring Monitor de de bunun aynen gerçekleştiğini görebilirsiniz. Bu durumda MYTESTINSTANCE önceki durumdan farklı olarak Okunabilir ve yazılabilir durumdadır. Yani Principal database ile aynı özelliktedir. Ayrıca Mirroring State kolonundan da Mirroring in durduğunu görüyoruz.

 

 

Aşağıdada Management Studio dan da ilk durumda Mirror Rolünde bulunan MYTESTINSTANCE sına bağlandığımda

aşağıdaki gibi bu database in Principal Rolüne dönüştüğünü ve Mirroring in durduğunu görüyoruz. Veritabanı artık bu instance üzerinden hizmet vermeye devam etmektedir.
Şimdi daha önce Principal Role de olan MSSQLSERVER Instance Servisini tekrardan Start ettiğim zaman aşağıdaki gibi Mirroring devam edecek fakat MSSQLSERVER Instance sı Mirror rolünde MYTESTINSTANCE instance sı ise Principal modda olacaktır.
Rollerin değiştiğini ve Mirroring in devam ettiğini aşağıda görebilirsiniz.
Failover olayını böylece tamamlamış olduk. Şimdi her iki instance sa bağlandığım zaman gerçektende

rollerin değiştiğini aşağıdaki gibi görmüş olacağız.

 

Failover durumu gerçekleşti ve Database ler Rollerini değişti. Aynı sunucuda

çalıştıkları için bu durum bir sıkıntı oluşturmamaktadır.Ancak eğer farklı sunucularda olsalardı kullanıcılar için tekrar roldeğişikliğine gidilebilirdi. Büyük şirketlerde bu mantık geneldekullanılmaktadır. Principal rolünde bir production veritabanı olan şirketlerbir de aynı veritabanının disaster veritabanlarını oluşturmakta ve anlıkolarak her iki veritabanlarını da senkron tutmaktadırlar. Böylece Production veritabanı herhangi bir durumdan dolayı hizmet veremez ise tüm taleplerDisaster veritabanına yönlendirilirler. Buda şirketler içinhigh availability sunma açısından güzel bir çözüm teşkil etmektedir.

6.Sonuç

Mirroring, disaster durumlarında high availability i sağlamak, data kaybını önlemek ve raporlama yapan kişilerin production ortamına kattığı yükü azaltmak için anlık olarak bir database in kopyasının farklı bir yerde tutulmasını ve gerektiğinde burdan hizmet vermesini sağlayan güzel bir çözümdür.

Mirroring e benzeyen ve aynı amaca hizmet eden Log shipping gibi teknolojilerde high availability için tercih edilebilir.Öte yandan Microsoft un Nisan 2012 de Release ettiği SQL Server 2012 ile beraber gelen AlwaysOn teknolojisinin getirmiş olduğu Availability Groups, High Availability açısından yine mükemmel bir çözümdür. Bu teknolojide büyük çaplı Veritabanı barındıran şirketler tarafından incelenmeli ve kullanılmalıdır.

Mirroring çözümü SQL Server 2012 de ile beraber deprecated olarak ilan edildi yani SQL Server 2012 de Mirroring kullanılabilinecek ancak bir sonraki majör release ile beraber mirroring tamamen kalkacak ve sadece AlwaysOn kullanılacaktır. Buda şu anlama geliyor Mirroring daha uzun yıllar boyunca SQL Server high availability çözümü için kullanılacaktır. En azından Microsoft şuanda SQL Server 2000 den desteğini çektiği gibi SQL Server 2012 den de desteğini çekene kadar,  ki bu süre benim tahminimce 10 yıldan fazla olacaktır, Mirroring çözümü kullanılmaya devam edecektir.

Mehmet Salih DEVECİ

VERİTABANI YÖNETİCİSİ

About Mehmet Salih Deveci

Karadeniz Teknik Üniversitesi Bilgisayar Mühendisliği bölümünden 2011 yılında mezun oldu. C#, ASP.NET ve Oracle, SQL Server Veritabanları Teknolojileri Alanlarında Çalışmalarını Sürdürmektedir. Şuan Türk Telekom A.Ş de Veritabanı Yöneticisi olarak Kariyerini Sürdürmektedir.

İlginizi Çekebilir

SQL Server ile Veri Şifreleme

Bilgi teknolojilerinde verinin güvenliği çok kritik bir öneme sahiptir. Önemli verileri korumak için ekstra bir …

Bir Cevap Yazın