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

9분 분량

Amazon Relational Database Service(Amazon RDS) for PostgreSQL 또는 Amazon 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 로그 파일 모니터링을 참조하십시오.

업그레이드 시간이 오래 걸림

보류 중인 유지 보수 활동 확인

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

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

이 문제를 방지하려면 RDS DB 인스턴스 또는 Aurora DB 인스턴스의 보류 중인 유지 보수 작업을 찾아보십시오. 또는 인스턴스에서 AWS Command Line Interface(AWS CLI) describe-pending-maintenance-actions 명령을 실행합니다.

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

참고: example-arn을 DB 인스턴스 ARN으로 바꾸십시오. AWS CLI 명령을 실행할 때 오류가 발생하면 AWS CLI 오류 문제 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

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

업그레이드 전 스냅샷 생성

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

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

기본 DB 인스턴스의 메이저 버전 업그레이드를 수행하면 Amazon RDS가 동일한 AWS 리전의 모든 읽기 전용 복제본을 자동으로 업그레이드합니다. 업그레이드 워크플로가 시작된 후 읽기 전용 복제본은 기본 DB 인스턴스에서 pg_upgrade가 성공적으로 완료될 때까지 대기합니다. 그런 다음 기본 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를 사용하여 쿼리를 종료하십시오. 이러한 함수에 대한 자세한 내용은 9.28.2 서버 신호 함수를 참조하십시오.

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

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 역할을 가진 다른 사용자를 생성하십시오.

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

호환되지 않는 파라미터 오류는 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 엔진의 업그레이드 또는 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 테이블의 콘텐츠를 새 버전으로 이동하지 않습니다. 콘텐츠를 이동하지 않으면 쿼리가 느려질 수 있습니다.