Anasayfa » SQL Server 2008 R2 ile Database Mirroring Bölüm 1

Makaleyi Paylaş

SQL Server

SQL Server 2008 R2 ile Database Mirroring Bölüm 1

SQL Server 2008 makale serimize aşağıda görmüş olduğunuz kurulum  ve kurulum sonrası temel bazı uygulamaları içeren aşağıdaki makaleleler ile sizlerle paylaşmıştım. Eğer SQL Server konusuna yeniyseniz öncelikle aşağıdaki makaleleri okuduktan sonra bu makalemize devam etmenizi öneriyorum.

 

SQL SERVER 2008 – Nedir – Kurulum Gereksinimleri – Destekleri – IIS 7 Yukleme
SQL SERVER 2008 – Kurulum
SQL SERVER 2008 – Management Studio ile Calışmak
SQL Server 2008 – Sıkıstırılmış Yedekleme / Backup Compression

Bu makalemizle sizlere SQL Server 2005 ile gelen ve sonraki SQL Server versiyonları ile daha da geliştirilen SQL Database Mirroring çözümünü anlatıyor olacağım. Database Mirroring özellikle felaketten kurtarma, iş  sürekliliği ya da olağanüstü durum merkezi senaryolarımızda Microsoft SQL Veritabanı Sunucuları için geliştirilmiş bir yüksek erişilebilirlik çözümü. Bir başka deyişle Database Mirroring, Microsoft SQL Server sistemleri üzerinde barındırılan veritabanları için geliştirilmiş bir yüksek erişilebilirlik (High Availability – HA) çözümüdür. SQL Server 2005 sp1 ile ilk olarak kullanılmaya başlanan bu çözüm sonraki SQL Server versiyonları olan SQL Server 2008 ve SQL Server 2008 R2 ile de desteklenmektedir. Burada aslolan amaç bir veritabanının iki farklı sunucuda kopyası oluşturularak, mevcut aktif sunucunun herhangi bir nedenden dolayı servis verememesi, devre dışı kalması ya da veritabanının bozulması durumunda yedek sunucu üzerinde bulunan veritabanı ile erişimin ve servisin aynen devam ettirilmesidir. SQL Server Log Shipping uygulaması ile daha önceden çalışmışsanız, database mirroring çözümünde de benzer bir süreç ile veritabanının başka bir sunucuya kopyasının oluşturulması gerçekleştirilmektedir. Database mirroing ilk çıktığında genelde gerçek-zamanlı log shipping ya da dinamik log shipping olarak sektörde tanımlanmaya başlamıştı. Fakat zaman içerisinde görüldü ki, database mirroring log shipping’e göre çok daha sağlam ve enterprise-seviyede bir çözüm olduğunu kanıtladı. Ve bugün gelinen noktada artık sektör içerisinde çoğu kurum ve kuruluşun felaket ya da olağanüstü durum senaryolarının en önemli maddelerinden biri halini aldı. Hatta Log Shipping’in artık yerini Database Mirrorring çözümü aldı dersek, abartmış da olmayız. 

 

Günümüzde Database Mirroring’in SQL Server ile ilgili felaket ya da olağanüstü durum senaryolarının gerçekleştirilmesindeki en önemli çözüm olduğunu ifade ettik. Database Mirroring çözümünden önce veritabanları için herhangi bir kesinti ya da sunuculardan birinin hizmet verememesi durumunda “sıfır-veri-kaybı” çözümünü gerçekleştirebileceğimiz yöntem “failover clustering” iken, artık bunu database mirroring için de söyleyebiliyoruz.

Sponsor

 

Database Mirroring SQL Server üzerinde elen yardımcı sihirbazlarla grafiksel olarak kolaylıkla devreye alabileceğimiz bir çözüm.

 

Şimdi isterseniz yavaş yavaş kavramlar ve terminolojiyi biraz detaylandıralım.

 

I.                    Konsept ve Kavramlar

 

Database Mirroring çözümünün kendine has terimleri ve kavramları mevcuttur. Fakat genel anlamda bu kavramlar felaketten kurtarma senaryolarında kullandığımız kavramlardır. Sektör içerisindeki diğer çözümlerdeki kavramlarla karşıklığı ortadan kaldırmak için, SQL Server kendisine özgü kavramları da getirmiştir:

 

Rol : Database Mirroring çözümünde yer alan sunucuların yerine getirdiği fonksiyonu ifade eden terimdir. Örneğin, database mirroring çözümünde sunucunun rolü principal (ana sunucu) , mirror (yedek sunucu) ya da witness (şahit sunucu) olabilir.

 

