검토할 확장 기능 및 논리적 복제 개체

업그레이드 전에 다음 사항을 확인하십시오:

pg_repack

업그레이드 전에 pg_repack 디렉터리를 삭제하고, 업그레이드 후에 다시 생성하십시오. pg_repack 는 버전별 확장자를 사용하며, 클라이언트/서버 구성 요소는 PostgreSQL의 주요 버전과 일치해야 합니다.

DROP EXTENSION pg_repack;

업그레이드 후에도 해당 확장 기능이 여전히 필요한 경우에만 이를 다시 생성하십시오.

CREATE EXTENSION pg_repack;

old_snapshot

업그레이드 전에 old_snapshot 를 삭제하십시오. PostgreSQL 18로 업그레이드한 후에는 더 이상 지원되지 않으므로 이 설정을 다시 생성하지 마십시오.

DROP EXTENSION old_snapshot;

wal2json 복제 슬롯

wal2json 를 논리적 디코딩에 사용하는 경우, 업그레이드 전에 관련 복제 슬롯을 모두 삭제해야 합니다. pg_upgrade 유틸리티는 복제 슬롯이 존재하는 동안 주요 버전 업그레이드를 엄격히 금지하며, 이 경우 치명적인 오류를 발생시키고 업그레이드를 중단합니다.

업그레이드 전:

1. 보류 중인 모든 WAL 데이터가 처리되었는지 확인하십시오.
2. 복제 슬롯을 사용하는 애플리케이션을 중지하십시오.
3. 복제 슬롯을 삭제합니다:

SELECT pg_drop_replication_slot('your_slot_name');

업그레이드 후에는 필요에 따라 복제 슬롯을 다시 생성할 수 있습니다. wal2json 는 CREATE EXTENSION 를 통해 설치되는 것이 아니라, 데이터베이스 매개변수(wal_level, max_replication_slots, max_wal_senders) 및 테이블 권한을 통해 구성되며, 이러한 설정은 업그레이드를 방해하지 않습니다.

anon

업그레이드 전에 ‘ anon ’ 확장 프로그램을 제거하고, 업그레이드 후에도 계속 필요하면 다시 활성화하세요. anon 을 삭제하기 전에 몇 가지 추가 절차가 필요합니다.

anon 확장 프로그램이 설치되어 있는 경우, 업그레이드를 수행하기 전에 아래 단계를 완료하고 관리자 권한으로 명령어를 실행하십시오.

1. 모든 마스킹 규칙을 제거합니다(활성화된 경우).

   SELECT anon.remove_masks_for_all_columns();
   

2. 마스킹 역할을 비활성화합니다(역할이 마스킹된 것으로 표시된 경우 업그레이드가 실패할 수 있습니다).

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. anon 확장자를 캐스케이드 옵션과 함께 삭제합니다.

   DROP EXTENSION anon CASCADE;
   

4. 인스턴스 내의 여러 데이터베이스에 ‘ anon ’ 확장 프로그램이 설치된 경우, 각 데이터베이스에 대해 설명된 단계를 모두 수행하십시오.

5. 업그레이드가 완료되면 anon 확장자를 다시 활성화하고 필요에 따라 마스킹 규칙을 다시 적용합니다.

업그레이드를 수행하기 전에 마스킹 일관성을 보장하기 위해 확장 프로그램 삭제 전후에 데이터의 유효성을 검사하는 것이 좋습니다.

PostGIS

PostGIS, 를 사용 중이라면, PostgreSQL 를 업그레이드하기 전에 먼저 PostGIS 를 업그레이드하십시오.

SELECT postgis_extensions_upgrade();

다음 쿼리를 사용하여 PostGIS 확장 프로그램 업그레이드의 유효성을 검사합니다.

SELECT postgis_full_version();

Logical replication slots

업그레이드 전에 모든 논리적 복제 슬롯을 삭제하고, 업그레이드 후에 다시 생성하십시오. 논리적 슬롯은 소스 서버의 상태와 연동되어 있으므로, 업그레이드된 인스턴스에서 완전히 새로 생성해야 합니다.

