Amazon RDS for PostgreSQL 또는 Aurora PostgreSQL 호환 버전에서 메이저 버전 업그레이드 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

메이저 버전 업그레이드에는 기존 애플리케이션과 역호환되지 않는 데이터베이스 변경 사항이 포함됩니다. 업그레이드로 인해 시스템 테이블, 데이터 파일 및 데이터 스토리지의 내부 형식이 변경될 수 있습니다. Amazon RDS는 pg_upgrade를 사용하여 메이저 버전 업그레이드를 수행합니다. 자세한 내용은 PostgreSQL 웹사이트의 pg_upgrade를 참조하십시오.

메이저 버전 업그레이드 도중 Amazon RDS는 사전 점검 절차를 실행하여 업그레이드 실패의 원인이 될 수 있는 문제를 식별합니다. 모든 데이터베이스에서 잠재적 비호환 상태를 확인합니다. Amazon RDS가 사전 점검 프로세스 중에 문제를 식별하면 실패한 사전 점검에 대한 로그 이벤트를 생성합니다. 로그 이벤트에는 파일 이름, 타임스탬프 및 업그레이드 실패 이유가 포함됩니다. 모든 데이터베이스의 사전 점검 프로세스에 대한 자세한 내용은 pg_upgrade_precheck.log 로그를 확인하십시오. 엔진 관련 문제의 경우 Amazon RDS for PostgreSQL 또는 Aurora PostgreSQL의 데이터베이스 로그 파일을 확인해야 합니다.

해결 방법

메이저 버전 업그레이드를 수행하는 pg_upgrade 유틸리티는 pg_upgrade_internal.log와 pg_upgrade_server.log를 생성합니다. Amazon RDS는 로그의 파일 이름에 타임스탬프를 추가합니다. 로그를 검토하여 업그레이드 중에 발생하는 문제 및 오류에 대한 자세한 정보를 확인하십시오. 자세한 내용은 Amazon RDS 로그 파일 모니터링 또는 Amazon Aurora 로그 파일 모니터링을 참조하십시오.

장기 실행 업그레이드

보류 중인 유지 관리 활동 확인

AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI의 오류 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

Amazon RDS는 엔진 버전 업그레이드를 사용하여 Amazon RDS 인스턴스의 운영 체제(OS) 패치와 같은 보류 중인 유지 관리 작업을 자동으로 적용합니다. Amazon RDS는 보류 중인 활동을 먼저 적용한 다음, 엔진 버전을 업그레이드합니다. Amazon RDS가 OS 유지 관리 작업을 수행해야 하는 경우 업그레이드 시간이 더 오래 걸립니다.

Amazon RDS 인스턴스가 다중 AZ 배포인 경우 OS 유지 관리로 인해 장애 조치가 발생합니다. 다중 AZ 환경에서 인스턴스를 설정할 때 Amazon RDS는 일반적으로 보조 인스턴스에 인스턴스의 백업을 생성합니다. 장애 조치 시 Amazon RDS는 업그레이드 후 새 보조 인스턴스에 백업을 생성합니다. 새 보조 인스턴스의 이 백업은 최신 백업이 아닐 수 있으므로 Amazon RDS는 증분 백업 대신 전체 백업을 완료합니다. 전체 백업은 특히 데이터베이스가 큰 경우 시간이 오래 걸릴 수 있습니다.

이 문제를 방지하려면 RDS DB 인스턴스 또는 Aurora DB 인스턴스의 보류 중인 유지 관리 작업을 검색하십시오. 또는 인스턴스에서 다음 describe-pending-maintenance-actions AWS CLI 명령을 실행합니다.

aws rds describe-pending-maintenance-actions --resource-identifier example-arn

참고: example-arn을 DB 인스턴스 ARN으로 바꾸십시오.

데이터베이스 엔진 버전 업그레이드를 수행하기 전에 보류 중인 유지 관리 작업을 완료하십시오.

업그레이드 전 스냅샷 생성

버전을 업그레이드하기 전에 RDS DB 인스턴스 또는 Aurora DB 클러스터의 스냅샷을 생성하는 것이 좋습니다. 인스턴스의 백업을 이미 활성화한 경우 Amazon RDS는 업그레이드 프로세스의 일부로 스냅샷을 자동 생성합니다. 스냅샷을 사용하면 Amazon RDS가 업그레이드의 일부로 증분 백업을 생성하기만 하면 되기 때문에 업그레이드 프로세스 시간이 줄어듭니다.