Principal : Fonksiyonel olarak aktif hizmet veren kaynak veritabanını tutan sunucudur. Kaynak sunucu ya da ana sunucu olarak da ifade edilir. Tabii bu sunucu üzerinde bulunan veritabanının kendisi de kaynak veritabanı, ana veritabanı ya da principal database olarak isimlendirilir.

 

Mirror : Mirror süreci ile kaynak veritabanının kopyasının oluşturulduğu yedek sunucu, kopya sunucu ya da aynalanmış sunucudur. Tabii bu sunucu üzerinde oluşan veritabanı da kopya veritabanı, yedek veritabanı, aynalanmış veritabanı ya da mirror database gibi isimlerle anılır.

 

Witness : Principal ve Mirror sunucuları sürekli izleyerek bir kesinti anında ya da durumunda otomatik olarak rollerin değiştirilmesine aracılık eden sunucudur. Bir başka ifade ile database mirroring çözümünde ana sunucuda oluşabilecek bir kesinti durumunda yedek sunucuyu ana sunucu konumuna otomatik geçiş yöntemiyle almak için kullanılan sunucudur. Yani database mirroring çözümünün rol-karar-noktası (quorum) tabir edilen role sahip sunucudur. Witness sunucu kullanmak isteğe bağlıdır. Eğer otomatik geçiş istemiyorsanız, kesintilerde rol geçişini manuel yapacağım diyorsanız, witness server kullanmayabilirsiniz.

 

Partner : Mirror ve Principal sunucular için database mirroring çözümünde birlikte çalışılan karşı taraftaki sunucu rolünü ifade etmek için kullanılır. Çözüm ortağı olarak ifade edilebilir. Mirror’in çözüm ortağı principal, principal’in çözüm ortağı mirror’dır.

 

EndPoint : Database mirroring çözümünde yer alan SQL sunucularının ağ üzerinden haberleşmelerini sağlayan ve bir ağ protokolüne bağlı çalışan “uçnokta” diye ifade ettiğimiz nesnelerdir.

 

Session : Database Mirroring çözümünde sunucuların birbirleri arasındaki bağlantı durumlarını canlı tutmak için sürekli birbirlerine yaptıkları kontrol ya da açtıkları oturumdur.

 

Operating Mode : Database Mirroring çalışma/işletme modeli, modu ya da yöntemidir. Database Mirroring çözümünde üç farklı işletme modu vardır : high-safety with automatic failover (synchronous), high-safety without automatic failover (synchronous),  high-performance mode, (asynchronous).

 

II.                  SQL MANAGEMENT STUDIO KULLANILARAK GUI’DEN DATABASE MIRRORING UYGULANMASI

 

Database Mirroring çözümünü devreye almadan önce mevcut yapının analiz edilerek öngereksinimlerin tamamlanıp tamamlanmadığı kontrol edilerek, uygulmaya alma ile ilgili bir planlama yapılmalıdır.

 

·         Database Mirroring için kullanılacak sunucuların hazırlanması

·         Database Mirroring için kullanılacak veritabanlarının hazırlanması

·         Servis hesaplarının belirlenmesi

·         Veritabanı kapasitelerine göre yer planlamasının yapılması

·         Diğer altyapı ve uygulama hazırlıkları

·         Database Mirroring Implementasyon Planının Oluşturulması

 

Database Mirroring Sunucularının Hazırlanması

 

 

Database Mirroring çözümünde kullanılacak sunucuların aynı SQL versiyonu ve sürüm numarasında çalıştıklarından emin olunmalıdır.(Build number). Database Mirroring desteklenen SQL Server sürümleri:

 

·         SQL Server 2005 SP1 ve üzeri

·         SQL Server 2008

·         SQL Server 2008 R2

 

Dolayısıyla eğer SQL Server 2005 SP1 öncesi sürüm numarasına sahip bir SQL Sunucusu ile çalışıyorsanız, öncelikle bu sürüm numarasını mutlaka minimum SQL 2005 SP1 versiyonuna yükseltmeniz gerekir. Burda bizim tavsiyemiz lisansına sahip olduğunuz SQL Server ürününün son servis paketlerini ve güncellemelerini de yükledikten sonra database mirroring uygulamasına geçmenizdir. Burada dikkat etmeniz gereken ya da sizi kısıtlayan bir durum da SQL üzerinde veritabanı bulunan uygulamalarınızın da SQL ürünü ile ilgili gerekli servis paketi ve yamalarını desteklemesidir. Eğer kullandığınız uygulama SQL ürünü için çıkartılan belli paketlerin geçilmesi durumunda problem yaşatıyorsa, tabii ki database mirroring için gerekli minimum paketi geçmeniz yeterli olacaktır. Bu tamamen sizin ortamınıza ya da uygulamalarınızı gözönünde bulundurarak verilecek bir karardır.

 

