Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Ağustos 2017  >>
PaSaÇaPeCuCuPa
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Keywords

Workgrup ortamlarda SQL Server Mirroring kurulumu domain ortamlarda olduğu kadar kolay yapılamamakta. Örneğin GUI yani ekranları kullanarak workgrup ortamlarda DB Mirroring kurulumu yapılamamakta, script kullanımı şart olmaktadır.

Aşağıdaki blog post’ta bu kurulum adım adım çok güzel bir şekilde anlatılmış.

Step-by-step guide to configure Database Mirroring between SQL Server Instances in a Workgroup

 

Bu bloğun başına birşey gelme ihtimalini göz önüne alarak blog post'u buraya da kopyalıyorum.

[more]

=================

Step-by-step guide to configure Database Mirroring between SQL Server Instances in a Workgroup

 

This post is again in response to requests from customers who want to know how to configure Database Mirroring between instances of SQL Server 2005 in a WORKGROUP.

As you might have noticed, while configuring Database Mirroring using the GUI, it requires us to enter FQDNs of the servers; hence using the GUI, we can configure Database Mirroring between instances of SQL Server in a domain environment.

All credit goes to Varun for creating this step-by-step guide. I take the liberty to post it in my blog link.

Step 1: Create encryption key, certificate and end-points on Principal Instance

/* Execute this against the Principal Instance */
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password!'
GO
CREATE CERTIFICATE HOST_PRIN_cert
    WITH SUBJECT = 'HOST_PRIN certificate',
    START_DATE = '01/07/2009'
GO
CREATE ENDPOINT End_Mirroring
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING
    (
        AUTHENTICATION = CERTIFICATE HOST_PRIN_cert,
        ENCRYPTION = REQUIRED ALGORITHM RC4,
        ROLE = ALL
    )
GO
BACKUP CERTIFICATE HOST_PRIN_cert
    TO FILE = 'D:\certificate\HOST_PRIN_cert.cer'
GO

 

Step 2: Create encryption key, certificate and end-points on Mirror Instance

/* Execute this against the Mirror Instance */
USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password!'
GO
CREATE CERTIFICATE HOST_MIRR_cert
    WITH SUBJECT = 'HOST_MIRR certificate',
    START_DATE = '01/07/2009'
GO
CREATE ENDPOINT End_Mirroring
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5023, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING
    (
        AUTHENTICATION = CERTIFICATE HOST_MIRR_cert,
        ENCRYPTION = REQUIRED ALGORITHM RC4,
        ROLE = ALL
    )
GO
BACKUP CERTIFICATE HOST_MIRR_cert 
    TO FILE = 'D:\certificate\HOST_MIRR_cert.cer';
GO

Step 3: Create login, user and associate certificate with user on Principal Instance

/* 
*  Execute this against the Principal Instance. The HOST_MIRR_cert.cer
*  needs to be copied on the Principal Server.
*/
USE MASTER
GO
/*
*  We are creating a SQL Login here. For Windows logins,
*  use the Grant Login instead of Create Login
*/
CREATE LOGIN HOST_MIRR_login WITH PASSWORD = 'Password!'
GO
CREATE USER HOST_MIRR_user FOR LOGIN HOST_MIRR_login
GO
CREATE CERTIFICATE HOST_MIRR_cert
    AUTHORIZATION HOST_MIRR_user
    FROM FILE = 'D:\certificate\HOST_MIRR_cert.cer'
GO
GRANT CONNECT ON ENDPOINT::End_Mirroring TO [HOST_MIRR_login]
GO

 

Step 4: Create login, user and associate certificate with user on Mirror Instance

/* 
*  Execute this against the Mirror Instance. The HOST_PRIN_cert.cer
*  needs to be copied on the Mirror Server.
*/
USE MASTER
GO
/*
*  We are creating a SQL Login here. For Windows logins, 
*  use the Grant Login instead of Create Login
*/
CREATE LOGIN HOST_PRIN_login WITH PASSWORD = 'Password!'
GO
CREATE USER HOST_PRIN_user FOR LOGIN HOST_PRIN_login
GO
CREATE CERTIFICATE HOST_PRIN_cert
    AUTHORIZATION HOST_PRIN_user
    FROM FILE = 'D:\certificate\HOST_PRIN_cert.cer'
    GO