읽기 전용 복제본이 업그레이드될 때까지 대기

기본 DB 인스턴스의 메이저 버전 업그레이드를 수행하면 Amazon RDS가 동일한 AWS 리전의 모든 읽기 전용 복제본을 자동으로 업그레이드합니다. 업그레이드 워크플로가 시작된 후 읽기 전용 복제본은 기본 DB 인스턴스에서 pg_upgrade가 성공적으로 완료될 때까지 대기합니다. 그런 다음, 기본 DB 인스턴스 업그레이드는 읽기 전용 복제본 업그레이드가 완료될 때까지 기다립니다. DB 인스턴스는 모든 업그레이드가 완료될 때까지 종료됩니다. 업그레이드로 인한 가동 중지 시간이 짧으면 복제본 인스턴스를 승격하거나 삭제한 다음, 업그레이드가 완료된 후 읽기 전용 복제본을 다시 생성하십시오.

Aurora DB 클러스터의 경우 pg_upgrade는 먼저 작성기 인스턴스를 업그레이드합니다. 그런 다음, pg_upgrade가 새 메이저 버전으로 업그레이드할 때 각 리더 DB 인스턴스가 종료됩니다.

참고: Aurora 글로벌 데이터베이스를 업그레이드하는 경우 추가 요구 사항 및 프로세스가 있습니다.

업그레이드 전에 장기 실행 트랜잭션 또는 많은 워크로드 해결

트랜잭션이 장기 실행되거나 워크로드가 많으면 Amazon RDS가 데이터베이스를 종료하고 데이터베이스 엔진을 업그레이드하는 데 걸리는 시간이 증가할 수 있습니다.

장기 실행 트랜잭션을 식별하려면 다음 쿼리를 실행합니다.

SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query
FROM pg_stat_activity
WHERE query NOT ILIKE '%pg_stat_activity%' AND
usename!='rdsadmin'
ORDER BY query_start desc;

장기 실행 트랜잭션을 식별하는 경우 pg_cancel_backend 또는 pg_terminate_backend를 사용하여 트랜잭션을 종료하십시오. pg_cancel_backend 및 pg_terminate_backend에 대한 자세한 내용은 PostgreSQL 웹 사이트의 서버 신호 함수를 참조하십시오.

컴퓨팅 용량이 충분한지 확인

pg_upgrade 유틸리티는 컴퓨팅 집약적일 수 있습니다. 컴퓨팅 또는 메모리 용량이 충분한지 확인하려면 프로덕션 데이터베이스를 업그레이드하기 전에 테스트 업그레이드를 수행하는 것이 가장 좋습니다. 테스트 업그레이드는 사전 점검 또는 업그레이드 오류가 발생할 수 있는지 여부도 확인합니다. 프로덕션 인스턴스의 스냅샷을 복원하고 프로덕션 데이터베이스의 인스턴스 클래스와 동일한 인스턴스 클래스로 테스트를 수행할 수 있습니다.

업그레이드 실패

지원되지 않는 DB 인스턴스 클래스 확인

DB 인스턴스의 인스턴스 클래스가 업그레이드하려는 PostgreSQL 버전과 호환되지 않는 경우 업그레이드가 실패합니다. 엔진 버전이 Amazon RDS 또는 Amazon Aurora의 인스턴스 클래스와 호환되는지 확인하십시오.

열린 프리페어드 트랜잭션 확인

데이터베이스에 열린 프리페어드 트랜잭션이 있는 경우 업그레이드가 실패합니다. pg_upgrade.log 파일에 ‘There are uncommitted prepared transactions’ 오류가 발생합니다. 업그레이드를 시작하기 전에 모든 열린 프리페어드 트랜잭션을 커밋 또는 롤백하십시오.

인스턴스에 열린 프리페어드 트랜잭션이 있는지 확인하려면 다음 쿼리를 실행합니다.

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

지원되는 데이터 유형 사용

regclass, regrole 및 regtype 데이터 유형에 대해서만 버전을 업그레이드할 수 있습니다. pg_upgrade 유틸리티는 reg* OID(객체 식별자) 참조 유형을 사용하는 테이블 열을 포함한 데이터베이스를 업그레이드할 수 없습니다. regcollation, regconfig, regdictionary, regnamespace, regoper, regoperator, regproc 또는 regprocedure 데이터 유형을 사용하는 경우 업그레이드가 실패합니다.

