Skip to main content

> sıfır_kesintili_çevrimiçi_veritabanı_yeniden_parçalama_(resharding)_ve_çift_yazma_geçişi

Sıfır Kesintili Çevrimiçi Veritabanı Yeniden Parçalama (Resharding) ve Çift Yazma Geçişi

Mühendislik ekipleri, kapasitesi dolan bir veritabanı shard'ını (ör. 16'dan 32 shard'a) canlı üretimde kesinti, veri kaybı veya tutarsızlık olmadan nasıl böler?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

Tek bir veritabanı shard'ı donanım sınırlarına (IOPS kilitlenmesi, terabayt disk limitleri) ulaştığında veritabanının yeniden parçalanması (resharding) gerekir. 7/24 çalışan bir sistemde platformu 12 saatlik bir bakım penceresi için kapatmak kabul edilemez. Vitess ve Slack tarafından olgunlaştırılan 'Sıfır Kesintili Çevrimiçi Resharding Protokolü' 4 aşamada yürütülür: (1) Çift Yazma (Dual-Writing): Uygulama aynı anda hem eski hem yeni shard'lara yazar. (2) Geçmiş Veri Doldurma (Backfill): CDC worker'ları geçmiş verileri yeni shard'lara taşır. (3) Sürekli Tutarlılık Doğrulaması: Arka plan mutabakat servisleri satır bazında sağlama toplamı (checksum) ile %100 eşitliği kanıtlar. (4) Dinamik Geçiş (Cutover): Milisaniyeler içinde okuma trafiği yeni shard'lara çevrilir ve eski shard'lar güvenle emekliye ayrılır.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Çevrimiçi resharding 4 katı aşamada çalışır: (1) Çift Yazma: Ana yazmalar Shard V1'e yapılırken asenkron olarak Shard V2'ye de kopyalanır. (2) CDC ile Geçmişi Doldurma: Debezium tabloları kilitlemeden binlog üzerinden tüm eski veriyi V2'ye kopyalar. (3) Canlı Mutabakat: Otomatik bir denetçi iki küme arasında sağlama toplamı (MD5 checksum) alarak eksik veya farklı satırları anında düzeltir. (4) Atomik Okuma Geçişi: Sharding proxy'si (Vitess) okumaları V2'ye çevirir; 72 saat sıfır hatayla çalıştıktan sonra V1'e yazma tamamen kapatılır.

2. Doğru Kullanım Senaryosu

Çok kiracılı B2B SaaS veritabanları, dev e-ticaret ürün katalogları, fintech işlem kayıtları ve 10TB'ı aşan sosyal ağ veri katmanları.

3. Prodüksiyon Arıza Modları

Geçmiş veri kopyalaması (backfill) %100 bitmeden okuma trafiğini yeni shard'a çevirip müşterilere eksik/eski veri göstermek; V1'deki güncellemenin V2'yi, onun da tekrar V1'i tetiklediği sonsuz döngüsel çift yazma fırtınası yaratmak.

4. Teşhis ve Telemetri Sinyalleri

Ana shard disk doluluğunun %85'i aşması; tek sunucunun IOPS sınırına dayanması yüzünden yazma gecikmelerinin katlanması; V1 ile V2 arasındaki replikasyon gecikmesinin tepe saatlerde açılması.

5. Önleme ve Mimari Bariyerler

Çift yazma boru hatlarında `idempotent upsert` kuralları uygulayın; canlı veritabanı CPU'sunu boğmamak için CDC taşıma hızını limitleyin; okumayı çevirmeden önce %100 satır mutabakatını zorunlu tutun; acil durumlar için okumayı tek tıkla V1'e geri döndüren anlık rollback bayrağı bulundurun.

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

Çevrimiçi resharding geçiş sürecinde geçici olarak 2 katı veritabanı sunucu maliyeti ve mutabakat yazılımı eforu gerektirir; ancak yüz binlerce dolarlık saatler süren kesintileri tamamen engeller.

Vaka İncelemesi (TinyCTO Örneği)

Slack, ana MySQL mesaj deposunu Vitess kullanarak kesintisiz şekilde 16'dan 64 shard'a çıkardı. 4 hafta boyunca milyonlarca kanal yeni sunuculara kademeli olarak bölündü. Çift yazma ve VReplication ile 40TB mesaj sürekli satır doğrulamasıyla kopyalandı. Nihai geçiş Salı günü tepe trafikte yapıldı: Sıfır düşen sorgu, sıfır saniye kesinti ve milyonlarca aktif kullanıcıya hiç hissettirilmeden işlem tamamlandı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Sıfır Kesintili Çevrimiçi Veritabanı Resharding protokolünün 4 temel aşaması nedir?

1. Çift Yazma (Dual-Writing), 2. Geçmiş CDC Veri Doldurma, 3. Checksum Mutabakatı, 4. Atomik Okuma Geçişi.
Q2

Okuma trafiğini yeni shard'lara çevirmeden önce neden satır bazında checksum denetimi zorunludur?

Eski ve yeni shard'lar arasındaki %100 veri eşitliğini matematiksel olarak kanıtlamak ve kullanıcıya eksik/eski veri gösterilmesini engellemek için.

Sıfır Kesintili Çevrimiçi Veritabanı Yeniden Parçalama (Resharding) ve Çift Yazma Geçişi — Sıkça Sorulan Sorular

Veritabanı resharding bağlamında Vitess nedir?

MySQL'i yatayda ölçekleyen ve sıfır kesintiyle otomatik çevrimiçi resharding (VReplication) sunan bulut yerlisi bir kümeleme sistemidir.

Çift yazma (dual-write) sırasında döngüsel replikasyon fırtınaları nasıl önlenir?

Yazma işlemlerine kaynak etiketi koyarak (`origin=client` veya `origin=cdc_replicator`); migrasyon aracından gelen olayların tekrar kopyalanmasını engelleyerek.

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

Temel Gerçekler & İlkeler

  • ▸Online resharding splits saturated shards without taking the platform offline.
  • ▸The 4-stage workflow: Dual-Write -> CDC Backfill -> Checksum Verification -> Cutover.
  • ▸Never switch read traffic without validating 100% row equivalence via checksums.
  • ▸Always maintain an instant 1-click feature flag to revert reads if anomalies occur.

Yaygın Yanılgılar

  • ✗Yanılgı: Resharding requires a scheduled weekend downtime maintenance window (Gerçek: Modern CDC and dual-writing enable 100% online cutover).
  • ✗Yanılgı: Dual-writing is sufficient without backfill verification (Gerçek: Transient network blips inevitably drop rows; active reconciliation is required).

Karar Kılavuzu & Önceliklendirme

Use Debezium or Vitess VReplication for managed CDC streams during database migrations. Implement automated row-hash reconciliation jobs before initiating read flips.

Doğrulanmış Kaynaklar & Referanslar