GRANT CONNECT ON ENDPOINT::End_Mirroring TO [HOST_PRIN_login]
GO

 

Step 5: Create encryption key, certificate and end-points on Witness Instance

/* Execute this against the Witness Instance */
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password!'
GO
CREATE CERTIFICATE HOST_WITT_cert
    WITH SUBJECT = 'HOST_WITT certificate',
    START_DATE = '01/07/2009'
GO
CREATE ENDPOINT End_Mirroring
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5024, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING
    (
        AUTHENTICATION = CERTIFICATE HOST_WITT_cert,
        ENCRYPTION = REQUIRED ALGORITHM RC4,
        ROLE = Witness
    )
GO
BACKUP CERTIFICATE HOST_WITT_cert
    TO FILE = 'D:\certificate\HOST_WITT_cert.cer'
GO

 

Step 6: Create login, user and associate certificate with user on Principal Instance

/*
*  Execute this against the Principal Instance. The HOST_WITT_cert.cer
*  needs to be copied on the Principal Server.
*/
USE MASTER
GO
/*
*  We are creating a SQL Login here. For Windows logins,
*  use the Grant Login instead of Create Login
*/
CREATE LOGIN HOST_WITT_login WITH PASSWORD = 'Password!'
GO
CREATE USER HOST_WITT_user FOR LOGIN HOST_WITT_login
GO
CREATE CERTIFICATE HOST_WITT_cert
    AUTHORIZATION HOST_WITT_user
    FROM FILE = 'D:\certificate\HOST_WITT_cert.cer'
GO
GRANT CONNECT ON ENDPOINT::End_Mirroring TO [HOST_WITT_login]
GO

 

Step 7: Create login, user and associate certificate with user on Mirror Instance

/*
*  Execute this against the Mirror Instance. The HOST_WITT_cert.cer
*  needs to be copied on the Mirror Server.
*/
USE MASTER
GO
/*
*  We are creating a SQL Login here. For Windows logins,
*  use the Grant Login instead of Create Login
*/
CREATE LOGIN HOST_WITT_login WITH PASSWORD = 'Password!'
GO
CREATE USER HOST_WITT_user FOR LOGIN HOST_WITT_login
GO
CREATE CERTIFICATE HOST_WITT_cert
    AUTHORIZATION HOST_WITT_user
    FROM FILE = 'D:\certificate\HOST_WITT_cert.cer'
GO
GRANT CONNECT ON ENDPOINT::End_Mirroring TO [HOST_WITT_login]
GO

 

Step 8: Create login, user and associate certificate with user on Witness Instance

/*
*  Execute this against the Witness Instance. The HOST_PRIN_cert.cer
*  and HOST_MIRR_cert.cer needs to be copied on the Witness Server.
*/
USE MASTER
GO
/*
*  We are creating a SQL Login here. For Windows logins,
*  use the Grant Login instead of Create Login
*/
CREATE LOGIN HOST_PRIN_login WITH PASSWORD = 'Password!'
GO
CREATE USER HOST_PRIN_user FOR LOGIN HOST_PRIN_login
GO
CREATE CERTIFICATE HOST_PRIN_cert
    AUTHORIZATION HOST_PRIN_user
    FROM FILE = 'D:\certificate\HOST_PRIN_cert.cer'
GO
GRANT CONNECT ON ENDPOINT::End_Mirroring TO [HOST_PRIN_login]
GO
/*
*  We are creating a SQL Login here. For Windows logins,
*  use the Grant Login instead of Create Login
*/
CREATE LOGIN HOST_MIRR_login WITH PASSWORD = 'Password!'
GO
CREATE USER HOST_MIRR_user FOR LOGIN HOST_MIRR_login
GO
CREATE CERTIFICATE HOST_MIRR_cert
AUTHORIZATION HOST_MIRR_user
FROM FILE = 'D:\certificate\HOST_MIRR_cert.cer'
GO
GRANT CONNECT ON ENDPOINT::End_Mirroring TO [HOST_MIRR_login]
GO

 