SQL Database Mirroring çözümünde yer alacak sunucuların üzerinde çalışan işletim sistemleri birbirinden farklı olabilir. Örneğin Principal Sunucu Windows 2008 R2’de çalışırken, Mirror Sunucu Windows 2008 de, Witness Sunucu da Windows 2003 de çalışabilir. Hatta işletim sistemi mimarisi de farklı olabilir. Sunuculardan biri 64-bit mimaride çalışırken diğeri 32-bit mimaride çalışabilir. Tabii bizim burda önerimiz bütün rollerin 64-bit mimaride çalışan bir yapıda olmasıdır.

 

SQL Database Mirroring çözümünde rol alacak principal ve mirror sunucular üzerindeki SQL Server uygulaması aynı sürüme sahip olmalıdır. Principal ve Mirror sunucular üzerindeki sql uygulaması SQL Enterprise Edition ya da SQL Standart Edition olabilir. Fakat principal da hangi edition varsa mirrorda da aynısı olmalıdır. Ayrıca her iki SQL Sunucudaki SQL Server versiyonu da aynı olmalıdır.  Bir diğer önemli nokta da her iki sunucuda SQL Veri ve Log dosyalarının sürücü harfi ve yol tanımlamaları aynı olmalıdır.Eğer sürücü yapısı iki sunucuda farklı ise, yapısal farklılıklardan dolayı mirror rolü başarısız olacaktır. Witness sunucu üzerinde ise SQL 2005/2008 Express Edition ya da SQL 2005/2008 Workgroup Edition da kullanabilirsiniz.

 

 

Benim bu uygulamada anda kullandığım sistemle ilgili bilgiler aşağıdadır:

Principal: Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)   on Windows 2008 R2 (X64)

Mirror: Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)   on Windows 2008 R2 (X64)

Witness: Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)   on Windows 2008 R2 (X64)

 

Veritabanlarının Hazırlanması

 

Database Mirroring veritabanı seviyesinden ayarlanan ya da belirlenen bir çözüm. Yani ben aynı sunucu üzerinde bir veritabanı için database mirroring yaparken başka bir veritabanı için bu çözümü aktifleştirmeyebilirim.

 

·         Database Mirroring çözümü sadece Full Recovery model yapısında olan veritabanları için kullanabiliyoruz. Simple ya da Bulk-Logged Recovery modelde çalışan veritabanları için database mirroring özelliği etkinleştirilemez.

 

Bu uygulamada benim kullanacağım “COZUMPARK” veritabanıma ait recovery model tipinin Full modda olduğunu SQL Management Studio içerisinde Databases kabının altında gelen COZUMPARK veritabanının Properties’ine girdikten sonra Options sayfasına gelerek kontrol ediyorum.

 

 

image001

 

 

Ayrıca COZUMPARK veritabanı için Mirroring özelliğinin aktif olmadığını Mirroring sayfasına gelerek de kontrol edebilirsiniz:

 

 

image002

 

 

COZUMPARK veritabanının recovery modunu transact-sql uygulamasından aşağıda gördüğümüz gibi de kontrol edebiliriz:

 

 

image003

 

 

Burada Status kolonunda Receovery=FULL ile veritabanı kurtarma modu bilgisi geliyor.

 

Yine aşağıdaki sorgu ile de bunu kontrol edebilirsiniz:

 

 

image004

 

 

Eğer veritabanı FULL modda değilse transact-sql komutları ile aşağıdaki şekilde FULL moda alınabilir:

 

 

image005

 

 

Database Mirroring çözümü uygulanacak veritabanında filestream özelliği aktif olan bir dosya grubu(filegroup) olmamalıdır. Database Mirroring filestream özelliğini kullanan veritabanlarını desteklemez.Filestream SQL Server 2008 ile gelen yeni bir özelliktir ve veriyi dosya sisteminde saklayarak T-SQL sorguları ile sorgulanmasını sağlar. Database Mirroring çözümünde failover durumunda mirror sunucudan principal sunucunun dosya sistemindeki veri alınamayacağı için filestream özellikli veritabanları desteklenmiyor.

 

 

Servis Hesaplarının Hazırlanması

 

 

