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

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:

Çift Yazma (Dual-Writing): Uygulama aynı anda hem eski hem yeni shard'lara yazar.

Geçmiş Veri Doldurma (Backfill): CDC worker'ları geçmiş verileri yeni shard'lara taşır.

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.

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

6 Boyutlu Mimari Analiz

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

Mekanizma

Çevrimiçi resharding 4 katı aşamada çalışır:

Çift Yazma: Ana yazmalar Shard V1'e yapılırken asenkron olarak Shard V2'ye de kopyalanır.

CDC ile Geçmişi Doldurma: Debezium tabloları kilitlemeden binlog üzerinden tüm eski veriyi V2'ye kopyalar.

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.

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

Kapsam

Ç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ı

Kritik Risk

✓
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

Metrikler

✓
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

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)

Ödünleşim

Ç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 Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

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

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.

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

[OFFICIAL_DOCUMENTATION]Vitess Documentation: Horizontal Resharding and VReplication Workflows— Vitess.io / CNCF