SELECT pg_drop_replication_slot('<slot_name>');

시작하기 전에

업그레이드 절차를 시작하기 전에 다음 사항들을 고려하십시오.

• UI, API, CLI 또는 Terraform을 사용하여 배포 기능 정보를 확인함으로써, 현재 배포 중인 버전에 대한 버전 업그레이드가 가능한지 확인하십시오.

  예시: CLI를 사용하여 버전 업그레이드 정보 조회하기:

  ibmcloud cdb capability-show versions postgresql
  

• IPU를 실행하기 전에 이 항목에 설명된 사전 확인 관련 요구 사항을 반드시 검토하시기 바랍니다. IPU는 소스 배포 환경에서 직접 실행되며, 새로운 인스턴스를 생성하지 않습니다. 고객의 안전을 위해, 이 서비스는 업그레이드 시작 전에 사전 점검을 수행하며, 위험이 감지될 경우 해당 작업을 차단합니다. 특히 다음 항목을 확인하십시오:

  • 배포 구성원 수는 최대 3명입니다.
  • 배포 상태가 정상입니다.
  • 배포 환경에는 사용 가능한 디스크 공간이 최소 10% 이상 남아 있습니다. IPU 사전 검사의 기본 최대 허용 디스크 사용량은 90%입니다.
  • 현재 배포 환경은 I/O 부하가 심하지 않습니다. IPU 사전 검사의 기본 최대 허용 I/O 사용률은 90%입니다.
  • 스키마 크기와 객체 수는 기본 사전 검사 기준치 이내입니다. 기본적으로 개별 스키마의 크기는 100GB를 초과할 수 없으며, 인덱스와 시퀀스의 총 개수는 50,000개 미만이어야 합니다.
  • 업그레이드 전에 필요한 모든 확장 및 논리적 복제 슬롯 정리를 완료했습니다.

• 각 주요 버전에는 이전 버전과 하위 호환되지 않을 수 있는 일부 기능이 포함되어 있습니다. 데이터베이스 공급업체의 릴리스 노트를 확인하여 애플리케이션에 영향을 미칠 수 있는 변경 사항이 있는지 확인하십시오.

• 배포를 이전 버전으로 다운그레이드하는 것은 지원되지 않습니다.

• 한 번 시작된 인플레이스 메이저 버전 업그레이드는 취소할 수 없습니다.

• 최신 백업본이 없다면, 업그레이드하기 전에 백업을 해두는 것이 좋습니다.

또한, 업그레이드가 완료되면 데이터베이스가 새로운 PostgreSQL 메이저 버전을 사용하게 된다는 점에 유의하시기 바랍니다. PostgreSQL 는 데이터를 버전별 형식으로 저장하기 때문에, 업그레이드 이전의 백업 및 PITR 지점은 이전 버전의 타임라인에 속하므로 업그레이드된 버전으로 복원할 수 없습니다. 새 버전에서 전체 복원 및 PITR(특정 시점 복구) 기능을 유지하려면, 업그레이드가 완료된 직후 즉시 새로운 백업을 수행하십시오. 해당 백업은 새 버전 타임라인에서 향후 복구 작업의 기준이 됩니다.

IPU가 실패하더라도, 업그레이드 이전의 유효한 백업을 PITR과 함께 사용하여 이전 버전의 PostgreSQL 를 새 인스턴스로 복원할 수 있습니다.

문제점 해결

인플레이스 메이저 버전 업그레이드 후 애플리케이션에 예상치 못한 문제가 발생하여 이전 PostgreSQL 버전으로 되돌려야 하는 경우, 지원팀에 문의하여 안내를 받으십시오. 복구 과정을 복잡하게 만들 수 있으므로, 직접 PITR을 시작하거나 백업을 복원하지 마십시오.

