18.5 마이너 업그레이드와 패치 적용
PostgreSQL 마이너 버전(17.10·18.1 등)은 3개월마다 출시. 버그·보안 패치만 포함되고 PGDATA 호환 — restart만 필요합니다. 운영자가 정기적으로 따르는 마이너 업그레이드·보안 패치 절차를 정리합니다.
마이너 vs 메이저
| 측면 | 마이너 (17.5 → 17.10) | 메이저 (17 → 18) |
|---|---|---|
| PGDATA 호환 | ✓ — 그대로 사용 | ✗ — 마이그레이션 필요 |
| 다운타임 | restart (수 초~수 분) | 메이저 업그레이드 절차 |
| 빈도 | 분기 | 연 |
| 내용 | 버그·보안 패치 | 새 기능 + 패치 |
| pg_upgrade 필요 | X | O |
기본 절차
flowchart TD
S0["보안 advisory 확인"]
S1["staging에서 업그레이드 검증"]
S2["백업 확인"]
S3["application 점검 시간 잡기"]
S4["dnf/apt update"]
S5["systemctl restart postgresql"]
S6["SELECT version() 확인"]
S7["application healthcheck"]
S8["모니터링 24~48시간"]
S0 --> S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> S8
classDef step fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
class S0,S1,S2,S3,S4,S5,S6,S7,S8 step
OS 패키지 업그레이드
# RHEL/Rocky
sudo dnf check-update postgresql17-server
sudo dnf update postgresql17-server postgresql17 postgresql17-contrib
sudo systemctl restart postgresql-17
# Debian/Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade postgresql-17
sudo systemctl restart postgresql@17-main확장 호환성
마이너 업그레이드에서도 일부 확장은 같이 업그레이드:
# 확장 패키지
sudo dnf update pg_partman_17 pg_repack_17 pgvector_17-- 확장 활성 버전 확인
SELECT extname, extversion FROM pg_extension;
-- 새 버전 적용
ALTER EXTENSION pgvector UPDATE;staging 검증 — 필수
1. staging 환경에 동일한 OS 패키지 업그레이드
2. application·테스트 실행 — regression 없는지
3. 모니터링·성능 비교
4. 24~48시간 관찰운영 직접 적용 전에 staging 통과가 표준입니다.
백업 확인
# 백업이 최근 + 검증된 상태
pgbackrest --stanza=main info업그레이드 전 마지막 백업 시점 확인합니다. 사고 시 그 시점부터 PITR.
restart 시간 최소화
# fast shutdown
sudo systemctl restart postgresql-17fast shutdown(10.2) → 빠른 종료 → 새 binary로 기동. 보통 수 초~수십 초. 대용량 dirty buffer 많으면 더 길 수도.
체크포인트 직후 restart:
CHECKPOINT;
-- 그 후 restart — dirty page 적어 빠름HA를 활용한 무중단
Multi-AZ·standby가 있으면:
1. standby 먼저 업그레이드
2. standby 부팅 후 검증
3. failover — 옛 primary → 새 standby가 primary
4. 옛 primary도 업그레이드
5. 트래픽 정상화다운타임 failover 시간(1~2분)만. 매니지드 클라우드 Multi-AZ의 Apply Immediately가 자동 동작합니다.
매니지드 클라우드의 마이너 업그레이드
| 클라우드 | 동작 |
|---|---|
| AWS RDS | maintenance window 자동 또는 --apply-immediately |
| Aurora | 같음 — failover 동반 |
| Azure | maintenance window |
| Cloud SQL | maintenance window |
매니지드는 자동 패치 기본 활성화합니다. 옵션:
| 옵션 | 메모 |
|---|---|
| Auto Minor Version Upgrade | 매니지드가 자동 적용 |
| Maintenance Window | 시간대 명시 |
| Apply Immediately | 콘솔에서 즉시 |
자동 패치를 켜 두면 수동 작업 없이 보안 패치 적용합니다.
보안 advisory 추적
| 채널 | 메모 |
|---|---|
| postgresql.org/support/security | 공식 |
| announce@lists.postgresql.org | 메일링 리스트 |
| pgsql-announce | RSS |
| 클라우드 보안 advisory | RDS·Azure·GCP |
CVE 확인 + 영향 평가 + 패치 일정.
예: CVE-2024-XXXXX
- 영향: PG 17.0 ~ 17.5
- 대응: 17.6 이상으로 업그레이드
- 우선순위: HIGH (RCE 가능)운영 권장:
- HIGH/CRITICAL: 1주 안 적용
- MEDIUM: 1개월 안
- LOW: 다음 정기 패치 사이클
자동화 — Ansible / Terraform
# Ansible playbook
- name: Update PostgreSQL
hosts: pg_servers
tasks:
- name: Update postgresql packages
dnf:
name: postgresql17-server
state: latest
- name: Restart postgresql
systemd:
name: postgresql-17
state: restarted서버 수가 많으면 Ansible·Salt 같은 도구로 일괄. staging → production 단계 자동화합니다.
운영 시 함정
| 함정 | 영향 |
|---|---|
dnf update 후 restart 안 함 | 옛 binary가 그대로 동작 — 패치 미적용 |
| 모든 노드 동시 재시작 | 다운타임 |
| extension 같이 업데이트 안 함 | 호환성 사고 |
| staging 건너뜀 | regression 발생 시 운영 사고 |
| 백업 없이 업그레이드 | 사고 시 복구 어려움 |
점검 명령
# 현재 동작 중인 PostgreSQL 버전 + 시작 시간
psql -c "SELECT version(), pg_postmaster_start_time();"
# OS 패키지 버전
rpm -q postgresql17-server # RHEL
dpkg -l postgresql-17 # Debian
# 두 값이 일치해야 — 안 그러면 restart 안 한 것사고 시
마이너 업그레이드는 보통 안전하지만 드물게:
- 새 버전이 regression bug 가짐
- 특정 plan·extension에 영향
대응:
- 옛 패키지 버전로 다운그레이드:
# RHEL
sudo dnf downgrade postgresql17-server postgresql17
sudo systemctl restart postgresql-17- PGDATA가 새 minor 버전과 완전 호환이므로 다운그레이드도 안전 (메이저는 X)
정기 패치 cycle
분기 정기 패치:
- 첫째 주: staging 적용 + 검증
- 둘째 주: 비핵심 production
- 셋째 주: 핵심 production
- 넷째 주: 관찰·문서화회사 정책에 따라 긴급 보안 패치는 cycle 외 즉시.
정리
- 마이너 업그레이드 = OS 패키지 update + restart. PGDATA 호환
- staging 검증 → 백업 확인 → 점검 시간 → 패키지 update → restart → 검증
- HA·standby로 다운타임 최소화
- 매니지드 클라우드는 maintenance window·auto upgrade로 자동
- 분기마다 정기, HIGH/CRITICAL CVE는 1주 안
- 다운그레이드 가능 (마이너만) — 사고 시 대응
Part XVIII 마이그레이션·업그레이드가 끝났습니다. 본 PostgreSQL 노트의 모든 챕터 — Part I부터 XVIII까지 — 완결.
이후 운영 경험·신규 기능·실전 사고 사례는 별도 글로 보강하며 누적해 나갑니다.