Database Mirroring çözümü için yapılması gereken hazırlıklardan biri de kullanılacak servis hesaplarının belirlenmesidir. Bu konuda en kolay yöntem sunucular üzerinde SQL Servisleri için kullanılan domain hesabının aynısını database mirroring için de kullanmak olabilir. Bütün sunucularda aynı servis hesabını kullanıyorsanız, uçnoktalar için ayrıca bir yetki ataması yapmanıza da gerek kalmayacaktır. Tabii bu yöntem tüm ortamlarda ve durumlarda özellikle politikalardan dolayı uygulanamayabilir.  Domain hesabına alternatif olarak “Network Service” hesabın da kullanılabilir. Network Service hesabı da bir domain hesabı gibi kullanılır. Network Service hesabi diğer sunucuya erişirken kendisini Domain\SunucuAdi$ şeklinde gösterir. Örneğin COZUMPARK domaininde çalışan SQLSRV1 ve SQLSRV2 sunucuları için network service hesabını kullanıyorsanız domain hesapları COZUMPARK\SQLSRV1$ ve COZUMPARK\SQLSRV2$ olacaktır. Bunların dışında çok da tavsiye etmediğimiz bir diğer yöntem yerleşik olarak gelen Local System hesabini kullanmak olabilir. Local System hesabinin lokal bilgisayar üzerinde de ekstra bazı yetkileri olduğu için bunun da kullanılmasını önermiyoruz. Local System hesabı sadece kendi bilgisayarı üzerindeki kaynaklara erişimi gerçekleştirir. Başka bir bilgisayar üzerindeki bir kaynak için Local System hesabina yetki veremezsiniz. Database Mirroring çözümünde servis hesabi olarak Local System hesabini kullanacaksanız Windows authentication yerine sertifika-tabanlı certificate authentication kullanmanız gerekir.

 

 

ÖNEMLİ NOT : Certificate Authentication için kullanılacak sertifikaların belli bir geçerlilik süresi olduğu için, bu tip kullanımlar için alınan sertifikaların mutlaka uzun süreli alınmasını öneriyoruz.

 

 

Veritabanı Kapasitelerinin Kontrolü

 

 

Database Mirroring çözümünün devreye alınmasından önce kontrol edilmesi gereken önemli noktalardan biri de mirror yapılacak veritabanının boyutudur. Eğer çok yüksek boyutta bir veritabanı varsa, öncelikle bunun yedeğinin alınıp, karşı sunucuya geri yükleme yapılmasının gerçekleştirilmesinde zamandan kazanma ve gereksiz hattı yormama adına önemi çok yüksektir. Dolayısıyla çok büyük veritabanları için database mirroring’i devreye almadan önce saatler alabilecek bir aksiyon da bu olacaktır. Burada uygulama adımlarında da göreceğiniz, fakat belirtmekde yarar gördüğüm bir diğer konu da Mirror üzerine geri yükleme yaparken geri yükleme modunun NORECOVERY modda yapılmasıdır. Hatta burda bazı organizasyonlarda veritabanı çok büyükse önce Log Shipping ile veritabanının bir kopyası Mirror sunucuya senkronize edildikten sonra Log Shipping yöntemi Database Mirroring yöntemine dönüştütülmektedir. Zamandan kazanmak anlamında bu tip çözümlere de gidilebilir.  Database Mirroring devreye alınmadan önce son bir kez kaynak veritabanının Transaction Log yedeği alınarak Mirror sunucuya geri yükleme yapılması gerekir. Bu işlemin hemen akabinde de artık database mirroring çözümü devreye alınabilir.

 

 

Buradaki bir diğer önemli nokta, mirror sunucunun sahip olduğu donanımsal kaynakların (CPU, RAM, disk vb.) principal sunucu ile benzer nitelikte olmasıdır. Çünkü oluşabilecek bir felaket anında aktif duruma gelecek mirror sunucunun mutlaka gerekli yükü kaldırabilecek donanımsal kaynağa sahip olması gerekir. Aksi halde kapasitesi yükü kaldırmayan bir sunucu ile felaket senaryosu planlamak daha uç bir felaket olacaktır. Burada marifet sadece veritabanının başka bir sunucuya kopyalanması değildir, felaket anında bu yedek sunucu üzerinden hizmeti de en azından belli bir seviyede devam ettirmektir.

 

 

Uygulamalarda Database Mirroring Ayarlanması

 

Donanımsal ortamın hazırlanmasının yanında önemli olan bir diğer süreç de uygulamaların database mirroring çözümüne göre konfigüre edilmesidir.Normalde uygulamalar veritabanına erişirken hepimizin de bildiği gibi “connection string” adını verdiğimiz bir bağlantı cümlesindne bağlanacakları SQL Suncucu adını ve veritabanı adını alarak gerekli bağlantıları sağlarlar. Felaket anında mirror sunucunun kontrolü alması durumunda uygulamalarımızın da otomatik olarak artık principal sunucu yerine mirror sunucuya gitmelerini sağlayacak şekilde bağlantı cümleleri içerisine database mirroring parametrelerinin yerleştirilmesi gerekir. Böylece kullanıcı tarafindan hiçbir işlem yapmadan, hatta kullanıcılar hissetmeden uygulamalar mirror sunucu üzerinden erişimini devam ettirebilmelidirler. Tabii eğer uygulama içerde kendi geliştirdiğiniz (in-house) ve koduna sahip olduğunuz bir uygulama ise sorun yok. Fakat dışardan hazır satın aldığınız mevcut sisteme kurularak entegre edilen üçüncü parti uygulamalarsa ve uygulamanın kodlarına erişiminiz yoksa (ki biz bunlara black-box tabirini de kullanıyoruz.) bu durumda uygulamayı geliştiren firma ya da ekiplerle iletişime geçerek bu ihtiyacı belirtmeniz gerekecektir.

 

