Skip to main content

> katı_i̇ki_aşamalı_kilitleme_(2pl)_ile_çoklu_sürüm_eşzamanlılık_kontrolü_(mvcc)

Katı İki Aşamalı Kilitleme (2PL) ile Çoklu Sürüm Eşzamanlılık Kontrolü (MVCC)

Katı İki Aşamalı Kilitleme (2PL) veritabanlarında neden büyük okuma-yazma darboğazlarına yol açar ve MVCC mimarisi 'Okuyucuların Yazıcıları Asla Engellememesini' nasıl sağlar?

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

İlişkisel veritabanları eşzamanlı işlemlerde ACID izolasyon seviyelerini (Serializable, Repeatable Read) garanti etmek zorundadır. Geleneksel Katı İki Aşamalı Kilitleme (2PL / kötümser eşzamanlılık), okumalar için paylaşımlı kilit (S-lock), yazmalar için özel kilit (X-lock) koyar: Okuyanlar yazanları, yazanlar da okuyanları kilitler. Yoğun okuma yapılan bir sistemde uzun süren bir raporlama sorgusu tüm canlı müşteri güncellemelerini kilitler. Modern veritabanları (PostgreSQL, MySQL InnoDB, CockroachDB) 2PL yerine Çoklu Sürüm Eşzamanlılık Kontrolü (MVCC) kullanır: Bir satır güncellendiğinde satırın üzerine yazılmaz; işlem zaman damgasıyla (xmin/xmax) yeni bir sürümü oluşturulur. Okuyucular hiçbir kilit almadan kendi geçmiş anlık görüntülerini (snapshot) okur; böylece 'Okuyanlar Yazanları, Yazanlar da Okuyanları Asla Engellemez'.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

MVCC anlık görüntü izolasyonu ve görünürlük kurallarıyla çalışır:

1

Satır Sürümleme (Tuple Header): PostgreSQL'de her satır xmin (oluşturan işlem ID'si) ve xmax (silen/güncelleyen işlem ID'si) saklar.

2

Okuma Anlık Görüntüsü: Bir sorgu başladığında o anda çalışan işlemlerin anlık görüntüsünü alır. Bir satır sürümü ancak xmin değeri bu sorgudan önce commit edilmişse ve xmax boşsa (veya gelecekteki bir işleme aitse) görünür.

3

Vakumlama (Vacuum) ve Çöp Toplama: Hiçbir aktif işlemin göremediği eski satır sürümleri arka planda çalışan Vacuum/GC thread'leri tarafından temizlenir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

İlişkisel OLTP veritabanları (PostgreSQL, MySQL InnoDB), dağıtık SQL motorları (CockroachDB, YugabyteDB) ve yüksek eşzamanlı transactional sistemler.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓

    PostgreSQL'de unutulmuş uzun süren işlemlerin autovacuum temizliğini engellemesi sonucu milyonlarca ölü satırın (dead tuple / table bloat) birikmesi, diskin dolması ve tablo taramalarının 10 kat yavaşlaması

  • ✓

    Anlık Görüntü İzolasyonunda eşzamanlı güncellemelerin 'Write Skew' tutarsızlığı yaratması

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓

    Satır sayısı artmamasına rağmen PostgreSQL tablo boyutunun şişmesi (bloat)

  • ✓

    pg_stat_user_tables tablosunda n_dead_tup sayısının fırlaması

  • ✓

    pg_stat_activity içinde saatlerdir idle in transaction kalan işlemler görülmesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Katı işlem zaman aşımları uygulayın (idle_in_transaction_session_timeout = 60s)

  • ✓

    PostgreSQL autovacuum parametrelerini agresif temizlik yapacak şekilde ayarlayın

  • ✓

    kilitlenme olmadan tam serileştirilebilirlik için Serializable Snapshot Isolation (SSI) kullanın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

MVCC okuma-yazma kilit çekişmesini bitirir ve veritabanı verimini zirveye çıkarır; ancak satırların birden fazla sürümünü tuttuğu için ek disk alanı ve sürekli arka plan vakumlama (çöp toplama) maliyeti getirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

2PL kullanan bir bankacılık sistemi, ay sonu raporlaması sırasında kilitleniyordu çünkü 20 dakika süren bir analitik sorgu hesap tablosunu kilitliyor ve tüm ATM para çekme işlemleri zaman aşımına uğruyordu. MVCC ve Snapshot Isolation kullanan PostgreSQL'e geçildiğinde, 20 dakikalık rapor sorgusu tek bir kilit bile almadan kendi geçmiş anlık görüntüsünü okudu; bu sırada saniyede 5.000 ATM para çekme işlemi sıfır gecikmeyle çalışmaya devam etti.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Çoklu Sürüm Eşzamanlılık Kontrolünün (MVCC) temel altın kuralı nedir?

'Okuyanlar Yazanları, Yazanlar da Okuyanları Asla Engellemez.'
Q2

PostgreSQL'de bir uygulama bir işlemi saatlerce 'idle in transaction' durumunda açık bırakırsa ne olur?

Autovacuum o işlemden sonra oluşan ölü satırları (dead tuple) temizleyemez; bu da tablonun devasa şişmesine (table bloat) ve diskin dolmasına yol açar.

Katı İki Aşamalı Kilitleme (2PL) ile Çoklu Sürüm Eşzamanlılık Kontrolü (MVCC) — Sıkça Sorulan Sorular

Anlık Görüntü İzolasyonunda (Snapshot Isolation) 'Write Skew' hatası nedir?

İki eşzamanlı işlemin aynı veriyi okuyup, birbirlerinin yazdığı farklı satırlardan habersiz olarak global bir iş kuralını ihlal eden çelişkili yazmalar yapmasıdır.

Serializable Snapshot Isolation (SSI) 2PL kilitleri olmadan Write Skew hatasını nasıl engeller?

Bellekte okuma-yazma bağımlılık grafiklerini takip ederek ve döngüsel bir çakışma tespit edildiğinde çakışan işlemlerden birini otomatik iptal ederek (abort).

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸

    2PL enforces serializability via locks: readers block writers, writers block readers.

  • ▸

    MVCC stores immutable row versions, allowing non-blocking concurrent reads and writes.

  • ▸

    Uncommitted long-running transactions block Vacuum GC, causing catastrophic table bloat.

  • ▸

    Set idle_in_transaction_session_timeout to kill abandoned transactions automatically.

Yaygın Yanılgılar

  • ✗

    Yanılgı: Snapshot Isolation prevents all concurrency anomalies (Gerçek: Snapshot Isolation is susceptible to Write Skew; SSI is required for true serializability).

  • ✗

    Yanılgı: Updating a row in PostgreSQL modifies the disk block in-place (Gerçek: It writes a new row version and updates index pointers).

Karar Kılavuzu & Önceliklendirme

Always configure idle_in_transaction_session_timeout (e.g. 60 seconds) in PostgreSQL. Monitor n_dead_tup metrics and tune autovacuum_vacuum_cost_limit for write-heavy tables.

Doğrulanmış Kaynaklar & Referanslar