PostgreSQL 14 desteği bitiyor: yükseltme yolu

PostgreSQL 14 için son yayın 12 Kasım 2026'da çıkacak; ardından sürüm desteği biter ve hata ya da güvenlik düzeltmesi gelmez. PostgreSQL sürüm politikası her ana sürümü ilk yayından 5 yıl destekler ve sonunda son bir küçük sürüm çıkarır. Bugün 14'in güncel küçük sürümü 14.24; hedef olarak 18 (18.6) seçmek, 2030'a kadar destek demektir.

Küçük sürüm güncellemesi bu işi çözmez

14.24'ten sonraki küçük sürüme geçmek için dump ve restore gerekmez: sunucuyu durdurur, yeni ikili dosyaları kurar, yeniden başlatırsınız. Politika sayfası bunu açıkça yazar. Ancak 12 Kasım'dan sonra yeni küçük sürüm gelmez; asıl iş ana sürüm yükseltmesidir ve bu, veri dizininin biçimi değiştiği için ayrı bir yöntem ister.

Desteklenen sürümlerin son yayın tarihleri (sürüm politikası tablosundan):

Bir yükseltmeyi her yıl tekrar etmek istemiyorsanız 15 ve 16 iyi hedef değildir: biri bir yıl, diğeri iki yıl sonra aynı sorunu geri getirir. 17 ile 18 arasındaki fark bir yıllık destektir; ayrıca 18'e özgü iki özellik (aşağıda) yükseltmeyi hızlandırır.

Kesinti penceresine göre yöntem seçimi

Tablodaki "kısa/uzun" ifadeleri göreli; belgeler süre ya da disk için sayı vermez, bu yüzden kendi verinizle bir deneme koşusu yapmadan sayı varsaymayın. Karar şöyle çıkar:

• Kesinti penceresi veriyi kopyalamaya yetiyorsa ve dönüş garantisi istiyorsanız --copy.
• Pencere dar, yedeğiniz sağlam ve eski kümeyi yeni küme açıldıktan sonra kullanmayacaksanız --link.
• Dosya sisteminiz reflink destekliyorsa, hız ile "eski küme bozulmasın" isteğini birlikte --clone karşılar.
• Pencere neredeyse yoksa ve kaynak sunucunuz 14'se mantıksal replikasyon (sınırları aşağıda).

14'ten 18'e: değişen varsayılanlar

18 sürüm notları, doğrudan 14'ten gelen bir kümeyi etkileyen birkaç değişiklik içerir (PostgreSQL 18 sürüm notları):

• initdb artık varsayılan olarak veri sayfası sağlama toplamlarını (checksum) açar ve pg_upgrade iki kümenin ayarının aynı olmasını ister. Eski kümeniz sağlama toplamsızsa yeni kümeyi initdb --no-data-checksums ile kurun.
• pg_upgrade en iyileştirici istatistiklerini artık taşır; genişletilmiş istatistikler (CREATE STATISTICS) taşınmaz.
• Kümeniz libc dışı bir varsayılan harmanlama sağlayıcısı (ICU, builtin) kullanacaksa, sürüm notları yükseltmeden sonra tam metin aramayla ilgili indekslerin ve pg_trgm indekslerinin yeniden oluşturulmasını önerir.
• Birincil/yabancı anahtar ilişkilerinde belirleyici (deterministic) olmayan harmanlama kullanıyorsanız ve iki taraf aynı harmanlamayı kullanmıyorsa dump/restore ve pg_upgrade başarısız olur; şemada önceden düzeltme gerekir.
• MD5 parola doğrulaması kullanımdan kaldırıldı ve gelecekteki bir ana sürümde kaldırılacak; bu yükseltmede SCRAM geçişini de planlayın.

pg_upgrade adım adım (14'ten 18'e)

Aşağıdaki yollar, ikili dosyaları /usr/local/pgsql/<sürüm>/bin altında, veri dizinleri (yapılandırma dosyalarıyla birlikte) /srv/pgdata/<sürüm> altında olan genel bir kuruluma göredir; kendi yollarınızı yazın. Tüm komutları veritabanı kullanıcısıyla (postgres) çalıştırın. pg_upgrade bu ortam değişkenlerini kendisi okur.