Diğer yandan database mirroring destekli bağlantı sağlayıcılar da şunlardır: SQL Native Client, ADO.NET 2.0 Data Provider, JDBC 1.1 Driver for SQL Server. Bunlardan birini kullanan connection string cümleciği içerisinde failover partner sunucu adının yani mirror sunucu adının da tanımlanması gerekir. Dolayısıyla uygulamaların bağlantı cümlelerini buna göre güncellemeniz gerekecektir. Bu konuda geniş bilgi ve örnek cümlecikleri son kısımda veriyor olacağım.

 

Tabii eğer uygulamalarınızda database mirroring ile otomatik failover desteklemeyen komponentler (DTS ya da SSIS paketleri, bağlantı protokolleri ile veritabanına bağlananan EXE’ler vb.) varsa bu durumda ya bu komponentleri database mirroring destekleyecek şekilde yeniden yazmanız ve oluşturmanız ya da aynılarının mirror sunucu üzerine de konumlandırarak bir şekilde database mirroring yapısında çalışacak konuma getirmeniz gerekmektedir.

 

Bir diğer önemli nokta da database mirroring’in veritabanı seviyesinde devreya alınan ve veritabanı seviyesinde kontrol edilen bir çözüm olduğunu belirtmiştik. Eğer birbirine bağımlı olarak çalışan farklı veritabanlarının olduğu bir sunucumuz varsa bir veritabanının mirror sunucuya geçmesi durumunda diğer veritabanlarına bağımlılığı varsa, bu durumda o veritabanlarının da mirror sunucuya geçecek şekilde gerekli tetiklemelerin de devreye alınması gerekir.

 

 

Database Mirroring devreye almadan önce sunucu üzerindeki full ya da log backup job tanimlamaları varsa bunların mutlaka devre dışı bırakılması gerekir. Çünkü full ya da log yedekten sonra log işleme sırası değişeceği için bundan dolayı database mirroring devreye alamazsınız.

 

Son olarak kullandığınız uygulamalarınızın principal sunucu üzerinde erişim yaptığı dosya ve klasör yol tanımlamaları varsa (Özellikle UNC Path olarak), bunların da kesinti halinde sistem mirror sunucuya geçince ulaşılabilecek şekilde mirror sunucu üzerinde ya da ağda başka bir sistemde ulaşılabilir olmasını ayarlamanız gerekir.

 

Database Mirroring Implementasyon Planının Oluşturulması

 

Database Mirroring implementasyonunu gerçekleştirmek için uygulanacak adımları ve bunun zaman çizelgesini içeren bir planlamayı oluşturmanızda fayda vardır. Aşağıda database mirroring projeleriniz için örnek oluşturabilecek bir şablon planı da sizlerle paylaşıyoruz:

 

 

Saat

İşlem Tanımı

İşlem Süresi

9:00 P.M.

Tüm SQL Joblarin ve zamanlanmış görevlerin devre dışı bırakılması

4 dakika

9:05 P.M.

Mirror yapılacak veritabanının Full Recover Modelde çalıştığının kontrolü

2 dakika

9:08 P.M.

Veritabanın tam (FULL) yedeğinin alınması

20 dakika

9:30 P.M.

Alınan yedeğin Mirror Sunucuya kopyalanarak NORECOVERY modda geri yüklenmesi

30 dakika

10:00 P.M.

Veritabanın Log (Transaction Log) yedeğinin alınması

3 dakika

10:04 P.M.

Alınan Log yedeğin Mirror Sunucuya kopyalanarak NORECOVERY modda geri yüklenmesi

5 dakika

10:10 P.M.

Database Mirroring Konfigürasyonu

10 dakika

10:20 P.M.

Uygulamalara yeni bağlantı konfigürasyonlarının güncellenmesi

5 dakika

10:25 P.M.

Tüm SQL Joblarin ve zamanlanmış görevlerin devreye alınması

4 dakika

10:29 P.M.

Database Mirroring Bakım Sürecinin Oluşturulması

5 dakika

10:34 P.M.

Test Ekibine testleri yapmaları için gerekli bilginin verilmesi

5 dakika

 

 

 

Lab ortamı hakkında bilgi

 

Benim uygulama ortamımda şu anda üç farklı SQL sunucu bulunmakta. SQL Sunucu bilgileri aşağıdadır:

 

 