이 문제를 해결하려면 데이터 엔진을 업그레이드하기 전에 regclass, regrole, regtype을 제외한 reg* 데이터 유형의 사용을 모두 제거하십시오. 테이블에서 지원되지 않는 reg* 데이터 유형이 있는지 확인하려면 다음 쿼리를 실행합니다.

SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a  WHERE c.oid = a.attrelid
      AND NOT a.attisdropped
      AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
                         'pg_catalog.regprocedure'::pg_catalog.regtype,
                         'pg_catalog.regoper'::pg_catalog.regtype,
                         'pg_catalog.regoperator'::pg_catalog.regtype,
                         'pg_catalog.regconfig'::pg_catalog.regtype,
                         'pg_catalog.regdictionary'::pg_catalog.regtype)
      AND c.relnamespace = n.oid
      AND n.nspname NOT IN ('pg_catalog', 'information_schema');

논리적 복제 슬롯 확인

인스턴스에 논리적 복제 슬롯이 있는 경우 인스턴스를 업그레이드할 수 없으며 pg_upgrade.log 파일에 다음 오류 메시지가 표시됩니다.

"The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again."

일반적으로 AWS Database Migration Service(AMS DMS) 마이그레이션에는 논리적 복제 슬롯을 사용합니다. 또한 이를 사용하여 데이터베이스의 테이블을 데이터 레이크, 비즈니스 인텔리전스 도구 및 기타 대상으로 복제할 수 있습니다. 삭제 여부를 결정하는 데 사용하는 논리적 복제 슬롯의 용도를 알고 있어야 합니다. 논리적 복제 슬롯이 사용 중이면 삭제하지 마십시오. 논리적 복제 슬롯을 삭제하려면 먼저 버전 업그레이드를 기다려야 합니다.

논리적 복제 슬롯이 필요하지 않은 경우 다음 명령을 실행하여 슬롯을 삭제하십시오.

SELECT * FROM pg_replication_slots;

SELECT pg_drop_replication_slot(slot_name);

참고: slot_name을 논리적 복제 슬롯의 이름으로 바꾸십시오.

스토리지 문제 확인

pg_upgrade 스크립트를 실행할 때 인스턴스 공간이 부족하면 업그레이드가 실패하고 다음 오류 메시지가 표시됩니다.

"pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space keyword" left on device"

이 문제를 해결하려면 업그레이드를 시작하기 전에 인스턴스에 충분한 스토리지를 사용할 수 있는지 확인하십시오.

unknown 데이터 유형 확인

PostgreSQL 버전 10 이상에서는 unknown 데이터 유형을 사용할 수 없습니다. 예를 들어 PostgreSQL 버전 9.6 데이터베이스가 unknown 데이터 유형을 사용하는 경우, 버전 10으로 업그레이드하면 다음 오류 메시지가 표시됩니다.

"The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again."

이 문제를 해결하려면 unknown 데이터 유형을 사용하는 열을 수동으로 제거하거나 지원되는 데이터 유형으로 수정하십시오. 데이터베이스에서 unknown 데이터 유형을 사용하는 열을 찾으려면 다음 쿼리를 실행합니다.

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

(RDS for PostgreSQL에만 해당) 읽기 전용 복제본 업그레이드 실패 여부 확인

PostgreSQL 인스턴스에 읽기 전용 복제본이 있는 경우 읽기 전용 복제본 업그레이드 실패로 인해 기본 인스턴스 업그레이드가 중단 또는 실패할 수 있습니다. Amazon RDS는 실패한 읽기 전용 복제본을 incompatible-restore 상태로 설정한 다음 DB 인스턴스에서 복제를 중지합니다.

읽기 전용 복제본 업그레이드는 다음 이유 중 하나로 실패할 수 있습니다.

• 대기 시간이 지난 후에도 읽기 전용 복제본이 기본 DB 인스턴스를 따라잡을 수 없습니다.
• 읽기 전용 복제본이 최종 상태이거나 비호환 수명 주기 상태(예: storage-full 또는 incompatible-restore)입니다.
• 기본 DB 인스턴스 업그레이드가 시작되면 읽기 전용 복제본에서 별도의 마이너 버전 업그레이드가 실시됩니다.
• 읽기 전용 복제본이 호환되지 않는 파라미터를 사용합니다.
• 읽기 전용 복제본이 기본 DB 인스턴스와 통신하여 데이터 폴더를 동기화할 수 없습니다.

이 문제를 해결하려면 읽기 전용 복제본을 삭제하십시오. 그런 다음, 업그레이드 후 업그레이드된 기본 인스턴스를 기반으로 새 읽기 전용 복제본을 다시 생성하십시오.

기본 사용자 이름이 정확한지 확인

기본 사용자 이름이 pg_로 시작하는 경우 업그레이드가 실패하고 다음과 같은 오류 메시지가 표시됩니다.

"PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again".

이 문제를 해결하려면 pg_로 시작하지 않으면서 rds_superuser 역할을 가진 다른 사용자를 생성하십시오.

호환되지 않는 파라미터 확인

‘incompatible parameters’ 오류는 shared_buffer 또는 work_memory와 같은 메모리 관련 파라미터의 값이 구성에 비해 너무 높을 때 발생합니다. 이 오류로 인해 업그레이드 스크립트가 실패합니다. 문제를 해결하려면 파라미터의 값을 줄인 후 다시 업그레이드하십시오.

업그레이드 전에 확장 프로그램 업데이트

메이저 버전 업그레이드는 PostgreSQL 확장 프로그램을 업그레이드하지 않습니다. 메이저 버전 업그레이드 전에 확장 프로그램을 업데이트하지 않으면 pg_upgrade.log 파일에 다음과 유사한 오류 메시지가 표시됩니다.

"The Logs indicates that the RDS instance ''abcd'' has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade."

위의 예제 오류 메시지는 PostGIS 확장 프로그램 관련 문제를 보여줍니다. 이 문제를 해결하려면 다음 쿼리를 실행하여 PostGIS 및 종속 확장 프로그램의 기본 버전과 설치된 버전을 확인합니다.

SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL AND
name LIKE 'postgis%' OR name LIKE 'address%';

참고: **postgis%**를 확장 프로그램으로 바꾸십시오.

installed_version 값이 default_version 값보다 낮은 경우 PostGIS를 기본 버전으로 업데이트해야 합니다. 확장 프로그램을 업그레이드하려면 다음 명령을 실행합니다.

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

참고: default_version_number를 default_version 값으로 바꾸십시오.

자세한 내용은 RDS for PostgreSQL DB 엔진 업그레이드 또는 Amazon Aurora PostgreSQL DB 클러스터 업그레이드를 참조하십시오.

뷰에서 문제를 일으키는 대상 버전의 시스템 카탈로그에서 변경 사항 확인

특정 뷰의 열은 PostgreSQL 버전마다 다릅니다. 예를 들어 다음과 유사한 오류 메시지가 표시될 수 있습니다.

"PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on 'pg_stat_activity'. Please drop them and try again."

이 오류는 데이터베이스를 버전 9.5에서 9.6으로 업그레이드할 때 발생합니다. 위의 예제 오류 메시지에서 pg_stat_activity 뷰가 문제의 원인입니다. 버전 9.6에서 PostgreSQL은 waiting 열을 wait_event_type 및 wait_event 열로 대체했습니다.

또는 다음과 유사한 오류 메시지가 표시됩니다.

"pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: "c"."consrc" AS "search_condition", ^ HINT: Perhaps you meant to reference the column "c.conkey" or the column "c.conbin"."

위의 예제 오류 메시지는 PostgreSQL 버전 12에서 pg_constraint 카탈로그 구조가 변경되어 오류가 발생했음을 보여줍니다.

이러한 문제를 해결하려면 대상 버전의 시스템 카탈로그를 기반으로 뷰를 삭제하십시오.

중요: 뷰를 삭제하기 전에 pgdump를 사용하여 뷰를 백업하거나 뷰의 정의를 캡처하는 것이 가장 좋습니다. 뷰를 삭제하면 사용자 또는 데이터베이스 관리자가 버전 업그레이드 후 뷰를 수동으로 다시 생성해야 합니다.

업그레이드 완료

업그레이드가 완료되면 모든 사용자 데이터베이스에서 ANALYZE를 실행하여 pg_statistics 테이블을 업그레이드합니다. 메이저 업그레이드는 pg_statistics 테이블의 콘텐츠를 새 버전으로 이동하지 않습니다. 콘텐츠를 이동하지 않으면 쿼리가 느리게 실행될 수 있습니다.

관련 정보

Aurora PostgreSQL 업그레이드 프로세스 개요