PostgreSQL Sunucu Kiralama: Replikasyon, PITR ve Maliyet Rehberi

PostgreSQL sunucu kiralama, yalnızca bir Linux sunucusuna veritabanı yazılımını kurmak değildir. Kurumsal uygulamaların verileri büyüdükçe CPU ve RAM kadar disk gecikmesi, eşzamanlı bağlantı, yedekleme, güvenli erişim ve arıza sonrasında geri dönüş önem kazanır. Aynı işlemci ve bellek değerlerine sahip iki VPS veya fiziksel sunucu, depolama ve ağ koşulları farklıysa aynı PostgreSQL performansını sunmayabilir.

Kısa cevap: Önce gerçek sorgu yükünü ve veri büyüklüğünü ölçün. Sunucuyu CPU/RAM, SSD/NVMe depolama ve bağlantı kapasitesine göre boyutlandırın. Kritik iş yüklerinde streaming replication, bağımsız base backup + WAL arşivi ve point-in-time recovery (PITR) seçeneklerini ayrı ayrı değerlendirin. Replikasyonun yedekleme olmadığını kabul edin; veri kaybı ve hizmete dönüş hedeflerini gerçek testlerle doğrulayın.

Bu rehber SaaS ve B2B uygulama geliştiren firmalar, e-ticaret platformları, özel yazılım ekipleri ve BT yöneticileri içindir. Herhangi bir hizmet sağlayıcıya ait fiyat, sertifika, kesintisizlik yüzdesi veya performans garantisi iddia edilmez. Amaç, kurumsal sunucu kiralama teklifine işin gerektirdiği teknik kapsamı doğru yazmaktır.

1. PostgreSQL için VPS mi, dedicated sunucu mu?

VPS ve bulut sunucu, uygun kaynak tahsisiyle geliştirme, test, orta ölçekli üretim ve büyüyen uygulamalar için esnek bir seçenek olabilir. Ancak vCPU sayısı tek başına CPU performansını kanıtlamaz; ana makine üzerindeki kaynak paylaşımı, depolama katmanı ve ağ gecikmesi ayrıca incelenmelidir.

Dedicated fiziksel sunucu, sürekli yüksek işlem yükü, donanım izolasyonu veya özel disk/CPU konfigürasyonu gereken sistemlerde değerlendirilebilir. Fiziksel sunucu kiralamak ise otomatik yüksek erişilebilirlik, ayrı lokasyon veya yedekli veri koruma anlamına gelmez. Donanım arızasındaki müdahale ve muadil sunucu şartları teklifte belirtilmelidir.

İlk değerlendirmede tek uygulama mı, çok kiracılı SaaS mı, yoğun rapor üreten bir veri tabanı mı olduğunu kaydedin. Günlük ortalama yerine yoğun iş saatlerindeki sorgu sayısını, işlem süresini, bağlantı sayısını ve veri büyümesini ölçün. İki sunucu modelini aynı güvenlik, yedek ve yönetim kapsamıyla karşılaştırın.

2. CPU ve RAM: Veritabanı yükünü ölçmeden paket seçmeyin

PostgreSQL'de işlemci ihtiyacını yalnız veritabanı boyutu belirlemez. Karmaşık JOIN, sıralama, indeksleme, analitik sorgular ve aynı anda çalışan işlemler CPU kullanımını etkiler. Bazı sorguların paralel çalışabilmesi, kaç çekirdeğin gerçekten değer ürettiğini de değiştirebilir.

Bellek planında işletim sistemi önbelleği, shared_buffers, work_mem ve bakım işlemlerinin geçici bellek kullanımı birlikte değerlendirilmelidir. Çok yüksek work_mem değeri, eşzamanlı sorgularda beklenenden fazla toplam bellek tüketimine neden olabilir. Aynı RAM kapasitesi, yanlış sorgu veya bağlantı ayarıyla verimli kullanılamayabilir.

Teklifte ortalama ve tepe CPU, kullanılabilir RAM, aktif bağlantılar, veri büyümesi ve kaynak yükseltmesinde olası kesinti açıklanmalıdır. Birkaç gerçek iş gününün ölçümü, yalnız tahmin edilen vCPU/RAM paketine göre seçim yapmaktan daha güvenilir sonuç sağlar. İleride büyütülebilme koşulları da yazılı olmalıdır.