export PGBINOLD=/usr/local/pgsql/14/bin
export PGBINNEW=/usr/local/pgsql/18/bin
export PGDATAOLD=/srv/pgdata/14
export PGDATANEW=/srv/pgdata/18
export PGPORTOLD=5432
export PGPORTNEW=5433

Debian ve Ubuntu'da paket yöneticisinin kendi aracı var: postgresql-common ile gelen pg_upgradecluster, --method=upgrade, link ya da clone ile pg_upgrade'i sizin yerinize çalıştırır (kılavuz). Yöntem verilmezse varsayılan dump'tır.

Adım 1. Eski kümenin sağlama toplamı durumuna bakın, yeni kümeyi ona göre kurun:

"$PGBINOLD/pg_controldata" "$PGDATAOLD" | grep -i checksum
# "Data page checksum version: 0" ise kapalıdır; o zaman:
"$PGBINNEW/initdb" -D "$PGDATANEW" --no-data-checksums
# Sürüm 1 ise --no-data-checksums eklemeden "$PGBINNEW/initdb" -D "$PGDATANEW" çalıştırın

Adım 2. Yeni sürüme, eski kümede kullanılan her uzantının .so dosyalarını işletim sistemi paketiyle kurun (ör. pgcrypto). CREATE EXTENSION komutunu yeni kümede çalıştırmayın; belge bunun eski kümeden zaten çoğaltılacağını söyler. Özel tam metin arama dosyalarını da yeni kümeye kopyalayın.

Adım 3. Önce yalnızca denetimi çalıştırın; belgeye göre --check eski sunucu çalışırken de koşabilir. --link/--clone/--swap kullanacaksanız aynı seçeneği --check ile de vermeniz gerekir (moda özel denetimler için):

"$PGBINNEW/pg_upgrade" --check --link --jobs=4

Adım 4. Denetim temizse eski sunucuyu durdurup yükseltmeyi çalıştırın. --jobs, birden çok veritabanı ve tablespace içeren sunucularda süreyi belirgin kısaltır; belge başlangıç değeri olarak makinedeki CPU çekirdeği sayısını önerir:

"$PGBINNEW/pg_upgrade" --link --jobs=4

Adım 5. pg_hba.conf ayarlarınızı yeni kümeye geri yükleyin, yeni sunucuyu başlatın, pg_upgrade'in çıktısında anılan eklenti güncelleme betiğini psql ile çalıştırın.

Adım 6. İstatistikleri tamamlayın. 18 hedefinde belgedeki sıra şudur: --missing-stats-only yalnız eksik istatistiği hesaplar ve --analyze-in-stages ile birlikte eski istatistiğin geçici olarak daha düşük kaliteli olanla değişmesini önler. vacuumdb PGPORTNEW değişkenini okumaz; yeni kümenin portunu -p ile verin (yoksa PGPORT ya da varsayılan porttaki sunucuya bağlanır). --missing-stats-only yalnız süper kullanıcıyla çalışır, bu yüzden postgres ile koşun:

"$PGBINNEW/vacuumdb" -p "$PGPORTNEW" --all --analyze-in-stages --missing-stats-only
"$PGBINNEW/vacuumdb" -p "$PGPORTNEW" --all --analyze-only

Adım 7. Uygulama testleri geçtikten sonra pg_upgrade'in yazdığı delete_old_cluster.sh ile eski veri dizinini silin. Eski veri dizininin içinde kullanıcı tablespace'i varsa betik otomatik silemez.

