Büyük sürüm yükseltmesi (major upgrade)

Oracle

# Önerilen: AutoUpgrade (analiz + fixups + deploy tek akışta):
$ java -jar $NEW_ORACLE_HOME/rdbms/admin/autoupgrade.jar -config db.cfg -mode deploy
# Grafik alternatif: DBUA (Database Upgrade Assistant)
$ $NEW_ORACLE_HOME/bin/dbua

AutoUpgrade tek komutla analiz, ön düzeltmeler (fixups), yükseltme ve son adımları çalıştırır; kesintiyi kısaltmak için birden çok veritabanını sırayla işleyebilir. DBUA aynı işi rehberli arayüzle yapar. Öncesinde tam yedek şarttır.

PostgreSQL

# Yeni ana sürüm için pg_upgrade (her iki küme de kapalıyken):
$ pg_upgrade \
    --old-datadir=/var/lib/pgsql/16/data \
    --new-datadir=/var/lib/pgsql/17/data \
    --old-bindir=/usr/pgsql-16/bin \
    --new-bindir=/usr/pgsql-17/bin \
    --link   # sabit bağlantı ile hızlı geçiş
# Sonra istatistikleri topla (analyze_new_cluster.sh PG14'te kaldırıldı):
$ vacuumdb --all --analyze-in-stages

pg_upgrade ana sürüm geçişini (16 -> 17) yerinde yapar; --link kipi dosyaları kopyalamak yerine sabit bağlantı kurarak süreyi kısaltır ama eski kümeyi geçersiz kılar. Geçiş sonrası istatistikler yeniden toplanmalıdır.

MySQL

# In-place yükseltme (aynı datadir, yeni ikililer):
$ sudo systemctl stop mysqld
$ sudo dnf install mysql-community-server-8.4   # eski paketin yerine
$ sudo systemctl start mysqld   # sunucu sözlüğü otomatik yükseltir

MySQL 8.x'ten itibaren in-place major yükseltme desteklenir: yeni ikililerle başlatılan sunucu veri sözlüğünü ve sistem tablolarını otomatik dönüştürür (eski ayrı mysql_upgrade adımı kaldırılmıştır). Yalnız bir büyük sürüm atlanarak yükseltilmelidir.

SQL Server

-- Yerinde büyük sürüm yükseltmesi (setup ile):
-- setup.exe /q /ACTION=upgrade /INSTANCENAME=MSSQLSERVER
--   /IAcceptSQLServerLicenseTerms
-- Alternatif: yeni örneğe yan yana kurup veritabanlarını taşımak (restore/attach).

setup /ACTION=upgrade örneği yeni büyük sürüme yerinde yükseltir. Daha güvenli yöntem yan yana (side-by-side) kurulumdan sonra veritabanlarını backup/restore ile taşımak ve uyumluluk seviyesini ayrı bir adımda yükseltmektir.

MongoDB

// Adımlı major yükseltme (örn. 6.0 -> 7.0), tek büyük sürüm atlayarak:
// 1) Rolling ile tüm düğümlerde ikiliyi 7.0 yap
// 2) Küme kararlıyken FCV'yi yükselt:
db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true })

MongoDB'de büyük yükseltme iki aşamalıdır: önce tüm düğümlerin ikilisi rolling ile yeni sürüme alınır, küme kararlı olduğunda FCV yeni sürüme yükseltilir. Bir seferde yalnız bir büyük sürüm atlanabilir; FCV geriye alınabilirlik için ayrı yönetilir.

Redis

# Replika ile major yükseltme (kesintisiz):
# 1) Yeni sürümde bir replika oluştur, master'dan tam senkron olmasını bekle
# 2) Uygulamayı hazırla; master'ı devret:
redis-cli -h <yeni-replica> REPLICAOF NO ONE   # yeni sürümü master yap
# 3) Eski master'ı yükselt, yeni master'a replika olarak bağla

Redis büyük sürüm geçişi (6.x -> 7.x) yeni sürümlü bir replika kurup senkron ettikten sonra o replikayı master'a terfi ederek yapılır; böylece yazma kesintisi neredeyse sıfırlanır. RDB dosyaları ileri sürümlerle uyumludur.

Elasticsearch

# Major sürümler atlanamaz; her seferinde bir major ve önce son minor üzerinden (örn. 6.8 -> 7.17 -> 8.x):
# 1) Son minor sürüme (7.17) yükselt, GET _migration/deprecations uyarılarını gider
# 2) Rolling upgrade, düğüm başına: allocation'ı "primaries" yap -> düğümü güncelle -> başlat -> green bekle
# Alternatif: full-cluster restart (tüm düğümleri durdur -> yükselt -> birlikte başlat); bu da yalnız bir major atlar

Elasticsearch major sürüm atlamayı hiçbir yöntemle desteklemez: rolling upgrade de full-cluster restart da yalnızca bir sonraki major'a (n -> n+1) geçirir ve kaynak sürümün son minor'ı (ör. 7.17) olmasını ister. İki major önce (ör. 6.x'te) oluşturulmuş index'ler yeni sürümde açılamaz; geçişten önce _reindex ile yeniden oluşturulmalıdır (8.x bunları yalnızca salt okunur arşiv index'i olarak sınırlı biçimde okuyabilir). Geçiş öncesi snapshot alınmalı ve deprecation uyarıları giderilmelidir.