3. NVMe disk, IOPS, gecikme ve WAL yazma yükü

PostgreSQL için depolama seçerken yalnız kapasiteye bakmayın. İşlem yoğun veritabanlarında okuma-yazma gecikmesi, sürdürülebilir IOPS, throughput ve yoğun saatlerdeki davranış önemlidir. NVMe etiketi her iş yükünde belirli bir gecikme garantisi sağlamaz; paylaşımlı disk altyapısının özellikleri ayrıca sorulmalıdır.

Write-Ahead Log (WAL), veritabanı değişikliklerini dayanıklılık ve kurtarma için kaydeder. WAL üretimi işlem türüne, yazma hacmine ve yapılandırmaya göre değişir. Veri dizini, WAL ve geçici işlem alanlarının gerçek ihtiyacı ayrı ölçülmelidir. İşlem sırasında disk kuyruğu artarken CPU'nun boş kalması mümkün olabilir.

PostgreSQL'in resmî WAL yapılandırma belgesi, WAL seviyesinin arşivleme ve replikasyon özellikleriyle ilişkisini açıklar. RAID veya yerel snapshot, farklı hata alanında tutulan bağımsız yedeklerin yerini almamalıdır.

4. Streaming replication neden yedekleme değildir?

PostgreSQL'in standby ve streaming replication rehberinde, birincil sunucudaki WAL kayıtlarının standby sunucuya aktarılması ve standby'nin uygun şekilde salt okunur sorgulara hizmet verebilmesi açıklanır. Bu yaklaşım, birincil sunucu arızasında veri tabanını başka düğümde çalıştırma planına temel olabilir.

Ancak replikasyon, yanlışlıkla silinen kayıtları geri getiren bir yedekleme sistemi değildir. Silme, hatalı işlem veya uygulama kaynaklı yanlış değişiklik de uygun koşullarda diğer sunucuya ulaşabilir. Standby bulunduğu için PITR, ayrı kopya ve gerçek geri yükleme testi ihtiyacı ortadan kalkmaz.

İki sunucu farklı isimlerde olsa bile aynı fiziksel host, disk, güç veya ağ hata alanını paylaşabilir. Teklifte gerçek fiziksel ayrımı ve her bileşenin yönetim sorumlusunu öğrenin. Ayrı bir felaket kurtarma lokasyonu gerekliyse yalnız aynı tesiste ikinci sanal makine kullanmak yeterli olmayabilir.

5. Asenkron ve senkron replikasyon farkı

PostgreSQL streaming replication çoğu yapılandırmada asenkron çalışabilir. Birincil sunucuda işlem tamamlandığında standby henüz son değişiklikleri almamış olabilir. Bu yaklaşım düşük yazma gecikmesi sağlayabilse de birincil düğüm kaybedildiğinde kısa bir veri kaybı penceresi bulunabilir.

Senkron replikasyon ise seçilen onay koşullarına göre yazma işleminin tamamlanmasını standby yanıtına bağlayabilir. Daha yavaş veya uzak ağlarda yazma gecikmesi artabilir. Uygun standby ulaşılamazsa uygulama işlemlerinin nasıl davranacağı ayrıca incelenmelidir; iş sürekliliği yalnız “senkron” kelimesine indirgenemez.

Sıfır veri kaybı gibi iddialar, replikasyon modu, onay davranışı, ağ, failover ve gerçek tatbikatla sınanmadan pazarlama garantisi olarak kullanılmamalıdır. PostgreSQL'in yüksek erişilebilirlik dokümanı performans ve dayanıklılık arasındaki tercihleri açıklar.

6. PostgreSQL PITR ile hangi zamana geri dönülebilir?

Point-in-Time Recovery (PITR), uygun fiziksel temel yedek ve eksiksiz WAL arşiviyle veritabanı kümesini seçilen geçmiş bir zamana döndürmeye yardımcı olur. Örneğin yanlış bir toplu veri güncellemesinden hemen önceki duruma geri dönmek istenebilir. Ulaşılabilir zaman, alınmış yedeğe ve WAL dosyalarının eksiksizliğine bağlıdır.

