DB ops'un üretim incident'lerinin çoğu geldiği yer
"Sistem çöktü" incident'lerinin şaşırtıcı büyük bir kısmı database katmanına izini sürer.Düzenli geri yüklenen yedekler
Yedekleme thread'inde detayla kapsanmış, ama database özelinde:- Mantıksal yedekler (Postgres için pg_dump, Mongo için mongodump).
- Fiziksel / blok düzeyi yedekler.
- WAL arşivleme / sürekli replikasyon — point-in-time kurtarma.
- Üç ayda bir restore test — minimum.
Replikasyon stratejileri
- Async replica — primary yazar, replica yetişir. Risk: replica yüksek write yükünde gecikir.
- Sync replica — primary replica onayını bekler.
- Multi-master — mümkün ama operasyonel olarak karmaşık.
- Logical replication — tablo düzeyinde, ETL için faydalı.
Çoğu iş yükü için: primary + 1-2 async replica yeterli.
Failover: test edilmiş
- Test edilmiş failover prosedürü.
- Failover'ı ele alan bağlantı katmanı (pgBouncer, ProxySQL).
- Belgelenmiş manuel failover adımları.
- Üç aylık failover drill.
Schema migrasyonları: en yüksek riskli düzenli faaliyet
- Geriye uyumlu migrasyonlar — şema değişikliği kullanan kod öncesi deploy edilir.
- İki aşamalı eklemeler — yeni kolon/tablo ekle, eski ve yeni yaz, backfill, yeni oku, eski yazmayı durdur, eski'yi düşür.
- Lock-free değişiklikler mümkün yerlerde.
- Uzun süren migrasyonlar batch'lerle — 1.000 satır, sleep arası.
Bağlantı yönetimi
- Uygulama düzeyinde connection pooling.
- Sunucu tarafı bağlantı limitleri muhafazakâr ayarlanmış.
- Sızıntıları önlemek için idle bağlantı timeout'ları.
- Exponential backoff ile bağlantı retry.
- "Database çöktü" için circuit breaker.
Observability
- Yavaş sorgu log'u.
- Lock waits.
- Replication lag.
- Bağlantı sayıları.
- Cache hit oranları.
- Disk kullanımı ve IOPS.
Yükseltmeler: planlı, test edilmiş, rolled
- Major version yükseltmeleri planlı sıklıkta.
- Üretim verisi stage kopyasında test.
- Rollback plan ile düşük trafik penceresinde planla.
- Postgres'te major version yükseltmeleri için logical replication kullan.
Read'leri ölçeklendirme
- Read-ağırlıklı iş yükleri için read replica'lar.
- Uygulama veya sorgu düzeyinde caching.
- Pahalı toplu sorgular için materialised view'lar.
- OLTP olmayan sorgular için denormalised secondary store'lar.
Write'leri ölçeklendirme
- Vertical scaling — ilk cevap, sıkça yeterli.
- Sharding — operasyonel olarak ağır.
- CQRS / event sourcing — mimari karar.
- Spesifik write desenleri için uzmanlaşmış store'lar.
Uyaracağımız bir desen
"Sadece küçük bir migrasyon." Üretim migrasyonları üretim deploy'larıyla aynı disiplini gerektirir.Her zaman karşılığını veren bir desen
"Database yavaşken ne yapılacak" runbook'u.DB ops pratiğiniz nedir?
Database ops is where most production incidents come from
A surprisingly large fraction of incidents trace to the database layer.Backups, restored regularly
- Logical backups (pg_dump, mongodump).
- Physical/block-level backups.
- WAL archiving/continuous replication.
- Restore tested quarterly.
Replication strategies
- Async replica — replica lag risk.
- Sync replica — primary waits.
- Multi-master — complex.
- Logical replication — useful for migrations, ETL.
For most workloads: primary + 1-2 async replicas is enough.
Failover: tested
- Tested failover procedure.
- Connection layer handles failover.
- Documented manual failover steps.
- Quarterly failover drill.
Schema migrations: highest-risk regular activity
- Backward-compatible migrations.
- Two-phase additions.
- Lock-free changes where possible.
- Long-running migrations in batches.
Connection management
- Connection pooling.
- Conservative server-side connection limits.
- Idle connection timeouts.
- Connection retry with exponential backoff.
- Circuit breaker for "database is down".
Observability
- Slow query log.
- Lock waits.
- Replication lag.
- Connection counts.
- Cache hit ratios.
- Disk usage and IOPS.
Upgrades
- Major versions on a planned cadence.
- Test on staging copy.
- Schedule for low-traffic windows with rollback plan.
- Use logical replication for major PG version jumps.
Scaling reads
- Read replicas.
- Caching at application or query level.
- Materialised views.
- Denormalised secondary stores.
Scaling writes
- Vertical scaling — first answer.
- Sharding — heavy.
- CQRS/event sourcing — architectural.
- Specialised stores for specific patterns.
One pattern we'd warn about
"It's just a small migration."One pattern that always pays off
A "what to do when the database is slow" runbook.What's your DB ops practice?
