PostgreSQL용 Azure Database의 유연한 서버에서 주요 버전 업그레이드

Azure Database for PostgreSQL 유연한 서버 인스턴스는 PostgreSQL 버전 18, 17, 16, 15, 14, 13, 12, 11을 지원합니다. Postgres 커뮤니티는 약 1년에 한 번씩 새로운 기능을 포함하는 새로운 주 버전을 릴리스합니다. 또한 각 주 버전에는 부 릴리스 형태로 정기적인 버그 수정이 제공됩니다. 부 버전 업그레이드에는 기존 애플리케이션과 호환되는 변경 내용이 포함됩니다. Azure Database for PostgreSQL 유연한 서버 인스턴스는 고객의 유지 관리 기간 동안 부 버전을 주기적으로 업데이트합니다.

주 버전 업그레이드는 부 버전 업그레이드보다 더 복잡합니다. 여기에는 기존 애플리케이션과 호환되지 않을 수 있는 내부 변경 내용과 새로운 기능이 포함될 수 있습니다.

Azure Database for PostgreSQL 유연한 서버 인스턴스에는 서버의 제자리 주 버전 업그레이드를 수행하는 기능이 있습니다. 이 기능은 서버에 액세스하는 사용자 및 애플리케이션의 중단을 최소화하여 업그레이드 프로세스를 간소화합니다.

전체 업그레이드는 주 버전 업그레이드 후에도 현재 서버의 서버 이름과 기타 설정을 보존합니다. 데이터 마이그레이션이나 애플리케이션 연결 문자열 변경이 필요하지 않습니다. 현재 위치 업그레이드는 데이터 마이그레이션보다 빠르고 가동 중지 시간이 짧습니다.

업그레이드 유효성 검사(미리 보기)

Azure Database for PostgreSQL 유연한 서버는 주 버전 업그레이드를 시작하기 전에 업그레이드 준비 상태를 평가하는 데 도움이 되는 업그레이드 유효성 검사 검사를 제공합니다.

업그레이드 유효성 검사에서는 서버에 대한 일련의 호환성 및 구성 유효성 검사를 실행하여 업그레이드가 실패하거나 예기치 않게 동작할 수 있는 조건을 식별합니다. 일반적인 검사에는 지원되지 않는 확장, 논리 복제 슬롯, 준비된 트랜잭션, 이벤트 트리거, 지원되지 않는 개체 종속성 및 보류 중인 다시 시작 필수 구성 변경이 포함됩니다.

유효성 검사 프로세스는 실제 업그레이드 작업을 시작하지 않고 업그레이드 준비 상태를 평가하도록 설계되었습니다. 주 버전 업그레이드 워크플로 중에도 동일한 유효성 검사가 자동으로 수행됩니다. 이러한 검사는 서버 버전을 수정하거나, 가동 중지 시간을 트리거하거나, 서버를 다시 시작하지 않습니다. 프로덕션 업그레이드 창을 예약하기 전에 유효성 검사를 실행하는 것이 좋습니다.

유효성 검사가 완료되면 다음 결과 중 하나가 반환됩니다.

• 차단 문제가 검색되지 않음: 업그레이드 유효성 검사가 성공적으로 완료되었으며 업그레이드를 차단하는 문제를 식별하지 못했습니다.
• 차단 문제 감지됨: 업그레이드 유효성 검사에서 업그레이드를 진행하기 전에 해결해야 하는 하나 이상의 문제를 확인했습니다.

결과에 따라 업그레이드를 진행하거나 보고된 문제를 수정하고 유효성 검사를 다시 실행할 수 있습니다.

Limitations

업그레이드 유효성 검사를 사용하는 경우 다음 제한 사항을 고려합니다.

• 서버 상태는 준비 상태여야 합니다.
• 읽기 복제본에서는 유효성 검사가 지원되지 않습니다.
• 다른 서버 작업이 이미 진행 중인 동안에는 유효성 검사를 실행할 수 없습니다.
• 유효성 검사에서는 서버의 모든 데이터베이스에 연결해야 합니다. 응답하지 않거나 액세스할 수 없는 데이터베이스는 유효성 검사 실패를 일으킬 수 있습니다.
• 유효성 검사로 인해 가동 중지 시간이 발생하지는 않지만 데이터베이스 작업이 낮은 기간 동안 실행하는 것이 좋습니다.

