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.

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

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

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
• Latest Posts

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.

Latest posts by Mehmet Salih Deveci (see all)

• Oracle Data Guard Mimarisi - Şub 19, 2014
• Oracle RMAN ( Recovery Manager ) -4 - Şub 15, 2014
• Oracle RMAN ( Recovery Manager ) -3 - Şub 12, 2014

Powered by Starbox