PostgreSQL'in sürekli arşivleme ve PITR rehberi, base backup ve WAL arşivinin birlikte saklanması gerektiğini açıklar. Arşiv zincirinde eksik bölüm bulunması, belirli bir kurtarma noktasını olanaksız kılabilir. Yedek saklama süresi ve depolama kapasitesi bu zincire göre belirlenmelidir.

PITR doğrudan üretim sisteminde rastgele denenmemelidir. Yalıtılmış kurtarma sunucusunda test gerçekleştirin; uygulama bağlantıları, kritik tablolar, kayıt tutarlılığı ve erişim izinleri kontrol edilmelidir. Yedek dosyasının bulunması başarıyla geri dönebildiğinizi kanıtlamaz.

7. pg_dump, base backup ve WAL arşivi farkları

pg_dump, mantıksal veritabanı dışa aktarımı için kullanılır. Belirli bir veritabanını taşıma, nesneleri inceleme veya uygun koşullarda geri yükleme amacıyla yararlı olabilir. Fakat yalnız belli aralıklarla alınmış pg_dump kopyaları, aradaki her zamana fiziksel PITR yapılabileceği anlamına gelmez.

Base backup, PostgreSQL kümesinin fiziksel geri yükleme süreci için temel olabilir. WAL arşivi, kurtarma işleminin hedeflenen noktaya ilerlemesini sağlayan kayıtları tutar. Resmî PostgreSQL PITR belgesi, pg_basebackup aracını ve gerekli WAL dosyalarının nasıl yönetileceğini ele alır.

Teklifte hangi yedek türünün üretildiğini, nerede saklandığını, kaç gün tutulduğunu ve kimin doğruladığını sorun. Tek tablo kurtarma, tam küme kurtarma ve ikinci lokasyonda uygulamayı yeniden hizmete almak birbirinden farklı operasyonlardır; tümü aynı pakette varsayılmamalıdır.

8. Replication slot'ları ve WAL birikimi riski

Replication slot'ları, bağlı bir tüketicinin ihtiyaç duyduğu WAL kayıtlarının erken silinmesini engellemeye yardımcı olabilir. Fakat standby veya tüketici bağlantısı uzun süre kesilirse birincil sunucuda tutulan WAL büyüyebilir. Disk dolarsa en güçlü CPU/RAM paketi bile veritabanının doğru çalışmasını sağlayamaz.

PostgreSQL'in replikasyon yapılandırma rehberi, WAL gönderimi ve replication slot kaynaklarının ayarlarını açıklar. wal_keep_size gibi değerleri rastgele yükseltmek arşivleme, izleme veya failover tasarımının yerine geçmez.

Bu yüzden izleme planına WAL disk alanı, arşivleme hatası, replication slot birikimi, standby bağlantısı ve gerçek lag metriklerini ekleyin. Kurumsal sunucu izleme rehberimiz alarmları iş etkisine göre önceliklendirme yaklaşımını ele alır.

9. Güvenli PostgreSQL erişimi: VPN, TLS ve roller

Kiralık PostgreSQL sunucusunda veritabanı portunu herkese açık bırakmak, uzaktan erişim kolaylığı için doğru varsayılan çözüm değildir. Uygulama ile veritabanı mümkünse özel ağ veya kontrollü VPN üzerinden haberleşmelidir. Yönetici erişimi, uygulama bağlantıları ve yedekleme işlemleri için farklı yetki sınırları gerekir.

PostgreSQL'in pg_hba.conf belgesi, bağlantı kaynaklarına ve kimlik doğrulama yöntemlerine göre erişim kuralları tanımlanabileceğini belirtir. hostssl ile TLS gerektiren kurallar kullanılabilir; ancak istemci tarafında sertifika doğrulamasının da doğru yapılandırılması gerekir. trust gibi koşulsuz kimlik doğrulama yöntemleri güvenilmeyen uzak ağlar için uygun değildir.

Uygulama, raporlama, yedekleme ve replikasyon hesaplarını ayırın; en az yetki ilkesini uygulayın. Kimlik bilgilerinin saklanması, bağlantı logları ve güvenlik güncellemelerinin sorumlusu teklifte belirtilmelidir. Ağ ve güvenlik hizmetleri kapsamı ayrıca değerlendirilebilir.

10. pg_stat_activity ve pg_stat_statements ile izleme

PostgreSQL'de yavaşlığın nedeni her zaman sunucu kapasitesi değildir. Hatalı sorgu planları, gereksiz tam taramalar, uzun transaction'lar, indeks eksikliği, kilit beklemeleri ve çok fazla bağlantı uygulamayı yavaşlatabilir. Donanımı yükseltmeden önce hangi işlemlerin beklediğini ve hangi sorguların yoğun kaynak tükettiğini araştırın.

PostgreSQL'in resmî istatistik belgesi, pg_stat_activity ve pg_stat_replication gibi görünümleri açıklar. pg_stat_statements eklentisi ise uygun kurulumda SQL ifadelerinin planlama ve yürütme istatistiklerini incelemeye yardımcı olur; yapılandırma ve izin gereksinimleri bulunmaktadır.

CPU, RAM, disk gecikmesi, bağlantılar, uzun sorgular, kilit beklemeleri, replikasyon gecikmesi ve son başarılı yedeği aynı olay zaman çizelgesinde görmek yararlıdır. Bir SQL sorgusunun yavaşladığı anda disk veya ağ koşulları değişmişse kök nedeni daha doğru araştırabilirsiniz.

11. PostgreSQL yüksek erişilebilirlik ve failover testi

Primary ve standby kurmak, otomatik failover sisteminin de çalıştığını kanıtlamaz. Yeni primary'nin nasıl seçileceği, eski primary'nin yeniden devreye girmesinin nasıl engelleneceği ve uygulamanın yeni bağlantı adresini nasıl bulacağı farklı tasarım başlıklarıdır. Birden fazla yazılabilir primary oluşması veri tutarlılığı açısından ciddi risk yaratabilir.

İşletme kesinti hedeflerini belirlemeli; teknik ekip failover sırasında işlemlerin ve bağlantıların nasıl davranacağını test etmelidir. Uygulama bağlantı havuzu, DNS/VIP, kuyruk işlemleri, zamanlanmış görevler ve eski düğümün tekrar katılması kontrol edilmelidir. Canlı sistemde izinsiz failover tatbikatı yapılmamalıdır.

RPO, kabul edilebilir veri kaybı hedefi; RTO, hizmete hedeflenen dönüş süresidir. Bu hedefler sunucu sayısından türetilmemeli, iş etki analizi ve kurtarma testlerine dayanmalıdır. Yedekleme ve felaket kurtarma hizmetleri için yazılı kabul kriteri isteyin.

12. Yönetilen PostgreSQL hizmetinin sınırları

Bir Linux VPS'e PostgreSQL kurulmuş olması, yönetilen PostgreSQL hizmeti sunulduğu anlamına gelmez. İşletim sistemi yamaları, PostgreSQL sürüm güncellemeleri, izleme, kapasite raporu, yedekleme, veri tabanı sağlığı ve olay müdahalesi farklı operasyon katmanlarıdır.

Yönetilen sunucu hizmetlerini karşılaştırırken DBA müdahalesi, sorgu optimizasyonu, indeks tasarımı ve uygulama şeması değişikliğinin pakete dahil olup olmadığını yazılı öğrenin. Yazılım geliştirici, sistem yöneticisi ve veritabanı yöneticisinin görevlerini birbirine karıştırmayın.

Sürüm yükseltmesinde uygulama sürücüsü, PostgreSQL eklentileri ve uzantılarının uyumluluğu, gerekli testler, planlı bakım penceresi ve geri dönüş prosedürü bulunmalıdır. Güvenlik güncellemesini ertelemek risk yaratabilir; ancak üretime kontrolsüz değişiklik yapmak da iş sürekliliğini etkileyebilir.

13. PostgreSQL sunucu kiralama maliyet tablosu

PostgreSQL yazılımının açık kaynak olması, bu veritabanını kurumsal ölçekte işletmenin maliyetinin sıfır olduğu anlamına gelmez. Sunucu, disk, ağ, standby, bağımsız yedek, izleme, bakım, veri taşıma ve insan kaynağı giderleri birlikte hesaplanmalıdır.

12 veya 36 aylık toplam maliyet hesabında tekrarlayan ve tek seferlik giderleri ayırın. Bir sağlayıcıya ait güncel fiyatı görmeden örnek paket bedeli uydurmak doğru değildir. İki teklif aynı performans, RPO/RTO, destek ve güvenlik koşulları üzerinden karşılaştırılmalıdır.

14. Veritabanı taşıma ve devreye alma kontrol listesi

Mevcut sistemde PostgreSQL sürümünü, veri boyutunu, eklentileri, tablo ve indeksleri, collation/encoding özelliklerini, aktif bağlantıları ve iş saatlerini kaydedin. Uygulamanın kullandığı DNS, IP, bağlantı havuzu ve arka plan görevleri göç planında yer almalıdır.

Hedef Linux sunucusunda ağ, hesap yetkileri, disk/WAL alanı, yedekleme, replikasyon ve izleme doğrulanmalıdır. İzinli ve güvenli bir test verisiyle performans ve kurtarma tatbikatı yapılmalıdır. Üretim kesinti penceresi, son değişikliklerin aktarımı ve geri dönüş planı uygulama sahibiyle onaylanmalıdır.

Kabul testinde uygulama girişi, okuma-yazma işlemi, rapor, zamanlanmış işler, geri yükleme ve varsa failover denemesi ayrı ayrı tamamlanmalıdır. PostgreSQL sunucu kiralama teklifi alın bağlantısından mevcut veri hacmini ve kurtarma hedeflerini paylaşarak ihtiyaç analizi başlatabilirsiniz.

Sık sorulan sorular

1. PostgreSQL sunucu kiralamak için VPS yeterli mi?

Uygulamanın CPU, RAM, disk gecikmesi, eşzamanlı bağlantı ve izolasyon ihtiyacına göre VPS yeterli olabilir. Sürekli yüksek yükte dedicated sunucu da değerlendirilebilir. Karar ölçümle verilmelidir.

2. PostgreSQL streaming replication yedekleme midir?

Hayır. Replikasyon değişiklikleri standby'ye aktarır; hatalı silme veya istenmeyen güncelleme de çoğaltılabilir. Bağımsız yedek ve geri yükleme testi gereklidir.

3. PostgreSQL PITR için hangi veriler gereklidir?

Uygun fiziksel base backup ve hedef zamana ulaşmak için gereken eksiksiz WAL arşivi gerekir. Yalnız pg_dump tutmak fiziksel PITR sağlandığı anlamına gelmez.

4. Senkron replikasyon otomatik sıfır veri kaybı garantiler mi?

Her senaryoda değil. Onay davranışı, standby erişimi, ağ, failover ve kurtarma tasarımı birlikte değerlendirilmelidir. Somut veri kaybı hedefi gerçek testle doğrulanmalıdır.

5. PostgreSQL portunu internete açmak gerekir mi?

Hayır. Uygulama ve yöneticiler mümkünse özel ağ veya kontrollü VPN üzerinden erişmelidir. TLS, uygun kimlik doğrulama, IP sınırı ve en az yetki kullanılmalıdır.

6. PostgreSQL için NVMe tek başına yeterli performans sağlar mı?

Hayır. İşlemci, RAM, sorgu/indeks tasarımı, bağlantı yönetimi, disk gecikmesi ve WAL yükü birlikte etkilidir. NVMe etiketi belirli performans garantisi değildir.

7. Yönetilen PostgreSQL hizmetinde ne olmalı?

İşletim sistemi ve PostgreSQL güncellemesi, izleme, yedekleme, replika kontrolü ve olay müdahalesinin kapsamı yazılmalıdır. Sorgu optimizasyonu veya uygulama geliştirme desteği otomatik olarak dahil varsayılmamalıdır.

Teknik kaynaklar ve sonuç

Teknik açıklamalar PostgreSQL'in resmî standby/replikasyon, WAL/PITR, kimlik doğrulama, istatistik izleme ve pg_stat_statements belgeleri temel alınarak hazırlanmıştır. Kullanılan veritabanı sürümünün gerçek dokümantasyonu proje başlangıcında ayrıca doğrulanmalıdır.

Sonuç: Sağlam PostgreSQL sunucu kiralama teklifi yalnız CPU, RAM ve SSD kapasitesi değildir. Performansın ölçüldüğü, veri erişiminin korunduğu, WAL ve yedeklerin izlendiği, standby davranışının test edildiği ve kurtarma sorumluluğunun yazılı olduğu bir altyapıdır. Kurumsal PostgreSQL sunucu teklifi alın ve gerçek veri yükünüz ile RPO/RTO hedeflerinizi paylaşın.