단계별 지침은 업그레이드 유효성 검사 실행(미리 보기)을 참조하세요.

업그레이드 프로세스

전체 주 버전 업그레이드에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다.

• 업그레이드를 시작하기 전에 서버에 최소 10~20%의 여유 저장 공간이 있는지 확인하십시오. 업그레이드 프로세스 중에 임시 로그 파일 및 메타데이터 작업을 수행하면 디스크 사용량이 증가할 수 있습니다. 사용 가능한 공간이 부족하면 업그레이드 실패 또는 롤백 문제가 발생할 수 있습니다.
• 현재 위치 주 버전 업그레이드 프로세스 중에 Azure Database for PostgreSQL 유연한 서버 인스턴스는 사전 검사 절차를 실행하여 업그레이드가 실패할 수 있는 잠재적인 문제를 식별합니다.
  • 사전 검사에서 비호환성을 찾으면 오류 메시지와 함께 업그레이드 사전 검사가 실패했음을 보여 주는 로그 이벤트를 만듭니다.
  • 사전 확인에 성공하면 Azure Database for PostgreSQL 유연한 서버 인스턴스가 서비스를 중지하고 업그레이드를 시작하기 직전에 암시적 백업을 수행합니다. 업그레이드 오류가 있는 경우 서비스에서 이 암시적 백업을 사용하여 데이터베이스 인스턴스를 이전 버전으로 복원할 수 있습니다.
• Azure Database for PostgreSQL 유연한 서버 인스턴스는 pg_upgrade 도구를 사용하여 현재 위치 주 버전 업그레이드를 수행합니다. 이 서비스는 버전을 건너뛰고 최신 버전으로 직접 업그레이드할 수 있는 유연성을 제공합니다.
• HA(고가용성)를 사용하도록 설정된 서버의 현재 위치 주 버전 업그레이드 중에 서비스는 HA를 사용하지 않도록 설정하고 주 서버에서 업그레이드를 수행한 다음 업그레이드가 완료된 후 HA를 다시 사용하도록 설정합니다. HA를 다시 사용하도록 설정하려면 새 대기 인스턴스를 프로비전하는 데 충분한 용량이 필요합니다.
• 대부분의 확장은 일부 예외를 제외하고 전체 주 버전 업그레이드 중에 자동으로 이후 버전으로 업그레이드됩니다.
• Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 현재 위치 주 버전 업그레이드 프로세스는 지원되는 최신 부 버전을 자동으로 배포합니다.
• 업그레이드 기간은 개체 수(테이블, 인덱스, 스키마), 큰 개체 및 확장명을 포함하여 데이터베이스의 크기와 복잡성에 따라 달라집니다. 더 크거나 더 복잡한 워크로드의 업그레이드 시간이 길어질 수 있습니다.
• 업그레이드 전 장기 실행 트랜잭션 또는 높은 워크로드로 인해 데이터베이스를 종료하는 데 걸리는 시간이 늘어나고 업그레이드 시간이 늘어날 수 있습니다.
• 전체 주 버전 업그레이드가 성공하면 이전 버전으로 되돌릴 수 있는 자동화된 방법이 없습니다. 업그레이드 전에 PITR(특정 시점 복구)을 수행하여 새 서버에서 이전 버전을 복원할 수 있습니다.
• Azure Database for PostgreSQL 유연한 서버 인스턴스는 업그레이드하는 동안 데이터베이스의 암시적 백업을 수행합니다. 암시적 백업은 업그레이드가 시작되기 전에 수행됩니다. 업그레이드에 실패하면 시스템은 암시적 백업에서 데이터베이스를 해당 상태로 자동으로 복원합니다.
• Azure Database for PostgreSQL Server 측정값을 보호합니다. Azure Database for PostgreSQL 유연한 서버 인스턴스에서 주 버전 업그레이드 후, ADMIN 옵션이 부여된 서버에서 생성된 첫 번째 사용자는 이제 필수 유지 관리 작업을 위해 다른 역할에 대한 관리 권한을 가집니다.

업그레이드 고려 사항 및 제한 사항

현재 위치 주 버전 업그레이드 중에 사전 검사 작업이 실패하면 자세한 오류 메시지와 함께 업그레이드가 차단됩니다. 다음은 업그레이드가 실패하거나 예기치 않게 동작할 수 있는 알려진 제한 사항입니다.

지원되지 않는 서버 구성

• Azure Database for PostgreSQL의 지역 간 복제는 제자리 업그레이드 중에는 지원되지 않습니다. 주 서버를 업그레이드하기 전에 읽기 복제본(계단식 읽기 복제본 포함)을 삭제해야 합니다. 업그레이드 후 복제본을 다시 만들 수 있습니다.
• 네트워크 트래픽 규칙은 업그레이드 작업을 차단할 수 있습니다.
  • 유연한 서버 인스턴스가 가상 네트워크 내의 포트 5432 및 6432 및 Azure Storage 트래픽을 보내고 받을 수 있는지 확인합니다(로그 보관용).
  • NSG(네트워크 보안 그룹)가 이 트래픽을 제한하는 경우 HA는 업그레이드 후 자동으로 다시 사용하도록 설정되지 않습니다. NSG 규칙을 수동으로 업데이트하고 HA를 다시 사용하도록 설정해야 할 수 있습니다.
• 현재 위치 주 버전 업그레이드를 수행 이전에 논리 복제 슬롯을 삭제하세요. 업그레이드가 완료된 후에 다시 만들 수 있습니다.
• 주 버전 업그레이드 중에는 pg_stat_activity 종속 뷰가 지원되지 않습니다.
• PostgreSQL 11에서 상위 버전으로 업그레이드를 수행하는 경우 먼저 SCRAM을 사용하도록 설정하고 모든 로그인 역할 암호를 다시 설정하여 SCRAM 인증 을 사용하도록 유연한 서버를 구성해야 합니다.

확장 제한 사항

현재 위치 주 버전 업그레이드는 모든 PostgreSQL 확장을 지원하지 않습니다. 영향을 받는 업그레이드 경로에 차단된 확장이 있는 경우 사전 검사 중에 업그레이드가 실패합니다. 대부분의 블록은 다음 목록에 설명된 대로 모든 업그레이드가 아닌 특정 대상 (때로는 원본) 버전으로 범위가 지정됩니다.

• 다음 확장은 모든 업그레이드 경로에서 현재 위치 주 버전 업그레이드를 차단합니다. 업그레이드 전에 제거하고 대상 버전에서 지원되는 경우 session_variable, anon, age, pg_duckdb을(를) 다시 활성화하십시오.

• 다음 확장은 비영구적 유틸리티 확장이며, 설계상(모든 업그레이드 경로에서) 업그레이드 전에 제거하고 업그레이드 후에 다시 생성해야 합니다: pg_repack, hypopg, pg_partman.

• 다음 확장은 특정 버전 경로에서만 차단됩니다. 업그레이드가 나열된 조건과 일치하는 경우 업그레이드 전에 제거한 후 대상 버전에서 지원되는 경우 다시 사용하도록 설정합니다.

  Extension	차단된 경우
  pg_hint_plan	대상 버전은 PostgreSQL 14입니다.
  semver	대상 버전은 PostgreSQL 16 또는 17입니다.
  azure_local_ai	대상 버전은 PostgreSQL 17 또는 18입니다.
  pg_failover_slots	대상 버전은 PostgreSQL 17 또는 18(공유 프리로드 라이브러리)입니다.
  azure_ai	대상 버전은 PostgreSQL 18입니다.
  azure_storage	대상 버전은 PostgreSQL 18입니다.
  pg_diskann	대상 버전은 PostgreSQL 18입니다.
  pgrouting	대상 버전은 PostgreSQL 15; 또는 원본이 PostgreSQL 16보다 이전이고 대상은 PostgreSQL 16 이상입니다. 또는 대상 버전이 PostgreSQL 18입니다.
  orafce	원본 버전은 PostgreSQL 11, 12 또는 13입니다.

• 업그레이드가 실패하기 때문에 다른 데이터베이스 개체가 해당 개체에 의존하는 경우 다음 확장이 차단됩니다. 업그레이드 전에 종속성을 해결합니다.

  • pg_stat_statements: 다른 개체가 해당 뷰 또는 함수에 종속되어 있어 이로 인해 ALTER EXTENSION pg_stat_statements UPDATE이(가) 실패할 수 있는 경우 차단됨. 먼저 종속 개체를 제거합니다.
  • pgcrypto: 스키마에 pg_catalog 설치하고 PostgreSQL 11 또는 12에서 PostgreSQL 13 이상으로 업그레이드하는 경우 고객 개체가 이 스키마에 의존할 때 차단됩니다(기본 제공 gen_random_uuid() 함수와 충돌). 확장을 다른 스키마로 재배치하거나 종속 개체를 먼저 삭제합니다.

PostGIS 관련 고려 사항

PostGIS 또는 종속 확장을 사용하는 경우 다음을 포함하도록 search_path 매개 변수를 구성해야 합니다.

• PostGIS와 관련된 스키마
• postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch를 포함한 종속 확장명
• search_path 올바르게 구성하지 못하면 업그레이드 후 업그레이드 실패 또는 개체 손상이 발생할 수 있습니다.

TimescaleDB 관련 고려 사항

TimescaleDB를 사용하는 경우 현재 위치 주 버전 업그레이드는 특정 PostgreSQL 원본 및 대상 버전 조합에 대해서만 지원됩니다.

TimescaleDB 업그레이드 경로가 지원되는 매트릭스에 나열되지 않으면 현재 위치 주 버전 업그레이드가 차단됩니다. 계속하려면 업그레이드하기 전에 TimescaleDB 확장을 삭제하거나 가능한 경우 논리 복제를 사용하여 병렬 마이그레이션과 같은 대체 마이그레이션 방법을 사용합니다.

업그레이드를 시작하기 전에 원본 및 대상 버전이 지원되는 매트릭스에 포함되어 있는지 확인합니다.

기타 업그레이드 고려 사항

• 이벤트 트리거: 업그레이드 사전 검사는 DDL 명령에 연결되고 주 버전 간에 변경되는 시스템 카탈로그를 참조할 수 있으므로 이벤트 트리거를 차단합니다. 업그레이드하기 전에 모든 EVENT TRIGGERs를 삭제한 다음 업그레이드 후에 다시 만들어 원활한 업그레이드를 보장합니다.
• LO(큰 개체): 수백만 개의 큰 개체가 저장된 pg_largeobject데이터베이스는 높은 메모리 사용량 또는 로그 볼륨으로 인해 업그레이드 오류가 발생할 수 있습니다. vacuumlo 유틸리티를 사용하여 사용되지 않는 LO를 정리하고, 많은 LO가 계속 사용 중인 경우 업그레이드하기 전에 서버를 확장하는 것이 좋습니다.

업그레이드 후

메이저 버전 업그레이드가 완료되면 각 데이터베이스에서 ANALYZE 명령을 실행하여 pg_statistic 테이블을 새로 고치십시오. 통계가 없거나 부실하면 쿼리 계획이 잘못되어 성능이 저하되고 과도한 메모리가 소요될 수 있습니다.

postgres=> analyze;
ANALYZE

업그레이드 로그 보기

업그레이드 진행률을 모니터링하고 문제를 해결하는 데 사용합니다 PG_Upgrade_Logs .

서버 로그 매개변수로 업그레이드 로그 활성화

• logfiles.download_enable을(를) ON으로 설정합니다.
• logfiles.retention_days를 사용하여 보존을 구성하십시오.

시작하려면 PostgreSQL 다운로드 및 업그레이드 로그 를 참조하세요.

서버 로그 UI에서 PG_Upgrade_Logs 액세스

• 업그레이드 도중 및 후에 검토 PG_Upgrade_Logs 하여 진행 상황을 모니터링하고 오류 또는 지연을 진단합니다.
• 업그레이드가 실패하거나 예상보다 오래 걸리는 경우 오류 또는 경고를 확인합니다.
• 로그를 사용하여 차단 문제를 식별하고 신속하게 수정 작업을 수행합니다.

업그레이드 로그 사용의 이점

• 신속하게 문제 진단: 업그레이드의 각 단계를 검토하고 오류 또는 경고를 식별하는 데 사용합니다 PG_Upgrade_Logs .
• 효율적인 문제 해결: 로그를 분석하여 오류를 정확히 파악하고 가동 중지 시간을 줄이며 수정 작업을 더 빠르게 수행합니다.

PG_Upgrade_Logs 은 업그레이드 중에 발생한 일을 이해하고 자신 있는 문제를 해결하는 데 도움이 됩니다.

관련 콘텐츠

• 메이저 버전 업그레이드
• 업그레이드 유효성 검사 실행(미리 보기)