[Aior]

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?