SQL Server Always On Mimarisinde Paralel Redo Blocking

Microsoft SQL Server 2016 ile birlikte hayatımıza giren ve SQL Server 2017, 2019 ile 2022 sürümlerinde default olarak etkin şekilde gelen Paralel Redo (Parallel Redo) mekanizması, Always On Availability Groups (AG) mimarisinde Secondary veritabanlarının Primary veritabanı ile senkronizasyon hızını optimize etmek amacıyla tasarlanmıştır.

Klasik Seri Redo (Serial Redo) yaklaşımında log kayıtları tek bir thread üzerinden sırayla işlenirken, Paralel Redo log kayıtlarını birden fazla worker thread’e dağıtarak ikincil sunucudaki log uygulama (redo) performansını ve dolayısıyla RTO (Recovery Time Objective) sürelerini ciddi oranda iyileştirir.

Ancak bu performans artışı, özellikle yüksek OLTP yükü altında ikincil sunucularda salt-okunur (read-only) sorguların çalıştırıldığı ortamlarda latch contention, worker thread tükenmesi ve bloklanma (blocking) gibi operasyonel zorlukları da beraberinde getirebilir.

Paralel Redo varsayılan olarak açık gelse de, SQL Server sürümleri arasında log işleme ve thread yönetimi algoritmalarında kritik evrimler yaşanmıştır:

SQL Server 2016 & 2017: Paralel Redo ilk sunulduğunda yüksek yazma (heavy write/DML) yükü altında secondary veritabanlarında beklenmeyen performans darboğazlarına yol açabilmekteydi. Özellikle bellek üzerindeki dirty pages yönetimi ve thread’ler arası koordinasyon sırasında yüksek CPU kullanımı ile birlikte DIRTY_PAGE_TABLE_LOCK veya PARALLEL_REDO_WORKER_WAIT_FOR_WORK wait type’ları sıkça gözlemlenmiştir.
SQL Server 2019: Microsoft, iş yükünün thread’lere dağıtılma mantığını ve dispatcher-worker mimarisini yeniden optimize etmiştir. Lock ve Latch çekişmeleri büyük oranda azaltılmış, log kayıtlarının paralel işlenme kararlılığı artırılmıştır.
SQL Server 2022: Read-Only Secondary sorgular ile Redo thread’lerinin aynı bellek sayfalarına ve log kayıtlarına erişim çakışmaları (contention) daha da minimize edilmiştir. Bellek ve log işleme mekanizmaları enterprise ölçekteki sistemler için tam kararlı hale getirilmiştir.

Paralel Redo sürecinde iki temel bileşen görev yapar:

Parallel Redo Dispatcher: Birincil sunucudan gelen transaction log kayıtlarını okur, sıraya koyar ve uygun worker thread’lere dağıtır.
Parallel Redo Worker: Dispatcher tarafından kendisine atanan log kayıtlarını ikincil veritabanındaki veri sayfalarına (data pages) uygular.

İkincil sunucu üzerinde salt-okunur sorgular çalıştırıldığında, bu sorgular (Select queries) ile Paralel Redo worker’lar aynı veritabanı sayfalarına erişmeye çalışabilir. Bu durumda şu sorunlar baş gösterir:

Latch Contention (DIRTY_PAGE_TABLE_LOCK): Redo thread’leri bellek alanlarını güncellemeye çalışırken read-only sorguların sayfa kilitleri nedeniyle beklemeye düşer.
Worker Thread Exhaustion: Veritabanı sayısının fazla olduğu ortamlarda her veritabanı kendi Paralel Redo thread grubunu oluşturur. Bu durum ikincil sunucudaki max worker threads havuzunu tüketebilir.

Bir veritabanının veya Always On grubunun Paralel mi yoksa Seri (Serial) Redo modunda mı çalıştığını öğrenmek için aşağıdaki DMV sorgusu kullanılır:

SELECT 
    db_name(database_id) AS DatabaseName,
    redo_queue_size,
    redo_rate,
    is_parallel_redo_enabled
FROM sys.dm_hadr_database_replica_states;

is_parallel_redo_enabled = 1: Paralel Redo aktif.
is_parallel_redo_enabled = 0: Seri (Serial) Redo aktif.

Paralel Redo’nun anlık olarak kaç adet worker thread tükettiğini ve hangi veritabanında kaç paralel görev çalıştığını izlemek için aşağıdaki DMV sorgusu çalıştırılır:

SELECT 
    DB_NAME(database_id) AS DatabaseName,
    COUNT(*) AS ParallelRedoTaskCount
FROM sys.dm_exec_requests
WHERE command = 'PARALLEL REDO TASK'
GROUP BY database_id;

Bu sorgu Secondary Replica üzerinde çalıştırılmalıdır. Primary sunucuda Redo işlemi gerçekleşmediği için bu sorgu Primary sunucuda boş sonuç dönecektir.

Düşük Task Sayısı (1 – 4 arası): Veritabanı üzerinde az yazma yükü olduğunu veya Paralel Redo’nun yeterli iş parçacığıyla sorunsuz çalıştığını gösterir.
Yüksek Task Sayısı (CPU/Core sayısına yakın değerler): İkincil sunucuda yoğun bir log işleme yükü olduğunu gösterir.
Task Sayısının SIFIR (0) Olması:
- Veritabanında hiçbir DML/log aktivitesi olmayabilir.
- Veya sistemde Trace Flag 3459 aktif edilerek Seri Redo moduna geçilmiş olabilir.

Seri Redo (Serial Redo) modu, SQL Server Always On mimarisinde ikincil (Secondary) sunucuya gelen transaction log kayıtlarının tek bir iş parçacığı (single thread) tarafından sırayla işlenmesidir.

Eğer ikincil sunucuda aşırı CPU kullanımı, thread tükenmesi veya read-only sorgularda aşırı kilitlenme (blocking) gözlemleniyorsa aşağıdaki adımlar uygulanmalıdır:

A. Trace Flag 3459 ile Seri Redo’ya Geçiş (Troubleshooting)

Paralel Redo mekanizmasının ikincil sunucuyu tıkadığı netleşirse, geçici veya kalıcı olarak Seri Redo moduna dönülebilir:

Geçici Olarak Etkinleştirme (SQL Server Restart Gerektirmez):DBCC TRACEON (3459, -1);
Geçici İşlemi Geri Alma (Paralel Redo’ya Dönüş):DBCC TRACEOFF (3459, -1);
Kalıcı Hale Getirme: Sql Configuration Managerde Startup Parameter kısmından ilgili Trace Flag’ın eklenmesi gerekmektedir.

Not: Trace Flag 3459 aktif edildiğinde SQL Server logları SQL Server 2014 ve öncesinde olduğu gibi tek thread ile sırayla işler (Serial Redo). Bu işlem kilitlenme/latch sorunlarını çözer ancak yüksek log üreten sistemlerde redo_queue_size (Redo Kuyruğu) birikmesine ve RTO sürelerinin uzamasına neden olabilir.

Çok sayıda veritabanına sahip Always On ortamlarında ikincil sunucuda thread yetersizliği yaşamamak için:

max worker threads ayarının varsayılan (0 – Otomatik) bırakıldığından emin olunmalı veya veritabanı sayısı x işlemci çekirdek sayısı hesaplanarak manuel artırılmalıdır.

SQL Server 2017, 2019 ve 2022’de Paralel Redo varsayılan olarak yüksek verimlilikle çalışır ve manuel bir müdahale gerektirmez. Ancak ikincil sunucuların aynı zamanda Read-Only raporlama amacıyla kullanıldığı ortamlarda latch ve blocking durumlarını izlemek kritik önem taşır. sys.dm_exec_requests ve sys.dm_hadr_database_replica_states üzerinden yapılan izlemelerde darboğaz tespit edilirse, Trace Flag 3459 en etkili sorun gidermalardan biri olarak değerlendirilmelidir.

Başka makalede görüşmek dileğiyle..

İsraf etmeyin. İsra-26

Bir yanıt yazın