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은 현재 지원되는 PostgreSQL 버전으로의 직접적인 주 버전 업그레이드만 지원합니다. 예를 들어 대상 버전이 업그레이드 시 Azure에서 공식적으로 지원되는 경우 현재 버전을 업그레이드할 수 있습니다. 지원되지 않는 버전은 업그레이드 대상으로 선택할 수 없으며 사용되지 않는 버전으로 업그레이드하려고 하면 실패 또는 서비스 중단이 발생할 수 있습니다. 주 버전 업그레이드를 시작하기 전에 항상 Azure PostgreSQL 버전 관리 정책 및 업그레이드 설명서를 참조하세요 .
비고
PostgreSQL 18에 대한 주 버전 업그레이드는 단계적으로 사용하도록 설정되고 있습니다. 현재 MVU에서 PostgreSQL 18까지는 NorthCentralUS 및 WestCentralUS 지역에서 사용할 수 있습니다.
업그레이드 프로세스
전체 주 버전 업그레이드에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다.
- 업그레이드를 시작하기 전에 서버에 10~20개 이상의% 사용 가능한 저장소가 있는지 확인합니다. 업그레이드 프로세스 중에 임시 로그 파일 및 메타데이터 작업을 수행하면 디스크 사용량이 증가할 수 있습니다. 사용 가능한 공간이 부족하면 업그레이드 실패 또는 롤백 문제가 발생할 수 있습니다.
- 현재 위치 주 버전 업그레이드 프로세스 중에 Azure Database for PostgreSQL 유연한 서버 인스턴스는 사전 검사 절차를 실행하여 업그레이드가 실패할 수 있는 잠재적인 문제를 식별합니다.
- 사전 검사에서 비호환성을 찾으면 오류 메시지와 함께 업그레이드 사전 검사가 실패했음을 보여 주는 로그 이벤트를 만듭니다.
- 사전 확인에 성공하면 Azure Database for PostgreSQL 유연한 서버 인스턴스가 서비스를 중지하고 업그레이드를 시작하기 직전에 암시적 백업을 수행합니다. 업그레이드 오류가 있는 경우 서비스는 이 백업을 사용하여 데이터베이스 인스턴스를 이전 버전으로 복원할 수 있습니다.
- Azure Database for PostgreSQL 유연한 서버 인스턴스는 pg_upgrade 도구를 사용하여 현재 위치 주 버전 업그레이드를 수행합니다. 이 서비스는 버전을 건너뛰고 최신 버전으로 직접 업그레이드할 수 있는 유연성을 제공합니다.
- HA(고가용성)를 사용하도록 설정된 서버의 현재 위치 주 버전 업그레이드 중에 서비스는 HA를 사용하지 않도록 설정하고 주 서버에서 업그레이드를 수행한 다음 업그레이드가 완료된 후 HA를 다시 사용하도록 설정합니다.
- 대부분의 확장은 일부 예외를 제외하고 전체 주 버전 업그레이드 중에 자동으로 이후 버전으로 업그레이드됩니다.
- Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 현재 위치 주 버전 업그레이드 프로세스는 지원되는 최신 부 버전을 자동으로 배포합니다.
- 현재 위치 주 버전 업그레이드는 오프라인 작업이므로 프로세스 중에 서버를 사용할 수 없습니다. 대부분의 업그레이드는 15분 미만으로 완료되지만 실제 기간은 데이터베이스의 크기와 복잡성에 따라 달라집니다. 특히 필요한 시간은 PostgreSQL 인스턴스의 개체 수(테이블, 인덱스, 스키마)에 직접 비례합니다. 더 크거나 더 복잡한 스키마는 업그레이드 시간이 길어질 수 있습니다.
- 업그레이드 전 장기 실행 트랜잭션 또는 높은 워크로드로 인해 데이터베이스를 종료하는 데 걸리는 시간이 늘어나고 업그레이드 시간이 늘어날 수 있습니다.
- 전체 주 버전 업그레이드가 성공하면 이전 버전으로 되돌릴 수 있는 자동화된 방법이 없습니다. 그러나 업그레이드 이전 지점으로 PITR(특정 시점 복원)을 수행하여 이전 버전의 데이터베이스 인스턴스를 복원할 수 있습니다.
- Azure Database for PostgreSQL 유연한 서버 인스턴스는 업그레이드 중에 데이터베이스의 스냅샷을 만듭니다. 업그레이드가 시작되기 전에 스냅샷이 만들어집니다. 업그레이드에 실패하면 시스템은 스냅샷에서 데이터베이스를 해당 상태로 자동으로 복원합니다.
- PostgreSQL 16에는 역할 기반 보안 측정값이 도입되었습니다. Azure Database for PostgreSQL 유연한 서버 인스턴스에서 주 버전을 업그레이드한 후 서버에서 만든 첫 번째 사용자(ADMIN 옵션이 부여됨)는 이제 필수 유지 관리 작업에 대한 다른 역할에 대한 관리 권한을 갖게 됩니다.
업그레이드 고려 사항 및 제한 사항
현재 위치 주 버전 업그레이드 중에 사전 검사 작업이 실패하면 자세한 오류 메시지와 함께 업그레이드가 차단됩니다. 다음은 업그레이드가 실패하거나 예기치 않게 동작할 수 있는 알려진 제한 사항입니다.
지원되지 않는 서버 구성
- 현재 위치 업그레이드에서는 읽기 복제본이 지원되지 않습니다. 주 서버를 업그레이드하기 전에 읽기 복제본(계단식 읽기 복제본 포함)을 삭제해야 합니다. 업그레이드 후 복제본을 다시 만들 수 있습니다.
- 네트워크 트래픽 규칙은 업그레이드 작업을 차단할 수 있습니다.
- 유연한 서버 인스턴스가 가상 네트워크 내의 포트 5432 및 6432 및 Azure Storage(로그 보관용)에서 트래픽을 보내거나 받을 수 있는지 확인합니다.
- NSG(네트워크 보안 그룹)가 이 트래픽을 제한하는 경우 HA는 업그레이드 후 자동으로 다시 사용하도록 설정하지 않습니다. NSG 규칙을 수동으로 업데이트하고 HA를 다시 사용하도록 설정해야 할 수 있습니다.
- 논리적 복제 슬롯은 동일 장소에서의 주 버전 업그레이드 동안 지원되지 않습니다.
- SSDv2 스토리지를 사용하는 서버는 주 버전 업그레이드에 적합하지 않습니다.
- 주 버전 업그레이드 동안에는
pg_stat_activity에 종속된 뷰가 지원되지 않습니다. - PG11에서 상위 버전으로 업그레이드를 수행하는 경우 먼저 SCRAM을 사용하도록 설정하고 모든 로그인 역할 암호를 다시 설정하여 SCRAM 인증 을 사용하도록 유연한 서버를 구성해야 합니다.
확장 제한 사항
시스템 내 주요 버전 업그레이드는 모든 PostgreSQL 확장을 지원하지 않습니다. 지원되지 않는 확장이 발견되면 사전 검사 중에 업그레이드가 실패합니다.
- 다음 확장은 일반적인 용도로 지원되지만 있는 경우 제자리에서의 주요 버전 업그레이드를 차단합니다. 업그레이드 전에 제거하고 대상 버전에서 지원되는 경우
timescaledb,dblink,orafce,postgres_fdw을(를) 다시 활성화하십시오. - 다음 확장은 비영구 유틸리티 확장이며 업그레이드 후 삭제하고 다시 만들어야 합니다.
pg_repackhypopg - PostgreSQL 17로 업그레이드할 때는 다음 확장이 지원되지 않으며 업그레이드하기 전에 제거해야 합니다. 대상 버전
age에서azure_aihllpg_diskannpgrouting지원되는 경우에만 다시 사용하도록 설정할 수 있습니다.
메모: 이러한 확장이 서버 매개 변수에 azure.extensions 표시되면 업그레이드가 차단됩니다. 업그레이드를 시작하기 전에 매개 변수에서 제거합니다.
PostGIS 관련 고려 사항
PostGIS 또는 종속 확장을 사용하는 경우 다음을 포함하도록 search_path 서버 매개 변수를 구성해야 합니다.
- PostGIS와 관련된 스키마
-
postgis,postgis_raster,postgis_sfcgal,postgis_tiger_geocoder,postgis_topology,address_standardizer,address_standardizer_data_us,fuzzystrmatch를 포함한 종속 확장명 - search_path 올바르게 구성하지 못하면 업그레이드 후 업그레이드 실패 또는 개체 손상이 발생할 수 있습니다.
기타 업그레이드 고려 사항
- 이벤트 트리거: 업그레이드 사전 확인은 이벤트 트리거가 DDL 명령에 연결되고 주 버전 간에 변경되는 시스템 카탈로그를 참조할 수 있기 때문에 이벤트 트리거를 차단합니다. 업그레이드하기 전에 모두
EVENT TRIGGER삭제한 다음 업그레이드 후에 다시 만들어 원활한 업그레이드를 보장합니다. - LO(큰 개체): 수백만 개의 큰 개체가 저장된
pg_largeobject데이터베이스는 높은 메모리 사용량 또는 로그 볼륨으로 인해 업그레이드 오류가 발생할 수 있습니다. vacuumlo 유틸리티를 사용하여 사용되지 않는 LO를 정리하고, 많은 LO가 계속 사용 중인 경우 업그레이드하기 전에 서버를 확장하는 것이 좋습니다.
경고
vacuumlo 사용 시 주의하세요.
vacuumlo는 기존의 참조 열(oid, lo)을 기반으로 분리된 큰 개체를 식별합니다. 애플리케이션에서 사용자 지정 또는 간접 참조 형식을 사용하는 경우 유효한 큰 개체가 실수로 삭제될 수 있습니다.
vacuumlo 또한 특히 수백만 개의 큰 개체가 있는 데이터베이스에서 상당한 CPU, 메모리 및 IOPS를 사용할 수 있습니다. 유지 관리 기간 동안 실행하고 비-prod에서 먼저 테스트합니다.
업그레이드 후
주 버전 업그레이드가 완료된 후, 각 데이터베이스에서 ANALYZE 명령을 실행하여 pg_statistic 테이블을 새로 고치기를 권장합니다. 통계가 없거나 부실하면 쿼리 계획이 잘못되어 성능이 저하되고 과도한 메모리가 소요될 수 있습니다.
postgres=> analyze;
ANALYZE
업그레이드 로그 보기
주 버전 업그레이드 로그(PG_Upgrade_Logs)는 자세한 서버 로그에 대한 직접 액세스를 제공합니다.
PG_Upgrade_Logs를 업그레이드 프로세스에 통합하면 새 PostgreSQL 버전으로 더욱 원활하고 투명하게 전환하는 데 도움이 될 수 있습니다.
다음 서버 매개 변수를 사용하여 서버 로그와 동일한 방식으로 주 버전 업그레이드 로그를 구성할 수 있습니다.
- 이 기능을 켜려면
logfiles.download_enable을ON으로 설정합니다. - 로그 파일의 보존 기간(일)을 정의하려면
logfiles.retention_days를 사용합니다.
업그레이드 로그 설정
PG_Upgrade_Logs의 사용을 시작하려면 PostgreSQL 서버 로그와 주 버전 업그레이드 로그 캡처를 구성하세요.
서버 로그용 UI를 통해 업그레이드 로그에 액세스할 수 있습니다. 여기에서 PostgreSQL 주 버전 업그레이드의 진행률과 세부 정보를 실시간으로 모니터링할 수 있습니다. 이 UI는 로그를 볼 수 있는 중앙 위치를 제공하므로 업그레이드 프로세스를 보다 쉽게 추적하고 문제를 해결할 수 있습니다.
업그레이드 로그 사용의 이점
-
통찰력 있는 진단:
PG_Upgrade_Logs는 업그레이드 프로세스에 대한 귀중한 인사이트를 제공합니다. 수행된 작업에 대한 자세한 정보를 캡처하고 발생하는 오류 또는 경고를 강조 표시합니다. 이러한 세부 수준은 보다 원활한 전환을 위해 업그레이드 중에 발생할 수 있는 문제를 진단하고 해결하는 데 도움이 됩니다. - 간소화된 문제 해결: 이러한 로그에 직접 액세스하면 잠재적인 업그레이드 장애 요인을 신속하게 식별하고 해결할 수 있으므로 가동 중지 시간을 줄이고 작업에 미치는 영향을 최소화할 수 있습니다. 로그는 보다 효율적이고 효과적인 문제 해결을 가능하게 하여 중요한 문제 해결 도구 역할을 합니다.
비고
직접 주 버전 업그레이드는 자동 마이그레이션 서버에서 지원됩니다. 자동 마이그레이션된 서버에서 전체 주 버전 업그레이드가 성공하면 사용자 이름 형식 username@servername 더 이상 지원되지 않습니다. 대신 표준 형식인 사용자 이름을 사용해야 합니다. 인증 문제를 방지하려면 업그레이드 후 업데이트된 사용자 이름 형식을 사용하도록 애플리케이션 및 스크립트의 모든 연결 문자열을 신중하게 검토하고 업데이트합니다.