Step 9: Create the Mirrored Database on the Mirror Server using backups from the Principal Server

/*
*  Execute this against the Principal Instance.
*/
USE MASTER
GO
BACKUP DATABASE MirrorDB
    TO DISK = 'D:\Backups\MirrorDB_FullBackup.bak'
GO
BACKUP LOG MirrorDB
    TO DISK = 'D:\Backups\MirrorDB_LogBackup.trn'
GO
/*
*  Copy MirrorDB_FullBackup.bak and MirrorDB_LogBackup.trn to the
*  Mirror Server.
*  Execute this against the Mirror Instance.
*/
USE MASTER
GO
RESTORE DATABASE MirrorDB
    FROM DISK = 'D:\Backups\MirrorDB_FullBackup.bak'
    WITH NORECOVERY
GO
RESTORE LOG MirrorDB
    FROM DISK = 'D:\Backups\MirrorDB_LogBackup.trn'
    WITH NORECOVERY
GO

 

Step 10: Setup Mirroring

/*
*  Execute this against the Mirror Instance.
*/
ALTER DATABASE MirrorDB
    SET PARTNER = 'TCP://<>:5022'
GO
/*
*  Execute this against the Principal Instance.
*/
ALTER DATABASE MirrorDB
    SET PARTNER = 'TCP://<>:5023'
GO
ALTER DATABASE MirrorDB
    SET WITNESS = 'TCP://<>:5024'
GO

 

At this point your Database Mirroring should be up and running. You can use the Database Mirroring Monitor to verify the setup as well as to monitor the Synchronization status.

image

Disclaimer: All information provided here is my personal opinion and is neither verified nor approved by Microsoft before it is published. All information, and code samples, if any, is provided "AS IS" with no warranties and confers no rights.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2008 ile beraber Database Mirroring’e Auto Page Repair özelliği eklendi. Bu özellik ile beraber partner’ler (Mirroring yapılan sunucular birbirinin partner’idir) bozuk(corrupted) olan data page’leri birbirlerinden otomatik olarak recover etmeye çalışmaktadır. Herhangi bir page’i okuyamayan partner sunucu diğer sunucudan bu page’in düzgün olan halini istemekte, ve bu istek başarıyla sonuçlanırsa düzgün olan page corrupted yani bozuk olan page ile replace edilmektedir.

[more]

Auto Page Repair Yapılabilecek Page Tipleri

Auto Page Repair ile aşağıdaki page tipleri recover edilemez.

  • File header page (page ID 0).
  • Page 9 (the database boot page).
  • Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.

Bunun haricinde kalan page’ler Auto Page Repair ile partner’ler arasında otomatik olarak recover edilebilmektedir.

Auto Page Repair İşlem Adımları

Auto Page Repair işlemi aşağıdaki adımlardan oluşmaktadır.

  1. Principal database üzerinde bir data page’de okuma hatası gerçekleştiğinde, bu page’in ID bilgileri ve error mesajı suspect_pages table’ına yazılır. Daha sonra principal server bu page’in bir kopyasını secondary yani mirror sunucudan ister.Bu isteğin içinde page ID ve LSN bilgisi bulunur. Bu istekle beraber ilgili page restore pending statu’sunu çekilir ve bu sayede auto page repair süresi boyunca ilgili page’e erişimler engellenir. Eğer page’e bir istek gelirse 829 (restore pending) hata mesajı döndürülür.
  2. İstek mirror server’a eriştiğinde , mirror server ilgili page’e erişmeye çalışır. Eğer page’e erişimde bir sorun olmazsa mirror server ilgili page’i principal server’a gönderir. Eğer erişimde sıkıntı çıkarsa mirror server principal server’a hata mesajı döndürür.
  3. Principal server page’i alır ve işlemeye başlar. Yani mirror server’dan aldığı page’i kendi üstünde bulunan corrupted (bozuk) page ile replace eder.
  4. Auto page Repair işlemi tamamlandığında daha önce 1 no’lu adımda suspect_pages table’ına alınan ilgili page’in kaydı bu table’dan kaldırılır ve page erişime açılır.

