Kategori: DBA Guide · PostgreSQL · Derin Mimari Konuları Teknik Seviye: Expert Okuma Süresi: 22–25 dakika Önerilen URL: /postgresql/autovacuum-tuning-xid-wraparound-prevention/ Referans Doküman: postgres.ai — How to Monitor Transaction ID Wraparound Risks

PostgreSQL'de Autovacuum yalnızca ölü satırları (dead tuples) temizleyen bir bakım mekanizması değildir. Aynı zamanda Multi-Version Concurrency Control (MVCC) mimarisinin sürdürülebilirliğini sağlayan ve Transaction ID (XID) Wraparound nedeniyle veritabanının kullanılmaz hale gelmesini önleyen kritik bir koruma sistemidir.

PostgreSQL'in klasik 32-bit işlem kimliği alanı yaklaşık 4,29 milyar farklı değerden oluşur. Ancak MVCC görünürlük karşılaştırmalarında kullanılan işlem yaşı mantığı nedeniyle yaklaşık 2,147 milyar işlem kimliklik güvenli karşılaştırma ufku bulunur.

Autovacuum mekanizması doğru yapılandırılmadığında, uzun süreli transaction'lar, replication slot'ları, yüksek işlem hacmi ve yetersiz I/O kapasitesi bir araya gelerek PostgreSQL cluster'ını wraparound koruma moduna sürükleyebilir.

Bu makalede PostgreSQL Autovacuum'un iç mimarisini, transaction ID yaşlanmasını, tuple freezing mekanizmasını, anti-wraparound vacuum davranışını, production tuning stratejilerini ve olası bir XID krizine müdahale yöntemlerini ayrıntılı olarak ele alacağız.

PostgreSQL'in MVCC mimarisinde satır sürümleri transaction kimlikleri üzerinden yönetilir. Her heap tuple'ının başlığında (heap tuple header) bulunan xmin ve xmax alanları satırın oluşturulması ve geçersiz hale gelmesiyle ilişkili işlem kimliklerini tutar.

PostgreSQL transaction ID'leri (XID) 32-bit tamsayı genişliğindedir. Normal XID alanında 0, 1 ve 2 özel rezerve değerlerdir:

• •0: InvalidTransactionId
• •1: BootstrapTransactionId
• •2: FrozenTransactionId

Normal transaction kimlikleri 3'ten başlayarak artar.

PostgreSQL Transaction ID (XID) Wraparound — 32-bit Alan, Yaşlanma Eşikleri ve Tuple Freezing Yaşam Döngüsü

*Şekil 1 — Şematik 32-bit XID halka gösterimi. Gerçek transaction görünürlüğü, XID'lerin mevcut karşılaştırma ufkuna göre yorumlanmasına bağlıdır.*

32-bit XID alanının yarısı ($2^{31} \approx 2{,}147{,}483{,}648$), modüler işlem sıralamasında geçmiş ve gelecek transaction'ları ayırt etmek için kullanılır.

Bir tuple'ın oluşturulduğu transaction yeterince yaşlandığında ($> 2^{31}$ işlem geride kaldığında), modüler aritmetik gereği eski XID değeri artık geçmişteki bir transaction olarak değil, gelecekteki bir transaction olarak yorumlanmaya başlar. Bu durumda o satır aniden görünmez hale gelir ve telafisi imkansız sessiz veri kaybı (silent data corruption) oluşur.

PostgreSQL bu sorunu freezing mekanizmasıyla çözer.

Modern PostgreSQL sürümlerinde freezing, tuple'ın görünürlük durumunun t_infomask içindeki HEAP_XMIN_FROZEN bitiyle *frozen* olarak işaretlenmesiyle gerçekleştirilir. Bu nedenle her freezing işlemi fiziksel olarak xmin alanının FrozenTransactionId değerine üzerine yazılması anlamına gelmez.

PostgreSQL Autovacuum altyapısı iki temel süreç grubundan oluşur:

1. 1Autovacuum Launcher: Arka planda sürekli çalışır, katalog tablolarını inceler, bakım gerektiren veritabanlarını belirler ve worker süreçlerinin başlatılmasını koordine eder.
2. 2Autovacuum Worker: Launcher tarafından ayağa kaldırılan ve ilgili tablolar üzerinde VACUUM ile gerektiğinde ANALYZE işlemlerini yürüten işçi süreçleridir.

Autovacuum'un görevleri yalnızca dead tuple temizliğiyle sınırlı değildir. Freezing, visibility map güncellemesi, alanın yeniden kullanılabilir hale getirilmesi (FSM - Free Space Map) ve sorgu planlayıcısı (optimizer) istatistiklerinin güncellenmesi de bakım yaşam döngüsünün ayrılmaz parçalarıdır.

PostgreSQL Autovacuum Mimarisi — Launcher, Worker Süreçleri ve Tetikleme Parametreleri

Normal VACUUM tetikleme eşiği varsayılan ayarlarda şu formülle hesaplanır:

Burada:

• •$V_b$: autovacuum_vacuum_threshold (varsayılan: 50 satır)
• •$V_s$: autovacuum_vacuum_scale_factor (varsayılan: 0.20 yani %20)
• •$N$: Tablonun tahmini canlı satır sayısı (reltuples)

PostgreSQL'in güncel sürümlerinde autovacuum_vacuum_max_threshold parametresi bu eşik için bir üst sınır sağlayabilir.

Varsayılan değerlerle 100 milyon satırlı bir tabloda, üst sınır uygulanmıyorsa:

Bu tablo için yaklaşık 20 milyon UPDATE veya DELETE işlemi birikmeden normal dead-tuple VACUUM tetiklenmeyebilir!

Her XID tüketen transaction (INSERT, UPDATE, DELETE veya SELECT ... FOR UPDATE), 32-bit kimlik alanının ilerlemesine katkıda bulunur.

Bir tablonun relfrozenxid değeri, o tablodaki eski transaction kimliklerinin güvenli biçimde dondurulmasına ilişkin ilerlemeyi temsil eder. Bu değer ile mevcut XID arasındaki yaş (age()) büyüdükçe risk katlanarak artar.

Veritabanı düzeyindeki XID yaşını sorgulamak için:

Veritabanı düzeyindeki datfrozenxid, cluster içerisindeki en eski tablonun freezing ilerlemesine bağlıdır. Bu nedenle en yaşlı tabloların incelenmesi kritik önem taşır:

Aşağıdaki tablo, XID yaşlanmasının ulaştığı kritik seviyeleri ve operasyonel risk durumunu göstermektedir:

*200 milyon varsayılan freezing tetikleme yaşını ifade eder; diğer ara değerler kurumsal sistemler için önerilen operasyonel alarm eşikleridir. PostgreSQL'in gerçek uyarı ve koruma davranışı sürüm ve konfigürasyona bağlıdır.*

Freezing, PostgreSQL'in eski transaction kimliklerini sonsuza kadar saklamak zorunda kalmadan MVCC geçmişini güvenli biçimde yönetebilmesini sağlar.

VACUUM, uygun tuple sürümlerinin transaction durumlarını kalıcı biçimde "herkes için görünür" (frozen) kabul edilecek hale getirir:

• •vacuum_freeze_min_age: Bir tuple'ın dondurulabilmesi için üzerinden kaç transaction geçmesi gerektiğini belirler.
• •vacuum_freeze_table_age: Tablonun tüm sayfalarını kapsayacak agresif freezing taramalarının tetikleme yaşını belirler.

relfrozenxid değerinin güvenle ilerleyebilmesi için tablodaki sayfaların taranması ve eski XID'lerin dondurulması şarttır.

PostgreSQL'de her tablonun ilişkili bir Visibility Map (VM) dosyası bulunur (_vm). Visibility map her sayfa için iki kritik bayrak (bit) tutar:

All-frozen sayfalar, sonraki VACUUM ve anti-wraparound taramalarında disk I/O yükünü sıfırlayarak devasa optimizasyonlar sağlar.

Autovacuum tuning için tek bir sihirli ayar seti bulunmamaktadır. Transaction yoğunluğu, tablo boyutu, dead tuple üretim hızı, storage I/O gecikmesi ve replika yükü birlikte değerlendirilmelidir.

Örneğin, yüksek güncelleme hacmine sahip büyük bir OLTP sipariş tablosu için aşağıdaki tablo düzeyindeki agresif ayarlar uygulanabilir:

*Bu değerler yüksek hacimli tablolar için başlangıç örneğidir; doğrudan üretim ortamına uygulanmadan önce staging ortamında test edilmeli ve I/O üzerindeki etkisi ölçülmelidir.*

• •autovacuum_max_workers: Eşzamanlı çalışabilecek azami autovacuum worker sayısını belirler (varsayılan: 3). Ancak worker sayısını artırmak tek başına çözüm değildir!
• •autovacuum_vacuum_cost_limit: Worker'ların toplam I/O kotasını belirler (varsayılan: 200 veya -1 ile genel limite bağlı). Çok sayıda worker bu kotayı aralarında paylaşır. Dolayısıyla limit artırılmadan yalnızca worker sayısı artırılırsa her worker daha yavaş çalışır!
• •autovacuum_vacuum_cost_delay: Kota aşıldığında worker'ın kaç milisaniye uyuyacağını belirler (PostgreSQL 12+'de varsayılan: 2ms).

