PostgreSQL 14 Desteğinin Sona Ermesine İki Ay: Yükseltmeden Önce Kurtarma Pratiği Yapmak
Veritabanı sürümünü yükseltme takvimini belirlemiş ancak işlem başarısız olduğunda geri dönüşün ne kadar süreceğini bilmeyen ekipler var. PostgreSQL 14 çalıştırıyorsanız şu anda ihtiyacınız olan çıktı, yalnızca yeni bir sürüm adı değil, geri dönüşü mümkün olan bir geçiş planıdır. 14 Eylül 2026 itibarıyla resmi destek bitiş tarihine yaklaşık iki ay kaldı.
Doğrulanmış Gerçek: Topluluk Desteği ile Barındırma Sözleşmeleri Farklıdır
PostgreSQL'in resmi sürüm politikası ana sürümleri 5 yıl boyunca destekler ve 14 sürümünün son çıkış tarihini 12 Kasım 2026 olarak belirtir. Bu, topluluk destek takvimidir. Yönetilen hizmetlerin yükseltme pencereleri, ayrı uzatılmış destek seçenekleri ve ücretleri, ilgili sağlayıcının belgelerinde ve sözleşmelerinde ayrıca doğrulanmalıdır.
Aynı ana sürümün alt güncellemeleri ile ana sürüm yükseltmelerini de birbirinden ayırt etmek gerekir. 14'ün en son düzeltme sürümünü uygulamak, 15 veya üzerine geçmenin yerini tutmaz. Buna karşın, bir ana sürüm geçiş planı olduğu gerekçesiyle mevcut sürüm için gerekli düzeltmeleri uygulamayı sürekli ertelemek de doğru değildir.
İlk Çıktı: Veri Boyutundan Ziyade Bağımlılık Listesi
Buradan sonrası resmi destek politikasının kendisi değil, pratik operasyonel önerilerdir. Öncelikle hizmet bazında veritabanı sürümlerini, eklenti modüllerini ve sürümlerini, bağlantı sürücülerini, toplu (batch) işleri, yedekleme saklama konumlarını ve çoğaltma (replikasyon) yapılandırmalarını tek bir sayfada listeleyin. Hedef sürümü yalnızca en yenisi olduğu için seçmeyin; fiili barındırma ortamının ve eklenti modüllerinin destek kapsamını da kontrol edin.
Veritabanının küçük olmasından dolayı sürecin hızlı ilerleyeceği varsayımı yeterli değildir. Oturum açma sonrası ilk sorgulama veya ödeme durumu güncellemesi gibi iş açısından kritik yollarda kullanılan eklentiler ya da sorgular değişirse, veri kopyalama süresi kısa olsa bile geçiş başarısız olabilir. Bu listenin amacı, sorumlusu bulunmayan bağımlılıkları tespit etmektir.
İkinci Çıktı: Yedekleme Başarı Mesajı Yerine Geri Yükleme Sonucu
İzole bir ortamda en son yedeği geri yükleyin ve uygulamanın tipik okuma ve yazma akışlarını çalıştırın. Bu alıştırmada, canlı veritabanına yazma işlemi gönderilmesini önlemek için bağlantı hedefini önceden doğrulamalısınız. Gerçek verileri içeren geri yükleme kopyası, mevcut erişim denetimi sınırları dahilinde ele alınmalıdır.
Yedekleme başlangıç zamanını, geri yükleme tamamlanma zamanını ve doğrulama tamamlanma zamanını ayrı ayrı kaydetmek, dosyaları getirme süresi ile hizmetin yeniden yazmaya hazır hale gelme süresinin birbirine karıştırılmasını önler. Yapay olarak hızlı çalışan küçük bir örnekle yetinmek yerine, canlı veritabanı boyutuna yakın bir geri yükleme kopyasıyla süreyi ölçün; maliyet ve depolama alanı kısıtlamalarını da kaydedin.
pg_upgrade Denetiminden Geçmek, Hizmet Doğrulamasının Yerini Tutmaz
Resmi pg_upgrade belgeleri, --check seçeneğiyle fiili yükseltmeden önce uyumluluk denetimi yapılabileceğini açıklar. Harici modüllerin uyumluluğu ayrıca incelenmeli ve yeni sunucuya uygun paylaşılan kütüphaneler de sağlanmalıdır. Yalnızca denetim komutunun başarılı olmasıyla uygulama sorgularının ve performansın tamamen doğrulandığı sonucuna varmayın.
Özellikle --link yöntemi, yeni küme başlatıldıktan sonra eski kümenin artık olduğu gibi kullanılamaması kısıtlamasına sahiptir. Yalnızca hızına bakarak bir yöntem seçmek, planlanan geri dönüş yolunu ortadan kaldırabilir. Fiili geçiş yöntemiyle aynı koşullar altında prova yapmalı ve geri yüklemeye dayalı bir geri dönüşün hangi noktada gerekli olacağını açıkça belirlemelisiniz.
Yazma İşlemlerine Yeniden Başlamadan Önce Belirlenecek Kriterler
Geçiş günü anlık olarak uzlaşmaya çalışmamak için başarı kriterlerini önceden yazılı hale getirin. Örneğin, kritik API'lerin okuma ve yazma işlemlerini tamamlaması, toplu işlerin mükerrer işlem olmadan yeniden başlatılması, ana tablolardaki iş mutabakatlarının uyuşması ve çoğaltma durumunun doğrulanması gibi maddeleri ilgili sorumlularla eşleştirebilirsiniz. Bu, her hizmete aynı eşik değerlerini dayatan bir örnek değildir.
Yeni veritabanında yazma işlemleri başladıktan sonra önceki yedeğe geri dönülürse, arada gerçekleşen değişikliklerin nasıl korunacağı da sorun haline gelir. Eski sunucuyu açma prosedürü ile veri kaybı olmadan geri dönme prosedürü aynı şey olarak görülmemelidir. Kabul edilebilir kayıp ve kesinti sınırları, hizmetten sorumlu kişilerce kararlaştırılmalıdır.
Bu Hafta Yapılacaklar ve İtirazlar
Tüm veritabanlarını tek seferde taşımak zorsa, en az bağımlılığı olan tek bir hizmetle geri yükleme, doğrulama ve geri dönüş sürelerini ölçün ve elde edilen sonuçları diğer hizmetlerin planlamasında girdi olarak kullanın. Sorumluları, olası geçiş tarihlerini ve doğrulama başarısızlığında durdurma kriterlerini tek bir belgede toplamak, projeyi yalnızca takvimden ibaret olmaktan çıkarıp uygulanabilir bir göreve dönüştürür.
Şu anda ürün geliştirmenin daha acil olduğu yönündeki itirazlar anlaşılabilir. Ancak son tarihe kadar kurtarma yöntemini bilmeden beklemek, kullanılabilecek inceleme süresini daraltır. Bu makale belirli bir sürümün performans artışını savunmaz veya tüm topluluğun görüşünü temsil etmez. En son özellikleri benimseme hızından ziyade, geçiş başarısızlıklarını yönetmeye hazır olmaya odaklanan operasyonel bir öneridir.