메이저 버전 업그레이드

Oracle

# Recommended: AutoUpgrade (analyze + fixups + deploy in a single flow):
$ java -jar $NEW_ORACLE_HOME/rdbms/admin/autoupgrade.jar -config db.cfg -mode deploy
# Graphical alternative: DBUA (Database Upgrade Assistant)
$ $NEW_ORACLE_HOME/bin/dbua

AutoUpgrade는 분석, 사전 수정(pre-fixups), 업그레이드, 사후 단계를 단일 명령으로 실행하며, 다운타임을 줄이기 위해 여러 데이터베이스를 순차적으로 처리할 수 있다. DBUA는 같은 작업을 안내형 인터페이스로 수행한다. 사전 전체 백업은 필수다.

PostgreSQL

# pg_upgrade to the new major version (with both clusters stopped):
$ 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   # fast migration with hard links
# Then gather statistics (analyze_new_cluster.sh was removed in PG14):
$ vacuumdb --all --analyze-in-stages

pg_upgrade는 메이저 버전 이전(16 -> 17)을 in-place로 수행한다. --link 모드는 파일을 복사하는 대신 하드 링크를 만들어 시간을 단축하지만 기존 클러스터를 사용할 수 없게 만든다. 이전 후 통계를 다시 수집해야 한다.

MySQL

# In-place upgrade (same datadir, new binaries):
$ sudo systemctl stop mysqld
$ sudo dnf install mysql-community-server-8.4   # replacing the old package
$ sudo systemctl start mysqld   # the server upgrades the dictionary automatically

MySQL 8.x부터 in-place 메이저 업그레이드를 지원한다. 새 바이너리로 시작한 서버가 데이터 딕셔너리와 시스템 테이블을 자동으로 변환한다(기존의 별도 mysql_upgrade 단계는 제거됨). 한 번에 메이저 버전 하나씩 업그레이드한다.

SQL Server

-- In-place major version upgrade (with setup):
-- setup.exe /q /ACTION=upgrade /INSTANCENAME=MSSQLSERVER
--   /IAcceptSQLServerLicenseTerms
-- Alternative: install a new instance side by side and move the databases (restore/attach).

setup /ACTION=upgrade는 인스턴스를 새 메이저 버전으로 in-place 업그레이드한다. 더 안전한 방법은 side-by-side로 설치한 뒤 backup/restore로 데이터베이스를 옮기고, 별도 단계에서 호환성 수준을 올리는 것이다.

MongoDB

// Stepwise major upgrade (e.g. 6.0 -> 7.0), one major version at a time:
// 1) Roll the binary to 7.0 on all nodes
// 2) Once the cluster is stable, raise the FCV:
db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true })

MongoDB의 메이저 업그레이드는 두 단계로 이루어진다. 먼저 모든 노드의 바이너리를 새 버전으로 rolling 교체하고, 클러스터가 안정되면 FCV를 새 버전으로 올린다. 한 번에 메이저 버전 하나씩만 올릴 수 있으며, 다운그레이드 가능성을 위해 FCV는 별도로 관리된다.

Redis

# Major upgrade via a replica (no downtime):
# 1) Create a replica on the new version, wait for full sync from the master
# 2) Prepare the application; fail over the master:
redis-cli -h <new-replica> REPLICAOF NO ONE   # make the new version the master
# 3) Upgrade the old master, attach it as a replica of the new master

Redis 메이저 버전 이전(6.x -> 7.x)은 새 버전으로 replica를 구성해 동기화한 뒤 master로 승격하는 방식으로 수행한다. 이를 통해 쓰기 다운타임을 거의 0으로 줄인다. RDB 파일은 이후 버전과 호환된다.

Elasticsearch

# Major versions cannot be skipped; one major at a time, via the last minor first (e.g. 6.8 -> 7.17 -> 8.x):
# 1) Upgrade to the last minor (7.17), resolve the GET _migration/deprecations warnings
# 2) Rolling upgrade, per node: set allocation to "primaries" -> update the node -> start -> wait for green
# Alternative: full-cluster restart (stop all nodes -> upgrade -> start together); this also moves only one major

Elasticsearch는 어떤 방법으로도 메이저 버전 건너뛰기를 지원하지 않는다. rolling upgrade와 full-cluster restart 모두 다음 메이저(n -> n+1)로만 이동하며, 소스가 마지막 마이너(예: 7.17)여야 한다. 두 메이저 이전(예: 6.x)에 생성된 인덱스는 새 버전에서 열 수 없으므로 이전 전에 _reindex로 재구축해야 한다(8.x는 이를 read-only archive index로 제한적으로만 읽을 수 있음). 이전 전에 스냅샷을 생성하고 deprecation 경고를 해결한다.

DBAtlas에서 열기 →