image006

 

 

Principal: Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)   on Windows 2008 R2 (X64)

Mirror: Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)   on Windows 2008 R2 (X64)

Witness: Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)   on Windows 2008 R2 (X64)

 

 

Database mirroring kurulumu

 

 

1.   Principal Server üzerinde COZUMPARK isimli bir veritabanı oluşturdum:

 

USE [master]

GO

 

/****** Object:  Database [COZUMPARK]    Script Date: 02/16/2011 23:49:05 ******/

CREATE DATABASE [COZUMPARK] ON  PRIMARY

( NAME = N’COZUMPARK’,

FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\COZUMPARK.mdf’ ,

SIZE = 3072KB ,

MAXSIZE = UNLIMITED,

FILEGROWTH = 1024KB )

 LOG ON

( NAME = N’COZUMPARK_log’,

FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\COZUMPARK_log.ldf’ ,

SIZE = 4224KB ,

MAXSIZE = 2048GB ,

FILEGROWTH = 10%)

GO

 

ALTER DATABASE [COZUMPARK] SET COMPATIBILITY_LEVEL = 100

GO

 

ALTER DATABASE [COZUMPARK] SET RECOVERY FULL

GO

 

ALTER DATABASE [COZUMPARK] SET  MULTI_USER

GO

 

 

 

2.   Principal Server üzerinde COZUMPARK isimli bir veritabanı oluştuğunu aşağıdaki şekilde de görüyorsunuz.

 

 

 

image007

 

 

3.       Aşağıda Database Mirroring uygulamasında SQL Instance’larimizin hangisinin ne rolü olacağına ait şekli görüyorsunuz.

 

image008

 

 

 

4.       Principal Server üzerindeki COZUMPARK veritabanının öncelikle FULL yedeğini alıyoruz.

 

image009

 

image010

 

 

5.       Sonrasında alınan bu yedeği Mirror server olan SQL Server sunucusuna NORECOVERY modda geri yükleme yapıyoruz.

 

image011

 

 

image012

 

image013

 

 

6.       Geri yükleme sonrasında Mirror Server üzerinde Cozumpark veritabanı Restoring durumunda geliyor:

 

image014

 

 

7.       Hemen akabinde Principal server üzerindeki Cozumpark veritabanının Transactional Log yedeğini alıyoruz.

 

image015

 

 

8.       Ve bu Transactional Log yedeğini Mirror server olan sunucuya yine NORECOVERY modda restore ediyoruz.

 

 

image016

 

 

Mirror server üzerindeki veritabanı hala Restoring durumda çalışıyor.

 

 

image017

 

 

9.       Şimdi de sıra geldi Database Mirroring yeteneğinin aktifleştirilmesine. Bu işlem için Principal Server üzerindeki COZUMPARK veritabanı üzerinde Tasks’den Mirror geçiyoruz:

 

image018

 

 

Şu anda Mirror özelliğinin henüz aktif olmadığını görüyoruz.

 

 

image019

 

 

10.   Configure Security butonuna tıklayarak Mirror adımlarını başlatıyoruz.

11.   Karşımıza gelen sihirbaz ekranında ilk adımı Next ile geçiyoruz.

 

 

image020

 

 

12.   İkinci adımda bize Witness Server kullanıp kullanmayacağımızı soruyor. Yes seçeneğini seçip, Next ile devam ediyoruz.

 

image021

 

13.   Witness server kullanacağımız için mirroring yapısına ait security configurasyonunun tutulacağı sunucuları seçmemizi istiyor. Next ile sonraki aşamaya geçiyoruz.

 

image022

 

 

14.   Principal sunucu ve portunu gösteriyoruz. Next ile sonraki aşamaya geçiyoruz.

 

image023

 

 

15.   Mirror server ve port bilgisini istiyor. Bizim Mirror sunucumuz SunucuAdi\SQLSRV1 olacak. Burada ben demo çalışmasında tüm rolleri aynı fiziksel sunucu üzerinde farklı SQL Instance’lar üzerinden gerçekleştirdiğimi için farklı Port numaraları kullanmam gerekiyor. Eğer bu SQL Instance’lar fiziksel olarak ayrı sunucularda ise hepsinde aynı port numarasını kullanabilirsiniz, sunucu ismi farklı olacağı için sorun olmayacaktır.

 

image024

 

 

16.   Next ile sonraki aşamaya geçiyoruz.

17.   Witness Server olacak Sunucuadi\SQLSRV2 makinesini gösteriyoruz.

 

image025

 

 

18.   Next ile sonraki aşamaya geçiyoruz.

 

 

image026

 

19.   Bizden servis hesabinin bağlı olduğu account bilgilerini girmemizi istiyor. SQL servisleri için SunucuAdi\Administrator hesabini göstererek Next ile sonraki aşamaya geçiyoruz.

 

