Clusterlar Arası AlwaysOn Kurulumu-Distributed AlwaysOn(DAG)

Bu makalede SQL Server 2016 versiyonu ile hayatımıza giren Distributed AlwaysOn(DAG) özelliğinden bahsedeceğiz. • DAG Farklı Windows Failover Cluster (WSFC)’lar arası AlwaysON kurabilmemize olanak sağlamaktadır. • DAG kullanabilmemiz aktifleştirebilemiz için ortamlarımızın fiziksel, sanal yada bulutta olması bu özelliği kullanmamıza engel değildir.ortamlarımızda WFSC ve 5022,1433 portlarımızın erişimi olması yeterlidir. • SQL Sürümlerinin MS SQL 2016 ve üzeri sql sürümleri olmalıdır. SQL Özelliği olduğu için İşletim sisteminin farklılıkları engel değildir. • DAG yapılandırması Klasik AG yapılandırmasından biraz farklıdır. Normalde her bir AG dahil olduğu replikaları Primary ve Secondary olarak beslerken burada Hem kendi AG’ sinde bulunan replikaları hemde DAG’a bağlı olan İletici(Forwarder) AG yi besler. İletici(Forwarder) ile birlikte farklı secondarylerde beslenebilir. Bu durumlarda Primary harici 2. WSFC lerde dahil sadece read-only olarak hizmet verebilir. Failover edilip Primary olmadığı sürece. • Clusterless AlwaysON dan farkı, Clusterless AlwaysOn için yeni bir AG kurarken Cluster type=NONE olması gerekmektedir. Bu durumda mevcut clusterımıza dahil olan replikalarımızda […]

Clusterlar Arası AlwaysOn Kurulumu-Distributed AlwaysOn(DAG)

Bu makalede SQL Server 2016 versiyonu ile hayatımıza giren Distributed AlwaysOn(DAG) özelliğinden bahsedeceğiz.

• DAG Farklı Windows Failover Cluster (WSFC)’lar arası AlwaysON kurabilmemize olanak sağlamaktadır.
• DAG kullanabilmemiz aktifleştirebilemiz için ortamlarımızın fiziksel, sanal yada bulutta olması bu özelliği kullanmamıza engel değildir.ortamlarımızda WFSC ve 5022,1433 portlarımızın erişimi olması yeterlidir.
• SQL Sürümlerinin MS SQL 2016 ve üzeri sql sürümleri olmalıdır. SQL Özelliği olduğu için İşletim sisteminin farklılıkları engel değildir.
• DAG yapılandırması Klasik AG yapılandırmasından biraz farklıdır. Normalde her bir AG dahil olduğu replikaları Primary ve Secondary olarak beslerken burada Hem kendi AG’ sinde bulunan replikaları hemde DAG’a bağlı olan İletici(Forwarder) AG yi besler. İletici(Forwarder) ile birlikte farklı secondarylerde beslenebilir. Bu durumlarda Primary harici 2. WSFC lerde dahil sadece read-only olarak hizmet verebilir. Failover edilip Primary olmadığı sürece.
• Clusterless AlwaysON dan farkı, Clusterless AlwaysOn için yeni bir AG kurarken Cluster type=NONE olması gerekmektedir. Bu durumda mevcut clusterımıza dahil olan replikalarımızda Auto-Failover özelliği engellenir. DAG ile AG kurulumundaki Cluster Type=Windows Server Failover Cluster seçildiğinden aynı AG üzerinden hem clustera dahil olan replikalar otomatik Failover olabilecek hem de cluster dışı AG ler beslenebilecektir. Clusterless AlwaysOn Kurulumu için bknz:
• Sync yada Async olarak kullanılabilir.
• Auto-Failover özelliği bulunamamaktadır.
• Failoverlar’da FORCE_FAILOVER_ALLOW_DATA_LOSS seçeneği ile farklı WSFC’lerdeki AG lere Failover edilebilir.
• DAG’ı SSMS üzerinde izleyemiyoruz. DMV’ler yardımıyla Redo ve Commit zamanlarını kontrol edebiliriz.