Özellikle disk doygunluğu, checkpoint writeback ve WAL üretimiyle yarışan autovacuum süreçleri kullanıcı sorgularının latency değerlerini artırabilir. PostgreSQL 18'de worker yönetimi ve autovacuum cost algoritmalarının sürüme özgü iyileştirmeleri için resmi sürüm notları incelenmelidir.

Yalnızca mevcut XID yaşını bilmek yeterli değildir. Sistemin günlük XID tüketim hızı bilinmeden ne kadar zaman kaldığı öngörülemez.

Örneğin bir kurumsal veritabanında:

• •Mevcut en eski XID yaşı: 1.500.000.000 (1.5 milyar)
• •Günlük XID tüketimi: 20.000.000 (20 milyon/gün)
• •Planlanan kritik eskalasyon eşiği: 1.800.000.000 (1.8 milyar)

Bu durumda operasyonel müdahale penceresi şu formülle hesaplanır:

*Bu bir kapasite planlama projeksiyonudur. Freezing işlemi başarıyla ilerlemediği ve tüketim hızı sabit kaldığı varsayılmıştır. Gerçek kesinti zamanı tüketim dalgalanmalarına ve XID tutucularına göre değişebilir.*

Autovacuum arka planda sürekli çalışsa dahi, eski bir transaction veya askıda kalmış bir replikasyon mekanizması xmin ufkunu bloke ederek dead tuple temizliğini ve freezing ilerlemesini tamamen durdurabilir!

Özellikle şu 5 risk vektörü titizlikle taranmalıdır:

1. 1Uzun Süre Açık Kalan Transaction'lar: idle in transaction durumundaki oturumlar.
2. 2Eski `backend_xmin` Değerleri: Snapshot tutarak eski satırların silinmesini engelleyen analitik sorgular.
3. 3Logical Replication Slot'ları: Tüketilmeyen xmin ve catalog_xmin değerleri nedeniyle hem heap hem sistem kataloglarının dondurulmasını engeller.
4. 4Prepared Transaction'lar (2PC): PREPARE TRANSACTION ile başlatılıp unutulan oturumlar.
5. 5Standby Feedback (`hot_standby_feedback = on`): Standby üzerindeki uzun sorguların primary sunucudaki cleanup ufkunu geride tutması.

PostgreSQL'de bir tablo autovacuum_freeze_max_age (varsayılan: 200 milyon) sınırına ulaştığında, PostgreSQL anti-wraparound autovacuum sürecini zorunlu olarak başlatır.

Bu sürecin temel özellikleri şunlardır:

• •Normal autovacuum işlemlerinden çok daha yüksek operasyonel önceliğe sahiptir.
• •Tabloda autovacuum_enabled = false yapılmış olsa dahi PostgreSQL bu ayarı ezerek (override) anti-wraparound vacuum işlemini başlatır!
• •Kolay kolay SIGINT veya normal deadlock iptal mekanizmalarıyla durdurulamaz.

*Buradaki scan_pct, heap bloklarının tarama yüzdesidir. VACUUM süreci indeks temizliği ve truncating gibi diğer aşamaları da içerdiğinden bu değer tüm işlemin genel tamamlanma süresini doğrudan yansıtmaz.*

Bir PostgreSQL cluster'ında XID yaşı 1 milyarın üzerine çıkmış ve wraparound alarmı çalmışsa, aşağıdaki kritik müdahale sırası uygulanmalıdır:

1. 1En Yaşlı Tabloları ve Veritabanını Belirleyin: age(datfrozenxid) ve age(relfrozenxid) sorgularıyla krize yol açan ilk 5 tabloyu tespit edin.
2. 2Logları İnceleyin: PostgreSQL loglarında WARNING: database ... must be vacuumed mesajlarını ve autovacuum hata kayıtlarını doğrulayın.
3. 3Engelleri Temizleyin: pg_stat_activity üzerindeki eski transaction'ları sonlandırın (pg_terminate_backend), askıda kalmış 2PC prepared transaction'ları (pg_prepared_xacts) commit/rollback yapın, inaktif replikasyon slot'larını (pg_replication_slots) kaldırın.
4. 4Altyapı Kapasitesini Kontrol Edin: Disk doluluk oranını, I/O latency değerlerini ve vacuum_cost_limit kısıtlarını gözden geçirin.
5. 5Hedefli Manuel VACUUM (FREEZE) Başlatın: En yaşlı tablodan başlayarak kontrollü freeze çalıştırın.
6. 6İlerlemeyi Doğrulayın: pg_stat_progress_vacuum üzerinden taramayı izleyin ve işlem bitiminde age(relfrozenxid) değerinin düştüğünü teyit edin.

