PostgreSQL'i Bulutta İşletmek: Bir O&M Mühendisinin Gözünden RDS ve TaurusDB

Bir veritabanını kurmak ile onu işletmek arasında büyük bir fark var. Kendi makinenizde initdb çalıştırıp bir PostgreSQL örneği ayağa kaldırmak dakikalar sürer; ama binlerce müşteri örneğini 7/24, öngörülebilir performansla ve veri kaybetmeden çalıştırmak bambaşka bir mühendislik disiplini gerektirir. Huawei Cloud'un PostgreSQL tabanlı servisleri (RDS ve TaurusDB) üzerinde O&M — Operations & Maintenance — tarafında çalışırken öğrendiğim en temel şey bu oldu.

Yönetilen servis ne demek?

Kullanıcı açısından RDS gibi bir servis, birkaç tıklamayla açılan bir PostgreSQL endpoint'idir. Perde arkasında ise şunlar döner:

• Provizyon ve yaşam döngüsü: Örnek oluşturma, sürüm yükseltme, ölçekleme, silme — hepsi otomasyonla, insan eli değmeden.
• İzleme ve teşhis: Bağlantı sayısı, replikasyon gecikmesi, disk doluluğu, yavaş sorgular... Sorunu müşteri fark etmeden önce yakalamak esas hedef.
• Yedekleme ve kurtarma: Düzenli tam/artımlı yedekler ve WAL arşivleme ile point-in-time recovery. Test edilmemiş yedek, yedek değildir.
• Yüksek erişilebilirlik: Birincil düğüm düştüğünde failover'ın saniyeler içinde ve veri kaybı olmadan gerçekleşmesi.

Genel resim kabaca şöyle görünür:

Agent sistemlerinin rolü

Benim odaklandığım katman, her veritabanı düğümünde çalışan agent bileşenleri. Agent, kontrol düzlemi (control plane) ile veritabanı süreci arasındaki köprüdür: metrik toplar, sağlık kontrolü yapar, kontrol düzleminden gelen komutları (yedek al, parametre değiştir, failover başlat) güvenli şekilde uygular.

Agent geliştirirken sürekli akılda tutulması gereken iki ilke var:

1. Agent asla veritabanının önüne geçmemeli. İzleme yapan bileşenin kendisi CPU veya I/O tüketip performansı düşürüyorsa, tedavi hastalıktan kötü demektir.
2. Kısmi arızada öngörülebilir davranış. Ağ koptuğunda, disk dolduğunda, kontrol düzlemi ulaşılamaz olduğunda agent'ın ne yapacağı tasarım aşamasında belirlenmiş olmalı. En tehlikeli senaryo, izole kalan bir agent'ın kendi başına "karar vermesi"dir — split-brain'lerin çoğu böyle doğar.

Bir failover'ın anatomisi

Yüksek erişilebilirliğin sınavı, birincil düğümün düştüğü andır. İyi tasarlanmış bir failover kabaca şu adımlardan geçer:

1. Tespit: Sağlık kontrolleri art arda başarısız olur. Tek bir başarısız ping failover tetiklememeli — geçici ağ dalgalanması ile gerçek arıza ayrılmalı.
2. Karar: Kontrol düzlemi, yedek düğümün replikasyon gecikmesini kontrol eder. Gecikme sıfıra yakınsa veri kayıpsız geçiş mümkündür.
3. Terfi: Yedek, birincil olarak terfi ettirilir; eski birincil izole edilir (fencing) ki iki düğüm aynı anda yazma kabul etmesin.
4. Yönlendirme: Bağlantı endpoint'i yeni birinciyi gösterir; istemciler yeniden bağlanır.

Bu adımların her biri saniyelerle ölçülür ve hepsinin otomasyonla, gece 3'te, kimse uyanmadan çalışması beklenir.

İzlenmesi gereken beş metrik

Metrik	Neden kritik?
Replikasyon gecikmesi	Failover'da veri kaybı riskinin doğrudan ölçüsü
Bağlantı sayısı / limiti	Bağlantı sızıntıları servisi sorgu çalıştırmadan düşürebilir
Disk doluluğu ve büyüme hızı	Dolu disk PostgreSQL'i yazma yapamaz hale getirir
Autovacuum ilerlemesi	İhmal edilirse bloat ve transaction ID wraparound riski
p99 sorgu gecikmesi	Ortalama iyi görünürken kuyruktaki kullanıcı acı çekiyor olabilir

PostgreSQL tarafında bu görünürlüğü sağlayan araçlar da belli: pg_stat_activity ve pg_stat_statements ile sorgu düzeyinde gözlemlenebilirlik, EXPLAIN (ANALYZE, BUFFERS) ile plan analizi ve WAL mimarisinin kendisi — replikasyon, yedekleme ve kurtarmanın hepsi oradan geçiyor.

Kapanış

Bulut veritabanı işletimi, yazılım mühendisliğinin en "görünmez" alanlarından biri: her şey yolunda gittiğinde kimse varlığınızı fark etmez. Ama tam da bu görünmezlik — sistemin sıkıcı derecede güvenilir olması — işin başarı ölçütü. Sonraki yazılarda izleme metriklerine ve failover senaryolarına daha yakından bakmayı planlıyorum.