Yapılan Auto Page Repair İşlemlerini Monitor Etmek

Auto Page Repair işleminin otomatik olarak gerçekleştiğini söyledik. Peki ne zaman hangi page auto repair oldu nasıl kontrol edebiliriz.

Bunun için SQL Server 2008 ile beraber yeni bir DMV gelmiş durumda.

image

sys.dm_db_mirroring_auto_page_repair DMV’si ile geçmişe dönük olarak gerçekleşmiş Auto Page Repair işlemleri sorgulanabilir.

Bu DMV her bir Auto Page Repair işlemi bir sonuç döndürür. Her bir database için maksimum 100 adet kayıt saklanır. Bu rakama ulaşıldığında yeni gelen kayıt eski kayıtlardan birinin üzerine yazılır.

Sorgu sonucunda gelen bilgilere bakacak olursak;

  • database_id = Repair işleminin yapıldığı page’in bulunduğu database’in ID’si
  • file_id = Page’in bulunduğu file’in ID’si
  • page_id = Page’in ID’si
  • error_type = Principal server’ın hatalı olan page üzerinde aldığı hata
  • page_status = Repair işleminin şu an için bulunduğu status
  • modification_time = Status’ta yapılan en son değişikliğin zamanı

 

Bugünkü yazımda Mirroring yapısına 2008 ile beraber eklenen Auto Page Repair işleminin ne olduğu, ne şekilde çalıştığı ve nasıl monitor edilebileceği üzerinde durduk. High Avaibility açısından önemli bir çözüm olan DB Mirroring’e eklenen bu güzel özelliği mirror sunucularınızda periyodik olarak monitor etmenizin gerekliliğini vurgulayarak yazımı noktalıyorum.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2011 Denali ile beraber gelen en büyük yenilik gruplarından biri yeni High Availability and Disaster Recovery seçenekleri. Bu yeni seçenekler ile beraber daha yüksek erişebilirlik sunulabilecek ayrıca daha güvenilir disaster recovery çözümleri kullanılabilecektir. Ayrıca yeni gelen bu özellik grubuna Always On’da denilmektedir.

[more]

Hali hazırda SQL Server’ın sunduğu High Availability and Disaster Recovery çözümleri aşağıdaki gibidir.

  • Failover Cluster Instance
  • Database Mirroring
  • Log Shipping

Bu çözümler bir çok işimizi çözmekle beraber sektörde daha iyi bir high availability beklentisi vardı. Microsoft’ta Denali’de sunduğu HADR çözümleri ile bu istekleri karşılamış gibi gözüküyor.

HADR ile gelen çözümleri şu anki klasik mirroring yapısının iyileştirilmesi gibi düşünebiliriz. Şimdi isterseniz HADR ile beraber neler geliyor madde madde bakalım.

HADR Altyapısı

HADR kullanmak için hepinizin tahmin edebileceği gibi birden fazla node gerekmekte. Bu node’lar üzerinde Windows Server Failover Cluster (WSFC) kurulu olmalı.

SQL Server tipi olarak cluster kurulum yapma zorunluluğu yok. Standalone SQL Server kurulumları ile de HADR kullanılabilmekte.

Multi-Database Failover

Şu anki mirror yapısı tek bir database seviyesinde tanımlanmakta. Mirror yapılan bu database’de bir sıkıntı oluştuğunda mirror database’den çalışmalara devam edilebilmekte.

Yani burada tek bir database’in failover yapmasından bahsediyoruz.

