PostgreSQL 14 için destek sona erdi: güncellemeyen sunucular güvenlik yamasız kaldı

PostgreSQL 14'ün destekli ömrü sona erdi. dev.to'da yayımlanan bir yazıya göre PostgreSQL Global Development Group, 14 serisi için son sürüm tarihini 12 Kasım 2026 olarak açıkladı; bu sürüm çıktıktan sonra upstream proje tüm 14.x sürümleri için güvenlik yaması ve hata düzeltmesi sağlamayı bırakıyor.

Aynı yazı, yönetilen servis kullanıcılarını sağlayıcılarının zaman çizelgesini ayrıca kontrol etmeleri konusunda uyarıyor: bakım takvimleri, desteklenen yükseltme yolları ve genişletilmiş destek koşulları servisler arasında farklılık gösteriyor ve bu tarihler hem yamalamayı hem de uyumluluk gereksinimlerini etkileyebilir.

İlk adım: her örneği bulun ve bir sahiplenici atayın

Önerilen başlangıç noktası, production, staging, QA ve olağanüstü durum kurtarma ortamlarındaki bulut veritabanı listelerini, deployment manifestlerini ve self-hosted sunucuları kapsayan bir envanter. Failover'a kadar boşta bekleyen replicalar, en çok gözden kaçma ihtimali olan örnekler olarak işaretleniyor.

Sürüm kontrolü, herhangi bir uygulama bağlantısından veya SQL istemcisinden tek bir sorguyla yapılıyor: SHOW server_version;.

dev.to yazısı, her 14 örneği için ortamın, sahibi olan ekibin ve birincil mühendislik irtibat kişisinin, bağlanan tüm uygulamaların — normal trafik saatleri dışında veritabanını sorgulayan zamanlanmış job'lar ile BI veya raporlama araçları dahil — ve kullanılabilir bakım pencerelerinin kaydedilmesini öneriyor. Sahibi belli olmayan durumlarda, herhangi bir değişiklik planlanmadan önce bağımlılıkları haritalamakla görevlendirilecek birinin atanması gerekiyor.

Yığının gerçekten destekleyebileceği bir hedef sürüm seçin

Sıradaki adım, hosting platformunuzun hangi PostgreSQL major sürümlerini desteklediğini ve her birinin ne kadar süre daha upstream düzeltme alacağını doğrulamak, ardından bağımlı olduğunuz extension, driver ve yedekleme araçlarıyla uyumluluğu teyit etmek. Verilen örnek PostGIS: gerekli extension sürümü, bakım penceresi rezerve edilmeden önce hedef platformda mevcut olmalı.

Self-hosted kurulumlarda iki ana yol var: pg_upgrade ve dump-and-restore. pg_upgrade kullanmayı planlayan herkes, aracın önceden tespit edebileceği sorunları yakalamak için prova sırasında pg_upgrade --check çalıştırmalı. Yönetilen servislerde ise sağlayıcının belgelenmiş prosedürü izlenmeli ve 14'ten seçilen sürüme doğrudan geçişin desteklenip desteklenmediği teyit edilmeli.

Prova edin ve geri dönüş tetikleyicisini cutover'dan önce belirleyin

Prova, production verisinin temsili bir kopyasıyla yapılmalı: yükseltmenin süresini ölçün, uygulamanın kritik okuma ve yazma yollarını çalıştırın ve yalnızca ara sıra tetiklenen background job'ları koşturun. Yazı, başarılı bir girişin temel bağlantıdan fazlasını kanıtlamadığına dikkat çekiyor ve izinleri ile extension'ları hâlâ elinde tuttuğunu doğrulamak için gece raporlama job'ının ayrıca çalıştırılmasını öneriyor.

Ayrıca bir yedeğin test ortamında geri yüklenmesi, kurtarma süresinin ölçülmesi ve bu sayının recovery time objective ile karşılaştırılması tavsiye ediliyor.

Cutover'dan önce verilmesi gereken iki karar var. İlki ne zaman geri dönüleceği; bu, üzerinde anlaşılmış bir eşiğin üzerindeki uygulama hata oranı veya bakım penceresini aşan bir yükseltme gibi nesnel bir tetikleyici olarak tanımlanmalı. İkincisi, cutover sonrası yazma işlemlerinin nasıl ele alınacağı: trafik, yükseltilmiş veritabanı yazma kabul ettikten sonra eski PostgreSQL 14 örneğine geri yönlendirilirse, bu transaction'lar eski örnekte bulunmayacaktır; onları uzlaştırmanın bir yolu yoksa.

Bu hafta hedefi

Somut hedef, hafta sonuna kadar kalan her PostgreSQL 14 örneğinin bir sahibinin, doğrulanacak bir hedef sürümün ve planlanmış bir prova tarihinin olması. Bugün yalnızca tek bir işlem için zaman varsa, yazıya göre birincil production bağlantınızın arkasındaki sunucu sürümünü doğrulayın ve yükseltmenin sahibinin kim olduğunu teyit edin.

Neden önemli

Güvenlik düzeltmesi almayan bir veritabanı, 14.x kod tabanındaki gelecekteki her açığı kalıcı ve yamanamayan bir risk haline getiriyor; ayrıca veritabanı genellikle bir ekibin hızla değiştirebileceği son bileşendir. Süre kendi başına sürpriz değil — projenin yayımladığı sürümleme politikasından geliyor — dolayısıyla kalan risk operasyonel: sahipsiz örnekler, hedef sürümde bulunmayan extension'lar, gerçekçi bir veri kümesiyle süresi hiç ölçülmemiş yükseltmeler ve olay ortasında doğaçlama yapılan geri dönüş kararları. dev.to yazısının çizdiği iş bilinçli olarak sıradan, çünkü alternatifi bu boşlukların her birini bir kesinti sırasında keşfetmek.