Peki Neden Kullanmalıyız ?

1) Normal şartlarda Multi-Subnet AO ile aynı WSFC ye aldığımız farklı Subnetteki sunucuları AO ekleyerek tek bir primary node ile secondary nodeları besliyoruz. Bu yapıda Cluster ,witness ve vote bağımlılığımız oluyor. Bu şekilde Clusteri kaybettiğimizde tüm AG ler hizmet veremez durumlara geliyor. DAG ile bu senaryolarda Cluster, witness ve vote kendi cluster içinde olacağı için bağımlılık kalkmış oluyor. herhangi bir şekilde 1.Clusteri kaybettiğimiz senaryoda 2.Clusterımız hala ayakta kalıyor tabi manuel müdahale ile FORCE_FAILOVER_ALLOW_DATA_LOSS geçeneği ile data kaybı var ise kabul ederek failover yapılıp, ileticiyi primary olarak yapılandırabiliyoruz.

2) Farklı Clusterlar da bulunan bir çok prod ortamımız olduğunu düşünelim bu prod ortamların ise doğrulama yapmak için bir veri tabanına ihtiyacı var. Örneğin UserDB tüm prod-rapor ortamların UserDB içerisindeki User tablosunda sorgulama yapıyor. İşte tam bu noktada DAG ile farklı clusterlara UserDB veri tabanını Sync bir şekilde replikasyonunu sağlamana olanak tanır. Normal şartlarda UserDB veri tabanına sorguya gidip prod ortamda yük yaratacakken bu şekilde yükü yayarak erişilebilirlik daha da artırılabilir.

3) Sql Upgrade  (Sql Server 2016 >>> Sql Server 2017) sunucu değişikliği çalışmalarında da DAG kullanılabilir. SQL 2016 ile gelen bir özellik olduğu için daha önce ki sürümler desteklenmemektedir.

4) Windows Server 2012 r2 işletim sistemine sahip bir ortama sahibiz ve bu ortamı Windows Server 2016 yada daha üst versiyona sahip bir WSFC ortama taşımak istiyoruz. Bu aşamada da DAG yapılandırarak Geçişleri hızlı bir şekilde sağlayıp failover sonrası yeni clusterda olan tüm replikaları hızlı bir şekilde besleyerek ayağa kaldırabiliriz.

DAG yapılandırmak;

Bu yapılandırma ile mevcut bir AG de bulunan dbleri mevcut ortamı bozmadan DAG yöntemi ile farklı bir WSFC ortamına da replikasyonunu sağlayacağız ve failover yapacağız.

AG_CL2 Mevcutta WindowsFailoverCluster AO;

Kurulum;

1) Eğer AG yok ve DAG yapılmak isteniyorsa bir endpoint oluşturmak gerekiyor;

CREATE ENDPOINT [Hadr_endpoint]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (
ROLE = ALL,
AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM AES
)
GO

2) Endpointlere servis hesaplarını çapraz yetkilendiriyoruz. (Primary instance’ın service hesabını Secondary instance’da, Secondary İnstance’in service hesabını Primary’de);

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [testintra\tstsvcuser];

3) DAG’da bulunacak tüm AG lerde Çalıştırılır;

ALTER ENDPOINT Hadr_endpoint AS TCP (LISTENER_IP = ALL)
GO

4) Secondary instance’da yeni bir AG oluşturulur;

CREATE AVAILABILITY GROUP AG_RPT_TEST
WITH (CLUSTER_TYPE = NONE)
FOR
REPLICA ON N'DRCTSTAODB02' WITH (ENDPOINT_URL = N'TCP://DRCTSTAODB02.test.testintra.com:5022',
FAILOVER_MODE = MANUAL,
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50,
SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
SEEDING_MODE = AUTOMATIC)

 

5) Primary İnstance’da DAG yaratılır;