HADR ile gelen Availability Groups ile database grupları tanımlayabilir ve bu grubun içinde 1 database fail etse dahi grubun tamamını diğer sunucudan çalışır hale getirebileceğiz. Yani grup’un tamamı failover edebilecek.

Böyle bir ihtiyacın neden olabileceği üzerine konuşalım. Örneğin bir ticari program yaptınız ve müşteri bilgilerini bir database’de, satış bilgilerini de bir başka database’de tutuyorsunuz. Satış bilgilerini tuttuğunuz database’de de bazı SP’ler var ve bu SP’ler müşteri DB’sine giderek müşteri bilgilerini getirmekte. Böyle bir yapıda SP’lerin hata vermemesi için 2 DB’nin de aynı sunucu üzerinde bulunması gerekmekte. İşte böyle bir durumda örneğin müşteri DB’si fail edip diğer server’a giderken satış DB’si eski server’da kalmaya devam ederse bahsettiğimiz bu SP’ler hata verip çalışmayacaktır. İşte HADR ile beraber gelen Availability Groups seçeneği ile bu 2 DB’yi aynı grubun içine koyuyoruz ve bu 2 DB’den hangisi fail ederse etsin 2 sini birden mirror sunucudan kullanmaya başlıyoruz.

Şu anki CTP1 sürümündede Availability Groups içinde sadece 2 server bulundurulabilmekte.

Multiple Secondaries

Klasik mirroring çözümünde bir tane secondary yani mirror database bulundurabiliyorduk. HADR ile beraber gelen özelliklerden biri olan Multiple Secondaries yani birden fazla secondary bulundurabilme özelliği ile daha yüksek bir High Availability çözümü sağlamış olacağız.

Active Secondaries for Reporting

Belkide HADR ile beraber gelen en önemli özelliklerden biride secondary database’leri rapor amacı ile kullanabilmek. Bildiğiniz gibi şu anki klasik mirroring çözümünde mirror database’ler herhangi bir şekilde erişebilir durumda değildi  ve atıl olarak kalmaktaydı. Gerçi synonym ve snapshot ile bazı çözümler sunulmuş olmasına rağmen pek istediğimiz gibi çalışmamaktaydı.

HADR ile beraber artık secondary sunucularımızı kullanabilir yapıdayız. Bu durumda primary sunucuyu OLTP işlemleri için, synchronous yada asynchronous olarak beslenen secondary database’ide reporting amacı ile kullanarak ana server’daki yükü bölmemiz mümkün.

hadr

Bu arada CTP1’de sadece asynchronous mode desteklenmektedir.

Fast Client Connection Redirection

Gene klasik mirror yapısında primary database’den secondary database’e geçiş yapıldıktan sonra webconfig bilgilerimizi yeni sunucuya göre ayarlamamız gerekmekteydi. HADR ile beraber sağlanan virtual network name vasıtasıyla sunucular arasında database geçiş yaptıktan sonra herhangi bir connection string değişikliği yapmamız gerekmemekte. Bu yapıyı failover cluster sistemindeki virtual network name ile aynı şekilde düşünebilirsiniz.

Backup on Secondary Server

Backup’lama işlemi primary sunucudan yapılabileceği gibi secondary sunucudan da yapılabilir. Backup’ları secondary sunucudan alarak backup load’ını primary sunucunuzda kaldırabilirsiniz.

Primary’den alınan backup secondary için kullanılabilir, aynı şekilde secondary sunucudan alınan backup’ın da primary sunucu için kullanılması mümkündür.

AlwaysOn Dashboard

Bu kadar gelen yeni özellikle beraber bu özellikleri monitor etmek amacıyla yeni bir dashboard oluşturulmuş durumda. Tek bir ekrandan yeni HADR seçeneklerini monitor etmemiz mümkün.

 

Denali ile gelen/gelmesi planlanan yeni HADR özellikler bu şekilde. Daha sonraki yazılarımda bu özelliklerin teknik detaylarınada inmeye çalışacağım.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan