Skip to main content

> debezium_ve_kafka_ile_değişen_veri_yakalama_(cdc)

Debezium ve Kafka ile Değişen Veri Yakalama (CDC)

Log tabanlı Değişen Veri Yakalama (CDC), uygulama verimini düşürmeden veya OLTP tablolarını kilitlemeden commit günlüğü değişikliklerini doğrudan veritabanı motorundan nasıl çeker?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)pattern

⚡ÖZET VE TEKNİK CEVAP

Düşük seviyeli veritabanı replikasyon günlüklerine (mantıksal çözümlemeli PostgreSQL WAL veya MySQL binlog) sahte bir replika gibi bağlanarak, çözümlenen satır bazlı değişiklikleri Kafka Connect üzerinden doğrudan Apache Kafka konularına akıtarak.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

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

Mekanizma

Debezium, Kafka Connect çalışma zamanında bir kaynak bağlayıcı (source connector) olarak çalışır. Yerel replikasyon protokollerini kullanarak ana veritabanına bağlanır. Tablo taraması yapan ve ara güncellemeleri/silmeleri kaçıran periyodik SQL SELECT sorguları çalıştırmak yerine, Debezium ham ikili işlem günlüğünü (WAL/binlog) ayrıştırır. Onaylanan (committed) her INSERT, UPDATE ve DELETE işlemi, satırın önceki ve sonraki durumunu, işlem meta verilerini ve sıra ofsetlerini içeren tipli bir olay yüküne dönüştürülerek bölümlenmiş Kafka konularına yayımlanır.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Gerçek zamanlı arama indeksi senkronizasyonu (Elasticsearch), önbellek geçersiz kılma boru hatları (Redis), veri ambarı besleme (Snowflake/Iceberg), outbox olay aktarımı ve ana sisteme sıfır yük bindiren olay tabanlı mikroservis entegrasyonu.

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

Kritik Risk
  • ✓
    1. ▸WAL Disk Taşması: Debezium bağlayıcısının takılması veya kopması nedeniyle veritabanının WAL günlüklerini silememesi, diski %100 doldurup ana veritabanını çökertmesi
  • ✓
    1. ▸Şema Değişim Uyumsuzluğu: Tablodan kolon silinmesi veya değiştirilmesinin bağlayıcıyı çökertmesi
  • ✓
    1. ▸İlk Enstantane Şişmesi: Dev tabloların ilk enstantane (initial snapshot) taramasının veritabanı kaynaklarını tüketmesi

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

PostgreSQL replikasyon yuvası gecikmesini (replication slot lag), Kafka Connect bağlayıcı durumunu, Debezium olay işleme gecikmesini (DB commit anı ile Kafka kayıt zamanı arasındaki fark) ve veritabanı boş disk alanını izlemek.

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

Diskin kontrolsüz dolmasını engellemek için PostgreSQL'de max_slot_wal_keep_size yapılandırın, güvenli şema evrimi için Avro/Protobuf ile Schema Registry kullanın ve büyük tablolar için artımlı (chunked) salt-okunur enstantaneler tanımlayın.

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

Ödünleşim

Uygulamaya sıfır kod yükü bindirerek saniye altı veri akışı sağlar; buna karşılık Kafka Connect altyapı yönetimi ve hassas veritabanı replikasyon yuvalarının sürekli izlenmesi zorunluluğunu getirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

TinyCTO Mimarisi: Ürün arama motoru daha önce 4 saat süren ve ödeme performansını vuran gece SQL dump scriptleri ile güncelleniyordu. Katalog veritabanına kurulan Debezium CDC sayesinde, satıcı fiyat güncellemeleri 120 ms içinde canlı arama indeksine yansıtıldı ve ana veritabanı CPU yükü %74 azaldı.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Log tabanlı CDC ile sorgu tabanlı (SELECT WHERE updated_at > t) CDC arasındaki fark nedir?

Log tabanlı CDC ana veritabanında CPU yoran tablo taramaları yapmadan, her ara güncellemeyi, işlem meta verisini ve fiziksel DELETE işlemlerini doğrudan işlem günlüğünden yakalar.
Q2

Debezium tarafından kullanılan bir PostgreSQL replikasyon yuvası terk edilirse hangi felaket yaşanır?

PostgreSQL WAL günlüklerini silmeyi durdurur ve tüm işlem kayıtlarını süresiz saklar; disk %100 dolduğunda ana veritabanı tamamen çöker.
Q3

Bir Debezium CDC olay yükünde tipik olarak hangi bilgiler yer alır?

Satırın önceki hali ('before'), güncel hali ('after'), işlem türü (c=oluşturma, u=güncelleme, d=silme), işlem zamanı ve veritabanı sıra numarası (LSN/offset).

Debezium ve Kafka ile Değişen Veri Yakalama (CDC) — Sıkça Sorulan Sorular

Debezium ana veritabanı yerine salt-okunur replikalardan veri akışı sağlayabilir mi?

PostgreSQL'de mantıksal çözümleme replikasyon yuvalarına yazmayı gerektirir ve geleneksel olarak ana sunucuda çalışır (PG16+ ile standby desteği gelmiştir). MySQL ise replikalardan binlog CDC okumayı doğrudan destekler.

Debezium veritabanı şema geçişlerini (DDL değişiklikleri) nasıl yönetir?

Debezium DDL komutlarını yakalar, dahili şema geçmişi konusunu günceller ve Schema Registry'ye yeni şemaları bildirerek tüketicilerin uyum sağlamasını mümkün kılar.

Kafka'da Debezium CDC olaylarının sıralaması garanti midir?

Evet, olaylar tablonun Birincil Anahtarı (Primary Key) ile bölümlendiği sürece. Kafka tek bir bölüm (partition) içinde kesin FIFO sıralaması sağlar.

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

Temel Gerçekler & İlkeler

  • ▸

    Debezium, Apache Kafka Connect çatısı üzerine kuruludur ve PostgreSQL, MySQL, SQL Server, Oracle ve MongoDB için kurumsal seviyede bağlayıcılar sunar.

  • ▸

    Log tabanlı CDC, periyodik anlık görüntü sorgularının aksine tüm durum geçişlerinin %100'ünü temsil eden gerçek bir değiştirilemez değişiklik akışı sağlar.

Yaygın Yanılgılar

  • ✗

    CDC'nin yalnızca büyük veri analitiği için olduğunu sanmak; arama senkronizasyonu, önbellek temizleme ve transactional outbox aktarımı gibi operasyonel çekirdek süreçlerde yaygın olarak kullanılır.

Karar Kılavuzu & Önceliklendirme

Alt servislerin ana veritabanına ek sorgu yükü bindirmeden ve kod değişikliği gerektirmeden gerçek zamanlı veri akışına ihtiyaç duyduğu durumlarda Debezium CDC kurun.

Doğrulanmış Kaynaklar & Referanslar