CREATE AVAILABILITY GROUP DAG_RPT_TEST
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
'AG_CL2' WITH
(
LISTENER_URL = 'TCP://TSTAODBV11.test.testintra.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
),
'AG_RPT_TEST' WITH
(
LISTENER_URL = 'TCP://DRCTSTAODB02.test.testintra.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);
GO

6) Secondary instance’da JOIN edilir;

ALTER AVAILABILITY GROUP DAG_RPT_TEST
JOIN
AVAILABILITY GROUP ON
'AG_CL2' WITH
(
LISTENER_URL = 'TCP://TSTAODBV11.test.testintra.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
),
'AG_RPT_TEST' WITH
(
LISTENER_URL = 'TCP://DRCTSTAODB02.test.testintra.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);
GO

 

7)DAG kurulumu tamamlandı.Secondary instanceda bulunan DBler Kullanılacaksa Sadece Read-Only olarak açılabilir.

ALTER AVAILABILITY GROUP [AG_RPT_TEST]
MODIFY REPLICA ON N'DRCTSTAODB02' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
GO

DAG İzleme:

DAG özelinde Sync durumlarının Kontrolü İçin;

Script1;

SELECT
ag.[name] AS [AG Name],
ag.is_distributed,
ar.replica_server_name AS [Underlying AG],
ars.role_desc AS [Role],
ars.synchronization_health_desc AS [Sync Status]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
ON ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

 

Script2;

SELECT ag.name AS [AG Name],
ag.is_distributed,
ar.replica_server_name AS [AG],
dbs.name AS [Database],
ars.role_desc,
drs.synchronization_health_desc,
drs.log_send_queue_size,
drs.log_send_rate,
drs.redo_queue_size,
drs.redo_rate,
drs.suspend_reason_desc,
drs.last_sent_time,
drs.last_received_time,
drs.last_hardened_time,
drs.last_redone_time,
drs.last_commit_time,
drs.secondary_lag_seconds
FROM sys.databases dbs
INNER JOIN sys.dm_hadr_database_replica_states drs
ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups ag
ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars
ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas ar
ON ar.replica_id = ars.replica_id
--WHERE ag.is_distributed = 1
GO

 

 

DAG ile beslenen secondary’ye failover;

1) Primary ve secondary instancelarda AG statülerini synchronized yap

ALTER AVAILABILITY GROUP [DAG_RPT_TEST]
MODIFY
AVAILABILITY GROUP ON
'AG_CL2' WITH
(
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
'AG_RPT_TEST' WITH
(
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
);

2) Kontrol için SYNCHRONIZED olmasını bekle!

select ag.name
, ag.is_distributed
, ar.replica_server_name
, ar.availability_mode_desc
, ars.connected_state_desc
, ars.role_desc
, ars.operational_state_desc
, ars.synchronization_health_desc
from sys.availability_groups ag
inner join sys.availability_replicas ar on ag.group_id=ar.group_id
left join sys.dm_hadr_availability_replica_states ars on ars.replica_id=ar.replica_id
where ag.is_distributed=1
GO

3) LSN kontrolü yapılır;

SELECT ag.name
, drs.database_id
, db_name(drs.database_id) as database_name
, drs.group_id
, drs.replica_id
, drs.synchronization_state_desc
, drs.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states drs
INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;

4) LSN’ler eşit ise primary instance da çalıştırılır.

ALTER AVAILABILITY GROUP [DAG_RPT_TEST] SET (ROLE = SECONDARY);

5) Failover Yapılır

ALTER AVAILABILITY GROUP [DAG_RPT_TEST] FORCE_FAILOVER_ALLOW_DATA_LOSS;

6) Failover oldu. Eski Primaryi kullanacaksak Async çekelim.

ALTER AVAILABILITY GROUP [DAG_RPT_TEST]
MODIFY
AVAILABILITY GROUP ON
'AG_CL2' WITH
(
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
),
'AG_RPT_TEST' WITH
(
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
);

7) Read-only yapmak istiyorsak;

ALTER AVAILABILITY GROUP [AG_CL2]
MODIFY REPLICA ON N'TSTAODBV11' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
GO

İyi çalışmalar.

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 3 hafta önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 1 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 1 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele