Amazon RDS for PostgreSQL과 Aurora for PostgreSQL의 메이저 버전 업그레이드 관련 문제를 해결하려면 어떻게 해야 하나요?

11분 분량
0

Amazon Relational Database Service(RDS) for PostgreSQL 또는 Amazon Aurora PostgreSQL 호환 버전에 대한 엔진 버전 업그레이드가 중단되었거나 실패했습니다.

간략한 설명

Amazon RDS가 새 버전의 데이터베이스 엔진을 지원하는 경우 DB 인스턴스를 새 버전으로 업그레이드할 수 있습니다. DB 인스턴스에 대해 마이너 버전 업그레이드 또는 메이저 버전 업그레이드를 수행할 수 있습니다.

마이너 버전 업그레이드는 보안 취약점을 패치하고 버그를 수정하는 데 사용됩니다. 이러한 업그레이드는 일반적으로 새로운 기능을 추가하지 않으며 내부 스토리지 형식을 변경하지 않습니다. 또한 동일한 메이저 버전의 이전 및 이후 마이너 릴리스와 항상 호환됩니다. 그러나 메이저 버전 업그레이드에는 기존 애플리케이션의 이전 버전과 호환되지 않는 데이터베이스 변경 사항이 포함됩니다. 이러한 업그레이드는 시스템 테이블, 데이터 파일 및 데이터 스토리지의 내부 형식을 변경할 수 있습니다. Amazon RDS는 PostgreSQL 유틸리티인 pg_upgrade를 사용하여 메이저 버전 업그레이드를 수행합니다.

PostgreSQL 인스턴스의 메이저 버전 업그레이드 중 Amazon RDS는 사전 확인 절차를 실행합니다. 이 절차는 업그레이드 실패의 원인이 될 수 있는 모든 문제를 식별합니다. 모든 데이터베이스에서 잠재적인 비호환 조건을 확인합니다. Amazon RDS는 사전 확인 프로세스 중 문제를 식별하면 실패한 사전 확인에 대한 로그 이벤트를 생성합니다. 모든 데이터베이스의 사전 확인 프로세스에 대한 자세한 내용을 알아보려면 pg_upgrade_precheck.log 업그레이드 로그를 확인하세요. Amazon RDS는 파일 이름에 타임스탬프를 추가합니다. RDS 이벤트가 업그레이드 실패의 원인을 제공할 수도 있습니다. 그러나 엔진과 관련된 문제의 경우 데이터베이스 로그 파일을 확인해야 합니다.

자세한 내용을 알아보려면 RDS for PostgreSQL에 대한 데이터베이스 로그 파일 보기 및 목록을 참조하세요. 또는 Aurora for PostgreSQL에 대한 데이터베이스 로그 파일 보기 및 목록을 참조하세요.

메이저 버전 업그레이드 중 RDS는 다음 단계를 완료합니다.

  1. 업그레이드 전에 인스턴스의 스냅샷을 생성합니다. 이는 DB 인스턴스의 백업 보존 기간을 0보다 큰 숫자로 설정한 경우에만 발생합니다.
  2. 인스턴스를 종료합니다.
  3. pg_upgrade 유틸리티를 사용하여 인스턴스에서 업그레이드 작업을 실행합니다.
  4. 업그레이드 후 인스턴스의 스냅샷을 생성합니다.

해결 방법

Amazon RDS에서 이러한 업그레이드를 관리하지만 버전 업그레이드 중 다음과 같은 문제가 발생할 수 있습니다.

  • 업그레이드하는 데 시간이 더 오래 걸립니다.
  • 업그레이드가 실패합니다.

업그레이드하는 데 시간이 오래 걸리는 경우

유지 관리 활동 보류 중: 보류 중인 모든 유지 관리 활동은 엔진 버전 업그레이드와 함께 자동으로 적용됩니다. RDS 인스턴스에 운영 체제 패치 적용이 여기에 포함될 수 있습니다. 이 경우 운영 체제 패치가 먼저 적용된 다음 엔진 버전이 업그레이드됩니다. 따라서 운영 체제 유지 관리 작업을 수행하면 업그레이드를 완료하는 데 걸리는 시간이 늘어납니다.

또한 RDS 인스턴스가 다중 AZ 배포에 있는 경우 운영 체제 유지 관리로 인해 장애 조치가 수행됩니다. 다중 AZ에서 인스턴스를 설정할 때 인스턴스에 대한 백업은 일반적으로 보조 인스턴스에 생성됩니다. 장애 조치의 경우 업그레이드 후 새 보조 인스턴스에 백업이 생성됩니다. 새 보조 인스턴스의 이 백업이 최신 백업이 아닐 수 있습니다. 따라서 증분 백업 대신 전체 백업이 트리거될 수 있습니다. 특히 데이터베이스가 매우 큰 경우 전체 백업을 생성하는 데 시간이 오래 걸릴 수 있습니다.

이 문제를 방지하려면 RDS 콘솔의 Pending maintenance(대기 중인 유지 관리) 섹션에서 보류 중인 유지 관리 작업을 찾습니다. Aurora for PostgreSQL의 경우 보류 중인 유지 관리 보기를 참조하세요.

또는 인스턴스에 AWS Command Line Interface(AWS CLI) 명령인 describe-pending-maintenance-actions를 사용합니다.

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

참고: 데이터베이스 엔진 버전 업그레이드를 수행하기 전에 이러한 유지 관리 작업을 완료하세요.

업그레이드 전에 스냅샷이 생성되지 않음: 업그레이드를 수행하기 전에 RDS의 스냅샷을 생성하거나 Aurora for PostgreSQL 클러스터 스냅샷을 생성하는 것이 가장 좋습니다. 인스턴스에 대해 백업을 이미 켠 경우 업그레이드 프로세스의 일부로 스냅샷이 자동으로 생성됩니다. 업그레이드 전에 스냅샷을 생성하면 업그레이드 프로세스를 완료하는 데 필요한 시간이 줄어듭니다. 이는 업그레이드 프로세스 중 증분 백업만 생성되기 때문입니다.

RDS for PostgreSQL 읽기 전용 복제본 업그레이드: 기본 DB 인스턴스의 메이저 버전 업그레이드를 수행하면 동일한 리전의 모든 읽기 전용 복제본이 자동으로 업그레이드됩니다. 업그레이드 워크플로가 시작된 후 읽기 전용 복제본은 기본 DB 인스턴스에서 pg_upgrade가 성공적으로 완료될 때까지 기다립니다. 그런 다음 기본 인스턴스 업그레이드는 읽기 전용 복제본 업그레이드가 완료될 때까지 기다립니다. 모든 업그레이드가 완료될 때까지 중단이 발생합니다. 업그레이드를 위한 가동 중지 시간이 제한되어 있는 경우 복제본 인스턴스를 승격하거나 삭제할 수 있습니다. 그런 다음 업그레이드가 완료된 후 읽기 전용 복제본을 다시 생성합니다.

클러스터를 구성하는 DB 인스턴스를 안전하게 업그레이드하기 위해 Aurora for PostgreSQL는 pg_upgrade 유틸리티를 사용합니다. 라이터 업그레이드가 완료된 후 각 리더 인스턴스는 새 메이저 버전으로 업그레이드되는 동안 잠시 중단됩니다.

업그레이드 전 장기 실행 트랜잭션 또는 과중한 워크로드: 업그레이드 전 장기 실행 트랜잭션 또는 과중한 워크로드로 인해 데이터베이스를 종료하는 데 걸리는 시간과 업그레이드 시간이 늘어날 수 있습니다.

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

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_upgrade 유틸리티는 컴퓨팅 집약적일 수 있습니다. 따라서 프로덕션 데이터베이스를 업그레이드하기 전에 모의 업그레이드를 수행하는 것이 가장 좋습니다. 프로덕션 인스턴스의 스냅샷을 복원하고 프로덕션 데이터베이스와 동일한 인스턴스 클래스로 모의 실습을 수행할 수 있습니다.

업그레이드가 실패한 경우

지원되지 않는 DB 인스턴스 클래스: DB 인스턴스의 인스턴스 클래스가 업그레이드하려는 PostgreSQL 버전과 호환되지 않으면 업그레이드가 실패할 수 있습니다. 인스턴스 클래스와 엔진 버전의 호환성을 확인해야 합니다. 자세한 내용을 알아보려면 RDS for PostgreSQL용 DB 인스턴스 클래스에 대해 지원되는 DB 엔진을 검토하세요. 또는 Aurora for PostgreSQL용 DB 인스턴스 클래스에 대해 지원되는 DB 엔진을 검토하세요.

해결되지 않은 준비된 트랜잭션: 데이터베이스에서 해결되지 않은 준비된 트랜잭션으로 인해 업그레이드가 실패할 수 있습니다. 업그레이드를 시작하기 전에 해결되지 않은 준비된 트랜잭션을 모두 커밋하거나 롤백해야 합니다.

인스턴스에 해결되지 않은 준비된 트랜잭션이 있는지 확인하려면 다음 쿼리를 사용합니다.

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

이 경우 pg_upgrade.log 파일의 오류는 다음과 유사합니다.

------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with 
the requested major engine version upgrade and try the upgrade again.

*There are uncommitted prepared transactions. Please commit or rollback 
all prepared transactions.*

지원되지 않는 데이터 형식: 다음과 같이 지원되지 않는 데이터 형식으로 데이터베이스를 업그레이드하려고 하면 오류가 발생하여 업그레이드가 실패합니다.

  • regcollation
  • regconfig
  • regdictionary
  • regnamespace
  • regoper
  • regoperator
  • regproc
  • regprocedure

참고: regclass, regrole 및 retype 데이터 형식이 지원됩니다.

PostgreSQL 업그레이드 유틸리티인 pg_upgrade는 reg* OID 참조 시스템 데이터 형식을 사용하는 테이블 열이 포함된 데이터베이스 업그레이드를 지원하지 않습니다. 업그레이드를 시도하기 전에 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');

논리적 복제 슬롯: 인스턴스에 논리적 복제 슬롯이 있는 경우 업그레이드를 수행할 수 없습니다. 논리적 복제 슬롯은 일반적으로 AWS Database Migration Service(AMS DMS) 마이그레이션에 사용됩니다. 데이터베이스에서 데이터 레이크, 비즈니스 인텔리전스 도구 및 기타 대상으로 테이블을 복제하는 데에도 사용됩니다. 업그레이드 전에 사용 중인 논리적 복제 슬롯의 용도를 알고 있고 이들을 삭제할 수 있는지 확인합니다.

논리 복제 슬롯이 계속 사용 중이면 삭제해서는 안 됩니다. 이 경우 업그레이드를 진행할 수 없습니다.

pg_upgrade 로그 파일의 관련 오류는 다음 예시와 비슷합니다.

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

논리적 복제 슬롯이 필요하지 않은 경우 다음 쿼리를 실행하여 삭제합니다.

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(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

이 문제를 해결하려면 업그레이드를 시작하기 전에 인스턴스에 충분한 여유 스토리지가 있는지 확인합니다.

알 수 없는 데이터 형식: PostgreSQL 버전 10 이상에서는 알 수 없는 데이터 형식을 지원하지 않습니다. PostgreSQL 버전 9.6 데이터베이스에서 알 수 없는 데이터 형식을 사용하는 경우 버전 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."

이는 PostgreSQL의 제한 사항이며 RDS 자동화는 알 수 없는 데이터 형식을 사용하여 열을 수정하지 않습니다. 업그레이드 전에 이러한 열을 수동으로 수정해야 할 수 있습니다.

데이터베이스에서 알 수 없는 데이터 형식의 열을 찾으려면 다음 쿼리를 실행합니다.

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

이러한 열을 식별한 후 제거하거나 지원되는 데이터 형식으로 수정할 수 있습니다.

읽기 전용 복제본 업그레이드 실패(RDS for PostgreSQL만 해당): PostgreSQL 인스턴스에 읽기 전용 복제본이 있는 경우 읽기 전용 복제본 업그레이드 실패로 인해 기본 인스턴스 업그레이드가 중단될 수 있습니다. 읽기 전용 복제본 업그레이드 실패로 인해 기본 인스턴스 업그레이드가 실패할 수도 있습니다. 실패한 읽기 전용 복제본은 비호환 복구 상태가 되고 DB 인스턴스에서 복제가 중지됩니다.

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

  • 대기 시간이 지난 후에도 읽기 전용 복제본이 기본 DB 인스턴스를 따라잡을 수 없습니다.
  • 읽기 전용 복제본이 터미널 또는 호환되지 않는 수명 주기 상태(예: 스토리지 꽉 참 또는 비호환 복구)에 있습니다.
  • 기본 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

이 문제를 해결하려면 rds_superuser 역할을 가진 다른 사용자를 생성합니다. AWS Support에 문의하여 이 사용자를 새 기본 사용자로 업데이트할 수 있습니다.

호환되지 않는 파라미터 오류: shared_buffer 또는 work_memory와 같은 메모리 관련 파라미터가 더 높은 값으로 설정된 경우 이 오류가 발생합니다. 이로 인해 업그레이드 스크립트가 실패할 수 있습니다. 이 문제를 해결하려면 이러한 파라미터의 값을 줄인 다음 업그레이드를 다시 실행합니다.

업그레이드 전에 업데이트되지 않은 확장 프로그램: 메이저 버전 업그레이드는 PostgreSQL 확장 프로그램을 업그레이드하지 않습니다. 메이저 버전 업그레이드를 수행하기 전에 확장 프로그램을 업데이트하지 않으면 pg_upgrade.log 파일에 다음 오류가 표시됩니다.

The Logs indicates that the RDS instance ''xxxx'' 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_version
FROM pg_available_extensions WHERE installed_version IS NOT NULL AND
name LIKE 'postgis%' OR name LIKE 'address%';

installed_version 값이 default_version 값보다 작은 경우 PostGIS를 기본 버전으로 업데이트해야 합니다. 이렇게 하려면 다음 쿼리를 실행합니다.

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

자세한 내용을 알아보려면 RDS for PostgreSQL용 PostgreSQL 확장 프로그램 업그레이드 또는 Aurora PostgreSQL용 PostgreSQL 확장 프로그램 업그레이드를 참조하세요.

대상 버전의 시스템 카탈로그 변경으로 인한 보기 문제: 특정 보기의 열은 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으로 업그레이드할 때 발생합니다. 이 오류는 버전 9.6에서 대기 중인 열이 wait_event_typewait_event 열로 대체되기 때문에 pg_stat_activity 보기로 인해 발생합니다.

pg_restore: from TOC entry xxx; xxx xxxx 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의 구조가 변경되었기 때문에 발생합니다.

대상 버전의 시스템 카탈로그를 기반으로 보기를 삭제하여 이 문제를 해결할 수 있습니다.

참고: 이러한 보기를 삭제할 때는 주의하세요. 반드시 DBA와 상의하세요.

기타 고려 사항

  • pg_upgrade 유틸리티는 pg_upgrade_internal.logpg_upgrade_server.log라는 두 개의 로그를 생성합니다. Amazon RDS는 이러한 로그의 파일 이름에 타임스탬프를 추가합니다. 업그레이드 중 발생한 문제와 오류에 대한 자세한 내용을 알아보려면 이러한 로그를 보세요. 자세한 내용을 알아보려면 RDS for PostgreSQL에 대한 Amazon RDS 로그 파일 모니터링 또는 Aurora for PostgreSQL에 대한 Amazon Aurora 로그 파일 모니터링을 참조하세요.
  • 업그레이드가 완료되면 모든 사용자 데이터베이스에서 ANALYZE를 실행하여 pg_statistics 테이블을 업그레이드합니다. 메이저 업그레이드는 pg_statistics 테이블의 내용을 새 버전으로 이동하지 않습니다. 이 단계를 건너뛰면 쿼리 실행 속도가 느려질 수 있습니다.
  • PostgreSQL 버전 10으로 업그레이드한 경우 가지고 있는 모든 해시 인덱스에서 REINDEX를 실행합니다. 해시 인덱스는 버전 10에서 변경되었으며 다시 빌드해야 합니다. 잘못된 해시 인덱스를 찾으려면 해시 인덱스가 포함된 각 데이터베이스에 대해 다음 SQL을 실행합니다.
SELECT idx.indrelid::regclass AS table_name, 
   idx.indexrelid::regclass AS index_name 
FROM pg_catalog.pg_index idx
   JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid 
   JOIN pg_catalog.pg_am am ON am.oid = cls.relam 
WHERE am.amname = 'hash' 
AND NOT idx.indisvalid;

관련 정보

PostgreSQL 업그레이드 개요

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