Azure Database for PostgreSQL로의 원활한 마이그레이션을 위한 모범 사례입니다.
적용 대상:
Azure Database for PostgreSQL - 유연한 서버
이 문서에서는 Azure Database for PostgreSQL로 원활하고 성공적인 마이그레이션을 보장하기 위해 발생하는 일반적인 문제와 모범 사례를 설명합니다.
마이그레이션 전 유효성 검사
마이그레이션의 첫 번째 단계로, 마이그레이션을 수행하기 전에 사전 마이그레이션 유효성 검사를 실행합니다. 마이그레이션 설정 페이지에서 유효성 검사 및 유효성 검사 및 마이그레이션 옵션을 사용할 수 있습니다. 사전 마이그레이션 유효성 검사는 미리 정의된 규칙 집합에 대해 철저한 검사를 수행합니다. 목표는 잠재적인 문제를 식별하고 해결 작업에 대한 실행 가능한 인사이트를 제공하는 것입니다. 성공 상태가 될 때까지 마이그레이션 전 유효성 검사를 계속 실행합니다. 자세한 내용을 보려면 마이그레이션 전 유효성 검사를 선택합니다.
대상 유연한 서버 구성
데이터의 초기 기본 복사 중에 대상에서 여러 개의 삽입 문이 실행되어 WAL(미리 쓰기 로그)이 생성됩니다. 이러한 WAL이 보관될 때까지 로그는 대상의 스토리지와 데이터베이스에 필요한 스토리지를 사용합니다.
숫자를 계산하려면 원본 인스턴스에 로그인하고 마이그레이션할 모든 데이터베이스에 대해 이 명령을 실행합니다.
SELECT pg_size_pretty( pg_database_size('dbname') );
위 명령의 출력에 사용되는 것보다 1.25배 또는 25% 더 많은 스토리지에 해당하는 충분한 스토리지를 유연한 서버에 할당하는 것이 좋습니다. 스토리지 자동 증가도 사용할 수 있습니다.
Important
수동 구성 또는 스토리지 자동 증가에서는 스토리지 크기를 줄일 수 없습니다. 스토리지 구성 스펙트럼의 각 단계는 크기가 두 배로 늘어나므로 필요한 스토리지를 미리 예측하는 것이 좋습니다.
포털을 사용하여 Azure Database for PostgreSQL 유연한 서버 만들기에 대한 빠른 시작에서 시작하는 것이 좋습니다. Azure Database for PostgreSQL - 유연한 서버의 컴퓨팅 및 스토리지 옵션은 각 서버 구성에 대한 자세한 정보도 제공합니다.
마이그레이션 타임라인
각 마이그레이션의 최대 수명은 시작 후 7일(168시간)이며 7일 후에 시간 초과됩니다. 마이그레이션 시간 초과를 방지하기 위해 데이터 유효성 검사 및 모든 유효성 검사가 완료되면 마이그레이션 및 애플리케이션 컷오버를 완료할 수 있습니다. 온라인 마이그레이션에서는 초기 기본 복사가 완료된 후 컷오버 기간이 3일(72시간) 동안 지속되고 시간이 초과됩니다. 오프라인 마이그레이션에서는 데이터 손실을 방지하기 위해 애플리케이션이 데이터베이스에 쓰기를 중지해야 합니다. 마찬가지로 온라인 마이그레이션의 경우 마이그레이션 전체에서 트래픽을 낮게 유지합니다.
대부분의 비프로덕션 서버(개발, UAT, 테스트, 스테이징)는 오프라인 마이그레이션을 사용하여 마이그레이션됩니다. 이러한 서버에는 프로덕션 서버보다 데이터가 적기 때문에 마이그레이션이 빠르게 완료됩니다. 프로덕션 서버 마이그레이션의 경우 마이그레이션을 완료하는 데 걸리는 시간을 알고 미리 계획을 세워야 합니다.
마이그레이션을 완료하는 데 걸리는 시간은 여러 요인에 따라 달라집니다. 여기에는 데이터베이스 수, 크기, 각 데이터베이스 내의 테이블 수, 인덱스 수 및 테이블 전체의 데이터 배포가 포함됩니다. 또한 대상 서버의 SKU와 원본 인스턴스 및 대상 서버에서 사용 가능한 IOPS에 따라 달라집니다. 마이그레이션 시간에 영향을 줄 수 있는 많은 요인을 고려할 때 마이그레이션을 완료하는 데 걸리는 총 시간을 예측하기는 어렵습니다. 워크로드로 테스트 마이그레이션을 수행하는 것이 가장 좋습니다.
프로덕션 서버 마이그레이션을 수행하기 위한 총 가동 중지 시간을 계산하기 위해 다음 단계가 고려됩니다.
PITR 마이그레이션 - 프로덕션 데이터베이스 서버를 마이그레이션하는 데 걸리는 시간을 정확히 예측하는 가장 좋은 방법은 프로덕션 서버의 지정 시간 복원을 수행하고 이 서버에서 새로. 복원된 서버에서 오프라인 마이그레이션을 실행하는 것입니다.
버퍼 마이그레이션 - 위 단계를 완료한 후 애플리케이션 트래픽이 적은 기간 동안 실제 프로덕션 마이그레이션을 계획할 수 있습니다. 이 마이그레이션은 같은 날 또는 일주일 후에 계획할 수 있습니다. 이때 원본 서버의 크기가 증가했을 수 있습니다. 이 증가량에 따라 프로덕션 서버의 예상 마이그레이션 시간을 업데이트합니다. 증가가 상당한 경우 PITR 서버를 사용하여 다른 테스트를 수행하는 것을 고려할 수 있습니다. 그러나 대부분의 서버에서 크기 증가는 그다지 중요하지 않습니다.
데이터 유효성 검사 - 프로덕션 서버에 대한 마이그레이션이 완료되면 유연한 서버의 데이터가 원본 인스턴스의 정확한 복사본인지 확인해야 합니다. 고객은 오픈 소스/타사 도구를 사용하거나 수동으로 유효성 검사를 수행할 수 있습니다. 실제 마이그레이션 전에 수행하려는 유효성 검사 단계를 준비합니다. 유효성 검사에는 다음이 포함될 수 있습니다.
마이그레이션과 관련된 모든 테이블의 행 수 일치.
모든 데이터베이스 개체(테이블, 시퀀스, 확장, 프로시저, 인덱스)에 대한 일치 개수
주요 애플리케이션 관련 열의 최대 또는 최소 ID 비교
참고 항목
데이터베이스의 크기는 유효성 검사에 적합한 메트릭이어야 합니다. 원본 인스턴스에는 블로트/데드 튜플이 있을 수 있으며, 이로 인해 원본 인스턴스의 크기가 커질 수 있습니다. 원본 인스턴스와 대상 서버 간에 크기 차이가 있는 것은 완전히 정상적입니다. 유효성 검사의 처음 세 단계에 문제가 있으면 마이그레이션에 문제가 있음을 나타냅니다.
서버 설정 마이그레이션 - 모든 사용자 지정 서버 매개 변수, 방화벽 규칙(해당하는 경우), 태그 및 경고를 원본 인스턴스에서 대상 인스턴스로 수동으로 복사해야 합니다.
연결 문자열 변경 - 애플리케이션은 유효성 검사에 성공한 후 연결 문자열을 유연한 서버로 변경해야 합니다. 이 작업은 원본 인스턴스를 가리키는 연결 문자열의 모든 참조를 변경하기 위해 애플리케이션 팀과 협력합니다. 유연한 서버에서는 연결 문자열에서 user 매개 변수를 user=username 형식으로 사용할 수 있습니다.
예: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
마이그레이션은 문제 없이 실행되는 경우가 많지만, 디버깅에 더 많은 시간이 필요하거나 마이그레이션을 다시 시작해야 하는 경우에 대비해 계획을 세우는 것이 좋습니다.
마이그레이션 속도 벤치마킹
다음 표에서는 마이그레이션 서비스를 사용하여 다양한 크기의 데이터베이스에 대한 마이그레이션을 수행하는 데 걸리는 시간을 보여 줍니다. 마이그레이션은 SKU가 있는 유연한 서버를 사용하여 수행되었습니다. – Standard_D4ds_v4(코어 4개, 16GB 메모리, 128GB 디스크 및 500 iops)
| 데이터베이스 크기 | 소요된 대략적 시간(HH:MM) |
|---|---|
| 1GB | 00:01 |
| 5GB | 00:03 |
| 10 GB | 00:08 |
| 50GB | 00:35 |
| 100GB | 01:00 |
| 500GB | 04:00 |
| 1,000GB | 07:00 |
참고 항목
위의 숫자는 마이그레이션을 완료하는 데 걸리는 대략적인 시간을 나타냅니다. 서버 마이그레이션에 대한 정확한 값을 가져오려면 워크로드에 대해 테스트 마이그레이션을 실행하는 것이 좋습니다.
Important
더 빠른 마이그레이션을 수행하려면 유연한 서버에 대해 더 높은 SKU를 선택합니다. Azure Database for PostgreSQL 유연한 서버는 가동 중지 시간이 거의 없는 컴퓨팅 및 IOPS 크기 조정을 지원하므로 가동 중지 시간을 최소화하면서 SKU를 업데이트할 수 있습니다. 마이그레이션 후 애플리케이션 요구 사항에 맞게 SKU를 언제든지 변경할 수 있습니다.
마이그레이션 속도 개선 - 테이블 병렬 마이그레이션
PostgreSQL 마이그레이션 서비스는 유연한 서버의 컨테이너에서 실행되므로 대상에는 강력한 SKU가 권장됩니다. 강력한 SKU를 사용하면 더 많은 테이블을 병렬로 마이그레이션할 수 있습니다. 마이그레이션 후 SKU를 원하는 구성으로 다시 크기 조정할 수 있습니다. 이 섹션에는 테이블 간의 데이터 배포를 더욱 균형 있게 유지해야 하거나 더 강력한 SKU가 마이그레이션 속도에 큰 영향을 미치지 않는 경우 마이그레이션 속도를 개선시키는 단계가 포함되어 있습니다.
원본의 데이터 배포가 매우 왜곡되어 대부분의 데이터가 하나의 테이블에 있는 경우 마이그레이션을 위해 할당된 컴퓨팅을 완전히 활용해야 하며 이로 인해 병목 현상이 발생합니다. 따라서 큰 테이블을 더 작은 청크로 분할한 다음 병렬로 마이그레이션합니다. 이 기능은 10000000(10M)개 이상의 튜플이 있는 테이블에 적용됩니다. 다음 조건 중 하나가 충족되면 테이블을 더 작은 청크로 분할할 수 있습니다.
테이블에는 단순(복합 아님) 기본 키가 있거나 int 또는 significant int 형식의 고유 인덱스가 있는 열이 포함되어야 합니다.
참고 항목
방식 #2 또는 #3의 경우 사용자는 원본 스키마에 고유 인덱스 열을 추가하는 것의 의미를 신중하게 평가해야 합니다. 고유 인덱스 열을 추가해도 애플리케이션에 영향을 미치지 않는다는 것을 확인한 후에만 사용자가 변경 작업을 진행해야 합니다.
테이블에 int 또는 significant int 형식의 단순 기본 키나 고유 인덱스가 없지만 데이터 형식 기준을 충족하는 열이 있는 경우 아래 명령을 사용하여 해당 열을 고유 인덱스로 변환할 수 있습니다. 이 명령에는 테이블에 대한 잠금이 필요하지 않습니다.
create unique index concurrently partkey_idx on <table name> (column name);테이블에 단순 int/big int 기본 키나 고유 인덱스 또는 데이터 형식 기준을 충족하는 열이 없으면 ALTER를 사용하여 해당 열을 추가하고 마이그레이션 후에 삭제할 수 있습니다. ALTER 명령을 실행하려면 테이블에 대한 잠금이 필요합니다.
alter table <table name> add column <column name> big serial unique;
위 조건 중 하나라도 충족되면 테이블이 여러 파티션으로 병렬로 마이그레이션되므로 마이그레이션 속도가 눈에 띄게 향상됩니다.
작동 방식
- 마이그레이션 서비스는 병렬로 분할 및 마이그레이션해야 하는 테이블의 기본 키/고유 인덱스의 최대 및 최소 정수 값을 조회합니다.
- 최솟값과 최댓값의 차이가 10000000(10M)보다 큰 경우 테이블은 여러 부분으로 분할되고 각 부분은 병렬로 마이그레이션됩니다.
요약하면 PostgreSQL 마이그레이션 서비스는 다음과 같은 경우 병렬 스레드로 테이블을 마이그레이션하고 마이그레이션 시간을 줄입니다.
- 테이블에는 int 또는 significant int 형식의 단순 기본 키나 고유 인덱스가 있는 열이 있습니다.
- 테이블에는 최소 10000000(10M) 행이 있으므로 기본 키의 최솟값과 최댓값의 차이가 10000000(10M) 이상입니다.
- 사용된 SKU에는 테이블을 병렬로 마이그레이션하는 데 사용할 수 있는 유휴 코어가 있습니다.
PostgreSQL 데이터베이스의 진공 블로트
시간이 경과하여 데이터가 추가, 업데이트 및 삭제됨에 따라 PostgreSQL은 데드 행과 낭비되는 스토리지를 누적할 수 있습니다. 이러한 블로트로 인해 스토리지 요구 사항이 증가하고 쿼리 성능이 저하될 수 있습니다. 진공 처리는 낭비되는 공간을 회수하고 데이터베이스가 효율적으로 작동하도록 보장하는 중요한 유지 관리 작업입니다. 진공 처리하면 데드 행 및 테이블 블로트와 같은 문제가 해결되어 스토리지를 효율적으로 사용할 수 있습니다. 더 중요한 것은 마이그레이션 시간이 데이터베이스 크기에 따라 달라지므로 더 빠른 마이그레이션을 보장하는 데 도움이 된다는 것입니다.
PostgreSQL은 데드 행이 차지하는 스토리지를 회수하기 위해 VACUUM 명령을 제공합니다. ANALYZE 옵션은 통계를 수집하여 쿼리 계획을 더욱 최적화합니다. 대용량 쓰기 작업이 있는 테이블의 경우 VACUUM FULL을 사용하면 VACUUM 프로세스가 더 공격적일 수 있지만 실행하는 데 더 많은 시간이 필요합니다.
- 표준 진공
VACUUM your_table;
- 분석을 통한 진공
VACUUM ANALYZE your_table;
- 대용량 쓰기 테이블을 위한 적극적인 진공
VACUUM FULL your_table;
이 예에서는 your_table을 실제 테이블 이름으로 바꿉니다. FULL이 없는 VACUUM 명령은 공간을 효율적으로 회수하는 반면, VACUUM ANALYZE는 쿼리 계획을 최적화합니다. VACUUM FULL 옵션은 성능에 더 큰 영향을 미치므로 신중하게 사용해야 합니다.
일부 데이터베이스는 시간이 지남에 따라 데이터베이스를 블로트시킬 수 있는 이미지나 문서와 같은 대형 개체를 저장합니다. VACUUMLO 명령은 PostgreSQL의 대형 개체용으로 설계되었습니다.
- 진공 대형 개체
VACUUMLO;
이러한 진공 처리 전략을 정기적으로 통합하면 PostgreSQL 데이터베이스가 잘 유지 관리됩니다.
특별 고려 사항
일반적으로 학습자가 자습서이나 모듈을 진행하기 전에 알아야 할 고유한 상황, 구성 또는 필수 조건을 나타내는 특별한 조건이 있습니다. 이러한 조건에는 학습 콘텐츠를 성공적으로 완료하는 데 필요한 특정 소프트웨어 버전, 하드웨어 요구 사항 또는 추가 도구가 포함될 수 있습니다.
온라인 마이그레이션
온라인 마이그레이션은 pgcopydb follow를 활용하며 일부 논리적 디코딩 제한 사항이 적용됩니다. 또한 온라인 마이그레이션을 진행 중인 데이터베이스의 모든 테이블에 기본 키를 두는 것이 좋습니다. 기본 키가 없는 경우 업데이트 또는 삭제를 제외하고 삽입 작업만 마이그레이션 중에 반영될 수 있습니다. 온라인 마이그레이션을 계속하기 전에 관련 테이블에 임시 기본 키를 추가합니다.
대안은 작업이 FULL 옵션과 함께 REPLICA IDENTITY인 ALTER TABLE 명령을 사용하는 것입니다. FULL 옵션은 행에 있는 모든 열의 마이그레이션 값을 기록하므로 기본 키가 없더라도 온라인 마이그레이션 중에 모든 CRUD 작업이 대상에 반영됩니다. 이러한 옵션이 작동하지 않는 경우 대안으로 오프라인 마이그레이션을 수행합니다.
postgres_fdw 확장이 있는 데이터베이스
postgres_fdw 모듈은 외부 PostgreSQL 서버에 저장된 데이터에 액세스하는 데 사용할 수 있는 외부 데이터 래퍼 postgres_fdw를 제공합니다. 데이터베이스에서 이 확장을 사용하는 경우 성공적인 마이그레이션을 위해 다음 단계를 수행해야 합니다.
- 원본 인스턴스에서 외부 데이터 래퍼를 일시적으로 제거(링크 해제)합니다.
- 마이그레이션 서비스를 이용하여 나머지 데이터 마이그레이션을 수행합니다.
- 마이그레이션 후 외부 데이터 래퍼 역할, 사용자 및 링크를 대상으로 복원합니다.
postGIS 확장이 포함된 데이터베이스
Postgis 확장에는 여러 버전 간에 호환성을 손상시키는 변경/압축 문제가 있습니다. 유연한 서버로 마이그레이션하는 경우 최신 postGIS 버전과 비교하여 애플리케이션을 검사하여 애플리케이션이 영향을 받지 않는지 또는 필요한 변경이 이루어져야 하는지 확인해야 합니다. postGIS 뉴스 및 릴리스 정보는 버전별 호환성을 손상시키는 변경을 이해하는 데 좋은 시작점입니다.
데이터베이스 연결 정리
마이그레이션을 시작할 때 다음 오류가 발생하는 경우가 있습니다.
CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.
이 경우 migration user 권한을 부여하여 데이터베이스에 대한 모든 활성 연결을 닫거나 마이그레이션을 다시 시도하기 전에 수동으로 연결을 닫을 수 있습니다.
관련 콘텐츠
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기