Bu rehber neyi çözer?
PostgreSQL performansı yalnız CPU gücüne bağlı değildir. RAM, working set, storage latency, WAL yazma davranışı, autovacuum, checkpoint ve sorgu/index tasarımı birlikte sonucu belirler.
İşletim sistemi seçimi
PostgreSQL çok geniş platform desteğine sahiptir; üretimde Linux en yaygın seçeneklerden biridir. Ubuntu, Debian, RHEL türevleri gibi kurumsal Linux dağıtımları operasyon kolaylığı sağlar.
Windows üzerinde de çalışabilir; ancak mevcut otomasyon, monitoring, backup ve ekip uzmanlığı seçimde belirleyicidir.
CPU ve RAM
OLTP iş yüklerinde yüksek tek çekirdek performansı ve yeterli çekirdek sayısı önemlidir; paralel analitik sorgular daha fazla çekirdekten yararlanabilir.
RAM büyüdükçe işletim sistemi page cache, shared_buffers ve aktif veri setinin cache oranı iyileşebilir. Ayarlar gerçek workload ile ölçülmelidir.
Storage ve WAL
Düşük latency SSD/NVMe transaction log/WAL ve random read/write yükünde belirgin avantaj sağlar. WAL ile data dosyalarının ayrı hızlı storage üzerinde tutulması bazı workload’larda fayda sağlayabilir.
RAID seviyesi, write cache güvenliği, fsync davranışı ve sanallaştırma storage latency’si veri bütünlüğü ve performans açısından kritiktir.
Güvenlik
SCRAM-SHA-256 parola doğrulama, TLS, pg_hba.conf erişim politikaları, least privilege roller ve mümkünse network segmentasyonu temel katmanlardır.
Row Level Security, audit ihtiyacı, secret yönetimi ve OS hardening uygulama riskine göre değerlendirilmelidir.
HA ve backup
Streaming replication ve uygun failover yönetimi HA için kullanılabilir; HA backup yerine geçmez.
Base backup, WAL arşivleme ve point-in-time recovery ile RPO/RTO hedefleri test edilmelidir.
Sık Sorulan Sorular
PostgreSQL için Linux şart mı?
Hayır. PostgreSQL birçok platformda çalışır; Linux üretimde çok yaygındır fakat ekip ve uygulama gereksinimi önemlidir.
PostgreSQL için NVMe gerekli mi?
Zorunlu değildir; fakat latency ve IOPS hassas OLTP workload’larında NVMe ciddi avantaj sağlayabilir.
Replica backup yerine geçer mi?
Hayır. Replica mantıksal hata, yanlış DELETE veya ransomware etkisini kopyalayabilir; bağımsız backup gerekir.
Veritabanı Altyapınızı Birlikte Değerlendirelim
Workload, güvenlik, donanım, HA ve yedekleme gereksinimlerinize göre altyapıyı birlikte planlayabiliriz.
Mimari ve çalışma modeli
PostgreSQLde shared buffers, işletim sistemi cachei, bağlantılar ve sorgu çalışma belleği birlikte RAM tüketir. work_mem toplam sunucu bütçesi değil işlem/sorgu operatörü kapsamındaki bir ayardır; yoğun eşzamanlılık toplam kullanımı büyütebilir. WAL, checkpoint, vacuum ve replication slotları ayrı izlenir. pg_hba.conf, rol yetkisi ve TLS farklı erişim katmanlarıdır.
- 1Bağlantı ve sorgu
- 2Bellek/plan/kilit
- 3WAL ve veri dosyaları
- 4Vacuum/replica/kurtarma
Tasarım parametreleri
- Bellek çarpanı
- work_mem sorgu operatörleri ve paralel işlerle çarpılabilir; shared_buffers ve OS cache yanında toplam bütçeyi hesaplayın.
- WAL ve vacuum
- Checkpoint, replication slot ve uzun transactionı disk büyümesiyle ilişkilendirin; WAL’ı elle silmeyin.
- İş yükü ve sorgu dağılımı
- Okuma/yazma oranı, bağlantı sayısı, transaction süresi ve yoğun sorguları ölçün. Veritabanı boyutu tek başına donanım gereksinimini açıklamaz.
- Bellek ve depolama
- Çalışma kümesi, günlük yazması, geçici alan ve checkpoint davranışını ayrı inceleyin. Güvenilir yazma garantisi performans kadar önemlidir.
- Kurtarma zinciri
- Başlangıç yedeği, gerekli günlükler, yapılandırma ve anahtarların birlikte geri getirilebildiğini sınayın.
- Erişim ve değişiklik
- Uygulama rolü, yönetici rolü ve schema değişiklik yetkisini ayırın. Üretimde indeks veya parametre değişimini kontrollü yapın.
Hesap ve uygulama örneği
Örnek yoğun raporlama sırasında bellek, temp dosyaları, transaction süresi ve autovacuum davranışı kaydedilir. Replica geriliği yalnız bağlantı açık diye sıfır sayılmaz. Slot kaynaklı WAL tutma büyümesini inceleyin; pg_wal dosyalarını kapasite kazanmak için elle silmeyin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
SELECT application_name, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| WAL alanı sürekli büyüyor | Geride kalan slot veya archive başarısızlığı WAL tutuyor olabilir. | Slot, archive ve transaction istatistiklerini aynı anda kontrol edin. |
| CPU düşük, sorgu yavaş | Kilit, I/O veya istemci beklemesi baskın olabilir. | Yürütme planını ve bekleme türünü aynı sorgu için inceleyin. |
| Replica bağlı ama verisi eski | Gönderme, uygulama veya transaction beklemesi gerilik yaratabilir. | Son uygulanmış işlem ve kaynağın commit zamanını karşılaştırın. |
| Disk sürekli büyüyor | Günlük tutma, açık transaction, replication slot veya bakım ihtiyacı etkili olabilir. | Ürünün desteklediği istatistikleri inceleyin; günlükleri elle silmeyin. |
Kabul ve doğrulama kontrolleri
- Sorgu planı, WAL büyümesi ve replica durumunu uygulama yoğunluğu ile birlikte ölçün.
- Temsilî transactionları ve sorguları gerçek veri dağılımıyla test edin.
- Ayrı hedefe restore yapıp uygulama kayıtlarını doğrulayın.
- Yetkisiz okuma ve schema değişikliği denemelerini test kimliğiyle reddedin.
- Failover sonrasında tek yetkili yazıcı ve doğru bağlantı hedefini doğrulayın.
- Bakım sırasında kilit, günlük hacmi ve gecikme değişimini ölçün.
İlgili kavramlar
Transaction sınırı
Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.
İşlem günlüğü ve recovery zinciri
WAL, redo veya transaction log gibi mekanizmalar, veri değişikliklerinin kalıcılaştırılması ve kurtarılması için sıralı kayıt tutar; ürünler arasında ayrıntılar farklıdır. Veri dosyası kopyası ile işlem günlüklerinin zamanı ve zinciri uyumlu olmalıdır. Günlüklerin bulunması tek başına belirli bir zamana dönülebileceğini kanıtlamaz: başlangıç yedeği ve kesintisiz gerekli günlük aralığı da gerekir. Arşivleme gecikmesini, günlük hacmini ve geri oynatma süresini ölçün. Günlükleri kapasite kazanmak için rastgele silmeyin; saklama ve temizleme ürünün desteklediği yöntemle yapılmalıdır.
İndeks ve sorgu planı
İndeks, uygun sorgularda taranacak veriyi azaltabilir; her yeni indeks yazma, bakım ve depolama maliyeti getirir. Sütun sırası, seçicilik, filtre ve sıralama gereksinimi birlikte değerlendirilir. Sorgu yavaşlığını yalnız indeks yokluğuna bağlamayın: yanlış tahmin, kilit beklemesi, disk gecikmesi veya gereksiz veri taşıma da neden olabilir. Temsilî sorgunun yürütme planını ve gerçek satır sayılarını inceleyin. Değişikliğin okuma kazancını, yoğun yazma sırasında oluşturduğu maliyetle birlikte ölçün; üretimde kontrolsüz bakım işlemleri başlatmayın.
Kilit, bekleme ve deadlock
Eşzamanlı işlemler veri bütünlüğü için kilit veya sürümleme mekanizmaları kullanır. Uzun açık transaction, diğer işleri bekletebilir; deadlock ise birbirini bekleyen işlemler arasındaki döngüdür. Ürün bazı işlemlerden birini sonlandırabilir ve uygulamanın güvenli tekrar deneme yapması gerekebilir. Bekleyen sorgu ile onu bloke eden sorguyu birlikte inceleyin. İzolasyon seviyesini rastgele düşürmek veri tutarlılığını değiştirebilir. Transaction süresini kısaltma, tutarlı erişim sırası ve uygun indeks gibi seçenekleri aynı iş yükünde doğrulayın.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Replikasyonun kapsamı
Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.