모든 사전 검사가 통과될 때까지 인플레이스 주요 업그레이드는 진행되지 않습니다. 업그레이드가 소스 인스턴스에서 직접 수행되므로, 이러한 안전 장치는 사용자의 배포 환경을 보호하기 위해 마련되었습니다. 업그레이드가 차단된 경우 다음 영역을 검토하십시오:

• 멤버 수: 인플레이스 메이저 버전 업그레이드는 최대 3명의 멤버로 구성된 배포 환경을 지원합니다. 배포 구성원에 3명 이상이 포함된 경우, 사전 점검으로 인해 업그레이드가 차단됩니다. 수평 확장(horizontal scaling )을 통해 멤버를 제거할 수 없으므로, 업그레이드를 다시 시도하기 전에 IBM Cloud 지원팀에 지원 티켓을 제출하여 멤버 수를 줄이시기 바랍니다.
• 클러스터 상태: Patroni 클러스터가 정상적으로 작동하고, 리더/리플리카 상태가 명확하게 설정되어 있는지 확인하십시오. Patroni가 불안정성 또는 장애 조치 상태를 보고하는 경우 업그레이드를 진행할 수 없습니다.
• 디스크 공간: 사용 가능한 여유 공간이 충분한지 확인하십시오. 이 프로세스는 링크 모드를 pg_upgrade 사용하며, 이는 충분한 헤드룸이 필요합니다. 디스크 사용량이 설정된 한도(기본값: 90%)를 초과할 경우, 재시도 전에 여유 공간을 확보하십시오.
• 디스크 I/O 부하: 현재 I/O 사용률과 IOPS를 확인합니다. 시스템에 과부하가 걸릴 경우 성능 저하나 업그레이드 실패를 방지하기 위해 업그레이드가 일시 중지됩니다.
• 스키마 크기와 개체 수: 앞서 언급한 바와 같이, 스키마 크기는 인플레이스 메이저 버전 업그레이드 소요 시간에 직접적인 영향을 미칩니다. 개별 스키마가 최대 크기(기본값: 100GB)를 초과하지 않도록 하고, 인덱스 및 시퀀스 객체의 총 개수가 제한(기본값: 50,000개)을 넘지 않도록 하십시오. 대규모 스키마 또는 비정상적으로 많은 개체 수는 업그레이드 진행 전에 정리 또는 최적화가 필요할 수 있습니다. pg_upgrade 새로운 시스템 테이블을 생성하고 기존 사용자 데이터 파일을 재사용함으로써 신속한 업그레이드를 수행합니다. 이러한 시스템 테이블을 생성하는 데 소요되는 시간은 데이터베이스 개체 수에 비례합니다. 모니터링 통합을 사용하여 리소스 소비량을 평가할 수 있습니다. 모든 데이터베이스 구성 요소를 업그레이드할 수 없는 경우 업그레이드 작업이 실패합니다. 이는 유지보수 작업으로 인해 발생할 수 있습니다. 건강 상태 검사 실패로 인해 실패한 작업은 나중에 재시도할 수 있습니다. 작업이 계속 실패할 경우 IBM Cloud 지원팀 에 지원 티켓을 제출하십시오. 특정 검사가 귀하의 환경과 관련이 없는데도 업그레이드가 차단되는 경우, 추가 지원을 위해 지원 티켓을 생성하십시오.

승격 및 업그레이드 시범 실행

주요 버전 업그레이드의 영향을 평가하려면 모의 실행을 수행하십시오. 건식 실행은 승격 및 업그레이드를 시뮬레이션하며 결과는 데이터베이스 로그에 인쇄됩니다. 로그 분석 통합 를 통해 데이터베이스 로그에 액세스하고 확인할 수 있습니다. 이를 통해 현재 실행 중인 버전과 해당 확장 기능을 원하는 버전으로 성공적으로 업그레이드할 수 있습니다.

시범 실행은 skip_initial_backup이 false로 설정되고 version이 정의된 상태에서만 실행해야 합니다.

명령은 다음과 같습니다.

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \