Merhaba,
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 rol değişikliğine gidilebilirdi. Büyük şirketlerde bu mantık genelde kullanılmaktadır. Principal rolünde bir production veritabanı olan şirketler bir de aynı veritabanının disaster veritabanlarını oluşturmakta ve anlık olarak her iki veritabanlarını da senkron tutmaktadırlar. Böylece Production veritabanı herhangi bir durumdan dolayı hizmet veremez ise tüm talepler Disaster veritabanına yönlendirilirler. Buda şirketler için high 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.
Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var mehmet.deveci@gridgroup.com.tr adresine mail atarak Bizimle iletişime geçebilirsiniz.
– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri