PostgreSQL major sürüm yükseltmesinin başarılı olduğunu yalnızca servisin açılmasıyla anlayamazsınız. Uygulama bağlanabilir, ilk sorgu cevap verebilir; buna rağmen raporlar yavaşlayabilir, bir extension yüklenmeyebilir veya yeni kayıtların kimlik üretimi sorun çıkarabilir. SaaS ekipleri için asıl soru “veritabanı çalışıyor mu?” değil, “iş akışlarımız hedef sürümde doğrulanmış biçimde çalışıyor mu?” olmalıdır.

Bu rehber, yükseltme komutlarından önce hazırlanması gereken kabul dosyasına odaklanır. Amaç yöntem seçimini, uygulama testini ve geri dönüş sınırını aynı planda buluşturmaktır. Örneğin PostgreSQL topluluğunun takviminde 14 sürümünün destek sonu 12 Kasım 2026 olarak yer alır. Destek tarihi çalışmayı başlatmak için gerekçedir; aceleyle, provasız geçiş yapmak için gerekçe değildir.

PostgreSQL major yükseltme öncesinde neyi envantere almalısınız?

Önce mevcut major ve minor sürümü, işletim sistemini, veritabanı boyutlarını, extension listesini ve bağlantı katmanını kaydedin. Uygulamanın kullandığı sürücüleri, ORM sürümünü, bağlantı havuzunu ve kimlik doğrulama yöntemini de ekleyin. Aynı sunucudaki farklı uygulamalar aynı uyumluluk seviyesinde olmayabilir. Listeyi “PostgreSQL kullanıyoruz” cümlesine indirgemek, gerçek riski görünmez yapar.

Hedef major için extension paketlerinin bulunması ve desteklenmesi ayrıca doğrulanmalıdır. Sunucuya kurulu olması, hedef sürümde doğru davranacağı anlamına gelmez. Collation sağlayıcısı ve sürümü, zaman dilimi beklentileri, özel veri tipleri ve uygulamaya ait fonksiyonlar kontrol kapsamındadır. Aradaki major sürümlerin değişiklik notlarını okuyun; doğrudan daha yeni bir majora geçebilmek, aradaki davranış değişikliklerini önemsiz kılmaz.

Yöntemi kesinti bütçesi ve veri hareketine göre seçin

Dump/restore, pg_upgrade ve mantıksal replikasyon farklı operasyon maliyetleri taşır. Dump/restore temiz bir yeniden kurulum sağlayabilir ancak veri büyüdükçe süre ve ek alan ihtiyacı artar. pg_upgrade veri biçimi geçişini hızlandırabilir; uyumluluk denetimleri, disk yerleşimi ve seçilen çalışma modu önemlidir. Mantıksal replikasyonla geçişte ise şema değişiklikleri, sequence değerleri ve replikasyon kapsamına girmeyen nesneler ayrıca yönetilir.

Bu yöntemlerin hiçbirine ölçüm yapmadan “kesintisiz” etiketi koymayın. İlk denemede veri hazırlama, kopyalama, indeks işlemleri, istatistikler ve uygulama kontrolü için geçen zamanı ayrı ayrı ölçün. Planlanan bakım penceresine yalnız komutun çalışma süresini değil, karar verme ve hata inceleme payını da dahil edin. Küçük bir veritabanında bile yavaş bir dış entegrasyon kabul süresini uzatabilir.

Temsil gücü olan bir prova ortamı hazırlayın

Boş veritabanında açılan uygulama, gerçek geçiş provası değildir. Test ortamı üretime yakın veri dağılımını, büyük tabloları, indeksleri ve bağlantı davranışını temsil etmelidir. Kişisel ve ticari verileri uygun biçimde maskeleyin; test ortamından müşterilere e-posta, fatura veya webhook gönderilmesini engelleyin. Gerekli test hesapları ayrı olsun, üretim sırları kontrolsüz şekilde kopyalanmasın.

Prova boyunca uygulama sürümü ve test veri kümesi sabit kalmalıdır. Aynı anda büyük uygulama değişikliği, işletim sistemi yenilemesi ve major yükseltme yapmak hatanın kaynağını belirsizleştirir. Değişiklikleri ayırmak mümkün değilse her birinin sahibi ve geri alma etkisi yazılmalıdır. Altyapı tarafındaki kapsamı DevOps hizmeti değerlendirmesinde bu bağımlılıklarla birlikte konuşmak daha sağlıklıdır.

Veri kabulü: satır sayısından iş sonucuna ilerleyin

Tablo sayısı ve satır sayısı yararlı ilk kontrollerdir, fakat tek başlarına doğruluk kanıtı değildir. Kritik tarih aralıklarındaki sipariş toplamı, müşteri bakiyesi, açık işlem sayısı ve son kayıt zamanları gibi iş ölçülerini karşılaştırın. Büyük tablolar için maliyeti yönetilebilir örnekleme ve uygulamaya uygun tutarlılık sorguları seçin. Her kontrolün hangi veri anını karşılaştırdığı açık olsun; canlı yazma devam ederken alınan iki farklı anlık sonuç doğal olarak farklı çıkabilir.

• Kritik nesneler, roller, yetkiler ve extension sürümleri beklenen durumda mı?
• Örnek sipariş, fatura ve rapor sonuçları aynı iş anlamını koruyor mu?
• Sequence değerleri yeni kayıtlarla çakışmayı önleyecek seviyede mi?
• Uygulama bağlantı havuzu doğru hedefe ve doğru kullanıcıyla bağlanıyor mu?
• Zaman dilimi, metin sıralaması ve arama sonuçları beklenen davranışta mı?

Performans kabulünü gerçek sorgularla yapın

Major geçiş sonrası sorgu planları değişebilir. En sık çalışan sorguların yanında, nadir ama kritik ay sonu raporlarını da değerlendirin. Önceki ortamdan ölçülen gecikme dağılımını, eşzamanlı bağlantı sayısını ve kaynak kullanımını referans alın. Tek sorgunun bir kez hızlı çalışması yeterli değildir; önbellek durumu ve temsil edici yük sonuçları etkiler.

Yöntemin gerektirdiği istatistik toplama ve sonraki işlemleri hedef sürüm dokümantasyonuna göre tamamlayın. Kabul eşiğini iş gereksinimi belirlesin: ödeme onayının veya müşteri ekranının tolere ettiği süre, ekipçe önceden yazılsın. Ölçülmeyen performans vaadini yükseltme başarısı diye sunmayın. Sorunlu sorguyu bulduğunuzda rastgele parametre değişiklikleri yerine plan ve veri dağılımını karşılaştırın.

Yeni yazmalar başladıktan sonra rollback aynı şey değildir

Eski cluster’ı saklamak geri dönüşün otomatik olarak güvenli olduğu anlamına gelmez. Yeni sistemde yazma başladıysa eski sistem bu değişiklikleri içermez. Doğrudan eski adrese dönmek veri kaybına, çift işleme veya tutarsız entegrasyonlara yol açabilir. Yazma kesme noktası, yeni yazmaları geri taşıma yaklaşımı ve geri dönülemeyecek karar noktası geçişten önce tanımlanmalıdır.

Özellikle pg_upgrade bağlantı/link seçeneklerinde eski ve yeni veri dosyalarının bağımsızlığına dair varsayım yapmayın; kullanılan modun sınırlarını okuyun. Ayrı ve doğrulanmış bir yedek planı bulunmalıdır. Replikasyon, HA ve failover hizmet sürekliliği bileşenleridir; yedek veya PITR’nin yerine geçmez. PITR için base backup, WAL arşivi, saklama süresi ve geri yükleme testi ayrıca tasarlanır; standart pakete dahil olduğunu varsaymayın.

Canlıya geçiş karar dosyası ve takip

Kabul dosyasında yöntem, ölçülen prova süresi, veri kontrolleri, uygulama sahibi ve go/no-go yetkilisi yer alsın. Bağlantı adresi değişikliği, worker’ların yeniden başlatılması ve zamanlanmış görevlerin hedefi sırayla doğrulansın. Trafik açıldıktan sonra hata oranını, sorgu gecikmesini ve iş sonuçlarını izleyin. Eski cluster’ı ancak saklama ve geri dönüş kararı tamamlandıktan sonra, ayrı onayla kaldırın.

• Yedekten geri yükleme kanıtı ve erişilebilir bakım kaydı hazır.
• Extension ve uygulama uyumluluk testleri ilgili sahiplerce onaylı.
• Yazma dondurma, son eşitleme ve yeni hedef kontrolü tanımlı.
• Veri ve performans kabul sonuçları aynı test kümesiyle kayıtlı.
• Geçiş sonrası izleme sorumlusu ve geri dönüş sınırı belirli.

Narweb ile geçiş kapsamını netleştirin

PostgreSQL Cluster Hosting ihtiyacınızı değerlendirirken mevcut sürümünüzü, veri boyutunu, extension listesini ve kabul edilebilir bakım penceresini paylaşın. Uygulama testleri, migration, yedekleme ve PITR kapsamı ayrıca netleştirilmelidir. Sürüm geçişi ve kabul planınızı birlikte değerlendirmek için iletişime geçin.

Resmî kaynak: PostgreSQL sürüm ve destek politikası. Yönteme özel adımlar için hedef major sürümünün resmî yükseltme belgeleri esas alınmalıdır.