Sıfır Kesintili Veritabanı Migrasyonu için Claude promptu

# ROL
Sen 10+ yıl deneyimli bir veritabanı mühendisi ve DevOps mimarisisin. Özellikle yüksek-trafikli production sistemlerinde sıfır kesintili (zero-downtime) şema değişiklikleri ve veri migrasyonları konusunda uzmansın. Expand-contract pattern, online schema change araçları ve blue-green deployment stratejilerine hâkimsin.

# GÖREV
{proje_adi} projesindeki {veritabani_turu} veritabanında aşağıdaki şema değişikliğini uygulamam gerekiyor. Sistem 7/24 canlı ortamda hizmet veriyor; herhangi bir downtime kabul edilemez. Bu değişikliği güvenle production'a almak için eksiksiz bir sıfır-kesinti migrasyon planı oluştur.

# DEĞİŞİKLİK
{degisiklik_aciklamasi}
(Örnek: "orders tablosuna nullable `payment_method varchar(50)` sütunu ekleniyor" veya "users tablosundaki `status` sütunu enum'dan varchar'a dönüştürülüyor")

# SİSTEM BAĞLAMI
- Veritabanı: {veritabani_turu} (PostgreSQL 15 / MySQL 8 / MongoDB 7)
- Tablo büyüklüğü: {tablo_satir_sayisi} satır (örn: 80 milyon)
- Ortalama yazma yükü: {dakikada_yazma_sayisi} yazma/dakika
- Deployment stratejisi: {deployment_stratejisi} (Blue-Green / Rolling / Canary)
- ORM / Migration aracı: {orm_araci} (Alembic / Flyway / Prisma Migrate / Liquibase / ham SQL)
- Replikasyon: {replikasyon_konfigurasyonu} (örn: 1 primary + 2 async replica)
- Uygulama dili ve framework: {uygulama_dili_ve_framework}

# KURALLAR
1. Hiçbir adım tam tablo kilidi (EXCLUSIVE LOCK) almamalı; tüm DDL işlemleri non-blocking eşdeğeriyle yapılmalı.
2. Her SQL adımı idempotent olmalı (IF NOT EXISTS / IF EXISTS korumalı, tekrar çalıştırılabilir).
3. Her faz ayrı bir deployment'a karşılık gelmeli; DB değişikliği ve uygulama kodu değişikliği asla aynı anda yapılmamalı.
4. Index yaratmayı CONCURRENTLY (PostgreSQL) veya eşdeğer non-blocking yöntemle (MySQL: ALGORITHM=INPLACE, LOCK=NONE) uygula.
5. Backfill varsa 1.000–10.000 satırlık batch'lerle çalıştır; her batch sonrası `pg_sleep(0.1)` veya eşdeğer bir gecikme ekle.
6. Rollback süresini 5 dakikanın altında tut; her fazın geri-dönüş SQL'ini ayrıca yaz.
7. Veritabanına özel sözdizimi farklarını belirt: PostgreSQL için `CONCURRENTLY`, MySQL için `pt-online-schema-change` veya `gh-ost` seçeneğini, MongoDB için `collMod` kullanımını açıkla.

# ÇIKTI BİÇİMİ

## 1. Risk Değerlendirmesi
- Lock contention riski ve beklenen etki süresi
- Replication lag artış senaryosu
- Foreign key bağımlılıkları ve cascade etkileri
- Önerilen uygulama zaman penceresi (düşük-trafik saati)

## 2. Expand-Contract Planı (3 Faz)

### Faz 1 — Expand (Genişlet)
*Eski uygulama kodu kesintisiz çalışırken DB'ye uygula:*
```sql
-- Tam SQL (IF NOT EXISTS korumalı, idempotent)
-- CONCURRENTLY index yaratma
-- NOT VALID constraint (PostgreSQL) veya eşdeğeri
```

### Faz 2 — Transition (Geçiş)
*DB değişikliği stable olduktan sonra uygulama kodunu güncelle:*
- Dual-write mantığının pseudocode'u (eski + yeni sütuna aynı anda yazma)
- Feature flag / env değişkeni önerisi
- Backfill script'i (batch + sleep, progress tracking):
```sql
-- Batch backfill örneği
DO $$
DECLARE
  batch_size INT := 5000;
  last_id BIGINT := 0;
  max_id BIGINT;
BEGIN
  SELECT MAX(id) INTO max_id FROM {tablo_adi};
  WHILE last_id < max_id LOOP
    UPDATE {tablo_adi}
    SET {yeni_sutun} = {varsayilan_deger}
    WHERE id > last_id AND id <= last_id + batch_size
      AND {yeni_sutun} IS NULL;
    last_id := last_id + batch_size;
    PERFORM pg_sleep(0.1);
  END LOOP;
END;
$$;
```

### Faz 3 — Contract (Daralt / Temizle)
*Tüm uygulama instansları yeni kodu çalıştırıyor, backfill tamamlandı:*
```sql
-- Eski sütun/index kaldırma
-- NOT NULL constraint aktivasyonu (VALIDATE CONSTRAINT)
-- Artık kullanılmayan index temizliği
```

## 3. Rollback Planı
Her faz için:
- Rollback SQL'i
- Rollback kararı için metrik eşikleri (p99 latency, error rate, replication lag)
- Rollback süresi tahmini

## 4. Deployment Checklist
- [ ] Pre-migration: disk alanı ≥ tablo boyutunun 2 katı
- [ ] Pre-migration: replikasyon lag < 5 saniye
- [ ] Pre-migration: aktif bağlantı sayısı normal aralıkta
- [ ] Monitoring alarmları kuruldu (p99 latency, error rate, lag)
- [ ] Faz 1 uygulandı ve doğrulandı
- [ ] Backfill ilerleme sorgusu ile %100 doğrulandı
- [ ] Faz 3 temizlik tarihi takvime eklendi

## 5. Doğrulama Sorguları
```sql
-- Migration başarısını doğrulayan kontrol sorguları
-- NULL/boş satır sayısı kontrolü
-- Index varlığı ve boyutu kontrolü
```

# KALİTE KONTROL
- Her SQL adımı EXCLUSIVE LOCK almadan çalışıyor mu?
- Backfill batch'leri production yükünü boğmayacak şekilde ayarlandı mı?
- Rollback süresi her fazda 5 dakikanın altında mı?
- Her faz gerçekten ayrı bir deployment adımına karşılık geliyor mu?
- Veritabanına özel sözdizimi doğru kullanıldı mı?