Kurumsal ortamlarda XID güvenliği için yalnızca tek bir metrik izlemek yeterli değildir. Aşağıdaki izleme matrisi Prometheus, Datadog veya Zabbix gibi platformlara entegre edilmelidir:

*Bu eşikler işlem hızı standart sistemler içindir. Günde 100 milyon XID tüketen aşırı yoğun bir sistemde 1.8 milyar eşiği kriz için yalnızca 3 gün bırakır; bu nedenle yüksek işlem hacimli ortamlarda alarmlar çok daha erken devreye girmelidir.*

İleri seviye Autovacuum yönetimi, parametreleri rastgele değiştirmekten ibaret değildir. Sağlıklı bir mimari için şu 5 ilke benimsenmelidir:

• •Workload-Aware Tuning (İş Yüküne Duyarlı Yapılandırma): Çok sık UPDATE alan dinamik OLTP tabloları ile salt-ekleme (append-only) yapılan log/arşiv tabloları birbirinden tamamen farklı scale_factor ve freeze politikaları gerektirir.
• •Partition-Aware Maintenance (Bölümlemeye Duyarlı Bakım): Milyarlarca satırlık devasa tablolar partition'lara bölünmelidir. Eski partition'lar bir kez dondurulduktan (all-frozen) sonra autovacuum bu sayfaları tamamen atlar ve kaynak tüketmez.
• •I/O-Aware Scheduling (I/O Duyarlı Zamanlama): Vacuum süreçlerinin yoğun checkpoint yazımları, disk yedeklemeleri ve zirve sorgu saatleriyle kaynak yarışına girmesi cost_limit ve cost_delay ile dengelenmelidir.
• •Replication-Aware Maintenance (Replikasyon Uyumlu Bakım): Replikasyon slot'ları, standby feedback süreleri ve uzun süren analitik snapshot'lar veritabanı bakım stratejisine entegre edilmelidir.
• •Predictive Observability (Tahmine Dayalı Gözlemlenebilirlik): Yalnızca statik eşiklerle değil, XID tüketim hızının zamana bağlı türevi alınarak olası krizler haftalar öncesinden öngörülmelidir.

PostgreSQL'de XID wraparound krizi, mimari prensipler anlaşıldığında ve proaktif izleme kurulduğunda %100 önlenebilir bir risktir.

Autovacuum'un sistem üzerindeki performans etkisini azaltmak amacıyla gereğinden fazla kısılması veya kapatılması, anlık sorgu gecikmelerini iyileştirir gibi görünse de arka planda felaket getirecek devasa bir teknik borç biriktirir.

Başarılı bir PostgreSQL operasyon modelinde üç unsur sürekli dengede tutulmalıdır:

1. 1İşlem Tüketim Hızı: Cluster'ın XID tüketme temposu.
2. 2Freezing İlerlemesi: Sayfaların ve satırların zamanında dondurulması.
3. 3Bakım Kaynak Kapasitesi: Autovacuum worker'larına sağlanan CPU, RAM ve I/O bütçesi.

Amaç Autovacuum'u olabildiğince az çalıştırmak değil; veritabanının transaction üretim hızına yetişebilecek şekilde sürekli, kontrollü, ölçülebilir ve öngörülebilir çalışmasını sağlamaktır.

Teknik ayrıntıları doğrulamak ve PostgreSQL sürümlerine göre parametre farklılıklarını incelemek için resmi dokümantasyon:

• •PostgreSQL Documentation — Routine Vacuuming
• •PostgreSQL Documentation — Preventing Transaction ID Wraparound Failures
• •PostgreSQL Documentation — Automatic Vacuuming Configuration
• •PostgreSQL Documentation — Monitoring Database Activity and VACUUM Progress
• •postgres.ai — How to Monitor Transaction ID Wraparound Risks

Bu makale dataiotech çoklu site stratejisinin derin mimari ayağını temsil eder. Tamamlayıcı operasyonel ve araç odaklı rehberler için:

• •🛠️ [dataxtools.com](https://dataxtools.com): PostgreSQL Autovacuum ve XID Wraparound İzleme Araçları Karşılaştırması — Prometheus Postgres Exporter, Datadog ve pg_stat_activity görselleştirme çözümleri.
• •🚨 [dataopsphere.com](https://dataopsphere.com): XID Wraparound Incident Response, Alerting ve Escalation Runbook — PagerDuty eskalasyon kuralları, kriz toplantısı şablonları ve adım adım acil müdahale prosedürleri.