--link için iki kural: eski ve yeni veri dizinleri aynı dosya sisteminde olmalıdır (tablespace'ler ve pg_wal hariç) ve yeni küme bir kez açıldıktan sonra eski küme asla açılmamalıdır; ikisi aynı dosyaları paylaşır. 17 ya da daha eski bir hedefe gidiyorsanız bu yazıdaki 18 özellikleri (--swap, --missing-stats-only, istatistik taşıma) yoktur; istatistik için düz vacuumdb --all --analyze-in-stages kullanılır.

Geri dönüş matrisi: hangi modda eski kümeye ne zaman dönülür

pg_upgrade belgesinin geri dönüş bölümü şunu söyler:

--swap için ayrıntı: pg_upgrade "eski küme artık başlatmak için güvenli değil" diye bildirmeden önce durursa eski küme değişmemiştir; bildirdikten sonra yedekten dönmek gerekir. Belge ayrıca --swap ile --sync-method=fsync kullanılmasını önerir, çünkü bu mod eski kümede çok sayıda artık dosya bırakır ve syncfs bunları da eşitlemeye çalışarak adımı uzatır.

Pratik sonuç: --link ya da --swap seçtiyseniz yükseltmeden önceki tam yedeği geri yüklemeyi bir kez denemiş olmalısınız. Geri dönüş yolunuz o yedektir.

Mantıksal replikasyonla 14'ten yükseltmenin sınırı

Mantıksal replikasyon farklı ana sürümler arasında çalışır (belgenin kullanım senaryolarından biridir), ama 14 kaynaklı iş üç sınıra çarpar:

• Şema ve DDL replike edilmez: ilk şemayı pg_dump --schema-only ile yeni kümeye siz taşırsınız, sonraki değişiklikleri elle eşitlersiniz (kısıtlar sayfası).
• Sıra (sequence) verisi ve büyük nesneler (large object) replike edilmez. Sıralar için geçişte tablolardaki değerlerden yeterince yüksek bir başlangıç değeri hesaplayıp elle ayarlamak gerekir; büyük nesnelerin geçici çözümü yoktur.
• pg_upgrade ile mantıksal replikasyon topolojisini taşımak, belgeye göre tüm üyeler 17.0 ya da sonrası olduğunda desteklenir. Belge, 17.0'dan eski kümelerdeki mantıksal slotların ve abonelik bağımlılıklarının taşınmadığını, sessizce yok sayıldığını söyler (sizin durumunuz); pg_upgrade belgesi de eski birincil 17.0'dan eskiyse slotların yeni bekleme sunucusuna kopyalanmadığını, elle yeniden oluşturulması gerektiğini yazar. 17.0+ kaynaklarda mantıksal slotlar taşınır.

Yani 14 kümesi zaten mantıksal replikasyon topolojisinin üyesiyse, o topolojiyi pg_upgrade ile slotlarıyla birlikte taşıma yolu 14 kaynaklı olarak belgede yok; slotları ve abonelikleri yükseltmeden sonra elle yeniden kurarsınız. 17+ üyeli bir topolojide ise abonelikler ALTER SUBSCRIPTION ... DISABLE ile kapatılır, yükseltmeden sonra ENABLE ve REFRESH PUBLICATION çalıştırılır.

Yükseltmeyi durduran hatalar

Başlamadan önce kontrol listesi

• Hedef sürüm 17 mi 18 mi, bilinçli seçildi; 15/16 elendi (destekleri 2027 ve 2028'de biter).
• Eski kümenin sağlama toplamı durumu bilinir; initdb buna göre çalıştı.
• Her uzantının 18 için paketi kurulu; uzantı sürümleri kayıt altında.
• --check seçilen modla (--link, --clone ya da --swap) temiz geçti.
• Yükseltme öncesi tam yedek alındı ve geri yüklenebildiği denendi.
• Kesinti penceresi için deneme koşusu yapıldı; pencere sayısı belgeden değil, kendi veri boyutunuzdan çıkar.
• --link ya da --swap seçildiyse "yeni küme açıldıktan sonra eski küme açılmaz" ekipçe kabul edildi.
• Replikasyon ve bekleme sunucuları için ayrı bir adım planı var (bekleme sunucusu yükseltmesi pg_upgrade belgesinde ayrı adımdır).
• vacuumdb istatistik adımı zamanlandı; libc dışı harmanlama sağlayıcısı kullanıyorsanız tam metin arama/pg_trgm indeks yeniden oluşturma da.
• Uygulama tarafında sorgu planı karşılaştırması için yükseltmeden önceki yavaş sorgu listesi saklandı.

Yükseltme sonrası sorgu planlarını gerçek iş yükü üzerinde incelemeniz gerekirse PostgreSQL danışmanlık sayfası, sorgu planı, indeksleme, bakım ve yedekleme kararlarını inceleyen teknik değerlendirmeyi anlatır. Başka bir veritabanı ürününe taşıyorsanız bu yazı kapsam dışıdır; kavram için veritabanı migration rehberine bakın.