20.   Konfigürasyon sihirbazının sonuna geldik. Finish ile süreci tamamlıyoruz.

 

 

 

image027

 

21.   Başarıyla konfigürasyon tamamlanmış oldu.

 

image028

 

22.   Start Mirroring tıklayarak mirroring işlemini başlatıyoruz.

 

image029

 

image030

 

Karşımıza gelen uyarı penceresinde mirroring konfigürasyonu için sunucu tanımlamalarında FQDN ismi kullanmamızı belirten uyarı geliyor. Yes ile kabul ederek devam ediyoruz.

 

 

image031

 

 

23.   Status bölümüne dikkat ederseniz Mirroring senkronizasyonunun başladığını göreceksiniz. Ara ara Refresh butonuna tıklayarak ilk senkronizasyonun gerçekleştiğini gözlemleyin.

 

image032

 

 

24.   Artık Synchronized bilgisini aldık, böylece Mirroring gerçekleşmiş oldu.

 

SQL Management Studio içerisinde veritabanlarının durumuna bakarsanız SunucuAdi üzerindeki Cozumpark veritabanının Principal, SınucuAdi\SQLSrv1 üzerindeki veritabanının da Mirror olarak çalıştığını gözlemlemiş olacaksınız.

 

image033

 

 

Herhangi bir anda planlı olarak Principal ve Mirror arasındaki rolleri değişmek için, ya da oluşan bir problem de Mirror rolünü Principal yapmak için principal üzerindeki COZUMPARK veribanı üzerinde Tasks’den Mirror ekranına gelince karşımıza çıkan Failover butonuna tıklamanız yeterlidir.

 

 

image034

 

 

Bu işlem sonrası bize rollerin değişeceği ile ilgili bilgi mesajı ve uyarısı gelir. Yes ile kabul ederek geçişi sağlamış oluyoruz.

 

 

image035

 

 

Artık Management Studio içerisinde baktığımızda Mirror ve Principal rollerinin değiştiğini göreceksiniz.

 

 

image036

 

 

Bu başlık altında da Database Mirroring sürecinin grafiksel arayüzden  nasıl gerçekleştirileceğini  adım adım gerçekleştirdik.

Database Mirroring özelliğini bir veritabanında devre dışı bırakmak için veritabanın Properties’inde Mirroring sayfasında Remove Mirroring butonuna tıklamanız yeterlidir.

 

 

image037

 

 

Karşımıza gelen diyalog kutusunda emin olup olmadığımızı soracaktır.

 

 

image038

 

 

 

Yes butonuna tıklayarak işlemi onaylıyoruz.

 

 

image039

 

 

Status kısmında veritabanının database mirroring için konfigüre edilmediği bilgisini göreceksiniz. OK ile Database Properties penceresini kapatıyoruz.

 

 

image040

Artık veritabanı üzerindeki Mirrored ya da Principal ifadelerinin kaybolduğunu göreceksiniz.

 

 

III.                Transact-Sql Komutlarıyla Database Mırrorıng Uygulanması

 

 

1.  Principal sunucusu üzerindeki COZUMPARK veritabanının full backup’ını alıyoruz:

 

 

BACKUP DATABASE COZUMPARK

TO DISK=‘C:\COZUMPARK_FULL2\Cozumpark_Full.bak’

 

 

 

2.       İkinci adım olarak bu full backup karşı makineye restore edeceğiz. Benim senaryomda tüm sunucular aynı sunucu üzerinde farklı SQL instance olduğu için ikinci SQL instance da mdf ve ldf dosyalarına farklı bir konum belirtiyorum.

 

RESTORE DATABASE COZUMPARK  

FROM DISK=‘C:\COZUMPARK_FULL2\Cozumpark_Full2.bak’ WITH NORECOVERY,  

MOVE ‘Cozumpark’ TO ‘C:\Cozumpark.mdf’,  

MOVE ‘Cozumpark_Log’ TO ‘C:\Cozumpark_Log.ldf’

 

 

 

3.       Şimdi de Principal Server üzerindeki kaynak veritabanının bir Transaction Log yedeğini alıyoruz.

 

Backup Log COZUMPARK

TO Disk= ‘C:\COZUMPARK_FULL2\Cozumpark_Tlog2.bak’

 

 

 

4.       Bu aldığımız log yedeğini mirror sunucuya kopyalayarak restore ediyoruz.

 

 

Restore Log COZUMPARK

from Disk=‘C:\COZUMPARK_FULL2\Cozumpark_Tlog2.bak’ with NORECOVERY 

 

Burada en önemli nokta mirror sunucuya restore yaparken kullanılan NORECOVERY seçeneğidir.

 

 

5.       Şimdi sıra geldi database mirroring için kullanacağımız endpoint yani uçnokta port tanımlamalarına. SQL Server TCP ve HTTP endpoint tiplerini destekler. Database Mirroring için biz TCP EndPoint kullanacağız. Endpoint nesnesi de SQL üzerindeki diğer nesneler gibi Create, Alter, Drop ifadelerini içeren DDL fonksiyonlari ile yönetilir.

 

Öncelikle Principal sunucu üzerinde Mirror işlemi için bir EndPoint oluşturuyoruz.

 

Create Endpoint Principal_Endpoint  

State= Started as TCP (Listener_Port=5022)  

For Database_Mirroring (Role=Partner);

 

 

6.       Şimdi de Mirror sunucu üzerinde bir TCP EndPoint oluşturuyoruz:

 

Create Endpoint Mirror_Endpoint  

State= Started as TCP (Listener_Port=5023)  

For Database_Mirroring (Role=Partner);

 

7.       Şimdi de Witness sunucu üzerinde bir TCP EndPoint oluşturalım:

 

Create Endpoint Witness_Endpoint  

State= Started as TCP (Listener_Port=5024)  

For Database_Mirroring (Role=Witness);

 

 

8.       Artık her üç rolümüz için EndPoint tanımlamalarını yapmış olduk.  Bu EndPointleri sys.endpoints, sys.database_mirroring_endpoints, sys.tcp_endpoints katalog tablolarından sorgulayabilirsiniz.

 

 

select * from master.sys.database_mirroring_endpoints

 

select * from master.sys.tcp_endpoints

 

Oluşturulan bir endpoint’i silmek için ise aşağıdaki komut kullanılır.

Drop Endpoint <ENDPOINT İsmi>

 

9.  Şimdi de sunucularda gelecek istekleri dinleyecek protokol ve port tanımlamalarını yapacağız. İlk aşama olarak yedek sunucu üzerinde database mirroring için bir oturum tanımlayacağız. 

 

 

 

ALTER DATABASE COZUMPARK  

SET PARTNER = N’TCP://SQLSunucuAdi:5022′

 

 

 

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

 

 

ALTER DATABASE COZUMPARK  

SET PARTNER = N’TCP://SQLSunucuAdi:5023′

 

 

 

11.   Şimdi de ana sunucu üzerinde aşağıdaki komutu çalıştırarak database mirroring oturumları için witness sunucu olacak tanımı yapıyoruz.

 

ALTER DATABASE COZUMPARK  

SET WITNESS = N’TCP://SQLSunucuAdi:5024′

 

 

 

Artık mirroring için gerekli yapılandırmaları tamamlamış olduk. Management Studio içerisinde sunucuların durumu aşağıdaki şekilde gözükecektir:

 

image041

 

 

Database mirroring özelliğini belli bir süre duraklatmak ya da askıya almak için aşağıdaki komut kullanılır.

 

ALTER DATABASE COZUMPARK SET PARTNER SUSPEND

 

Askıya alınmış database mirroring tekrar etkinleştirmek için de aşağıdaki komut kullanılır.

 

ALTER DATABASE COZUMPARK SET PARTNER RESUME 

 

Database Mirroring konfigürasyonunda komut satırından failover devreye almak için yani mirror sunucuyu principal sunucuya çevirmek için aşağıdaki komut kullanılır.

 

ALTER DATABASE COZUMPARK SET PARTNER FAILOVER

 

Management Studio içerisinde ekranları Refresh yaptıktan sonraki durumu aşağıdaki şekilde görülmektedir:

 

 

image042

 

 

Eğer database mirroring yapısı içerisindeki hem principal hem de mirror sunucular ulaşılabilir durumda ise manuel olarak failover gerçekleştirmek için yukarıdaki komutu kullandık. Eğer principal sunucu erişilemez durumdaysa mirror sunucuyu principal sunucu olarak atamak için de alağıdaki komut kullanılır.

 

ALTER DATABASE COZUMPARK SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

 

COZUMPARK veritabanı için database mirroring özelliğini tamamen devre dışı bırakmak için de aşağıdaki komut kullanılır:

 

ALTER DATABASE COZUMPARK SET PARTNER OFF

 

Bu makalemizde SQL Database Mirroring özelliğini ve kurulumunu gerek grafiksel arayüzden gerekse de Transact-SQL komutlarını kullanarak nasıl gerçekleştirileceğini adım adım uygulamalı olarak gördük. Bir sonraki makalemizde Database Mirroring en iyi yapılandırma önerilerini, Database Mirroring çalışma modlarını ve uygulamalarda database mirroring’e göre connection string yapılandırmalarını anlatacağız. Bir sonraki makalede görüşmek dileğiyle.

 

Makaleyi Paylaş

Cevap bırakın