Azure Database for PostgreSQL - 단일 서버의 읽기 복제본
적용 대상:
Azure Database for PostgreSQL - 단일 서버
Important
Azure Database for PostgreSQL - 단일 서버는 곧 사용 중지됩니다. Azure Database for PostgreSQL - 유연한 서버로 업그레이드하는 것이 좋습니다. Azure Database for PostgreSQL - 유연한 서버로 마이그레이션하는 방법에 대한 자세한 내용은 Azure Database for PostgreSQL 단일 서버에 대한 새로운 소식을 참조하세요.
읽기 복제본 기능을 사용하면 Azure Database for PostgreSQL 서버에서 읽기 전용 서버로 데이터를 복제할 수 있습니다. 복제본은 PostgreSQL 엔진의 기본 물리적 복제 기술을 사용하여 비동기식으로 업데이트 됩니다. 주 서버에서 최대 5개의 복제본으로 복제할 수 있습니다.
복제본은 일반 Azure Database for PostgreSQL 서버와 비슷한 방식으로 관리하는 새로운 서버입니다. 읽기 복제본의 경우, vCore 및 스토리지에 프로비저닝된 컴퓨팅에 대한 비용이 GB/월 단위로 청구됩니다.
복제본을 만들고 관리하는 방법을 알아봅니다.
읽기 복제본을 사용하는 경우
읽기 복제본 기능은 읽기 작업이 많은 워크로드의 성능과 규모를 향상시키는 데 도움이 됩니다. 읽기 워크로드는 복제본으로 분리할 수 있고 쓰기 워크로드는 주 서버로 보낼 수 있습니다. 또한 읽기 복제본은 다른 지역에 배포할 수 있으며 재해 복구 시 읽기/쓰기 서버로 승격될 수 있습니다.
일반적인 시나리오는 BI와 분석 워크로드가 보고를 위한 데이터 원본으로 읽기 복제본을 사용하도록 합니다.
복제본은 읽기 전용이기 때문에 주 서버에 대한 쓰기 용량 부담을 직접적으로 줄이지는 못합니다.
고려 사항
이 기능은 지연이 허용되는 시나리오를 위한 것이며 쿼리를 오프로딩하기 위한 것입니다. 복제본 데이터가 최신 상태로 유지되는 동기 복제 시나리오를 위한 것은 아닙니다. 주 서버와 복제본 간에는 측정 가능한 지연이 발생합니다. 주 서버와 복제본 간의 대기 시간 및 워크로드에 따라 몇 분 또는 몇 시간까지도 걸릴 수 있습니다. 복제본의 데이터는 결과적으로 주 서버의 데이터와 일치하게 됩니다. 이러한 지연 시간을 수용할 수 있는 워크로드에 이 기능을 사용합니다.
참고 항목
대부분의 워크로드에서 읽기 복제본은 주 서버에서 거의 실시간 업데이트를 제공합니다. 하지만 지속적인 쓰기 집약적 주 워크로드의 경우 복제 지연이 계속 증가할 수 있으며 주 서버의 속도를 따라잡지 못할 수도 있습니다. WAL 파일은 복제본에서 수신될 때까지 삭제되지 않기 때문에 주 서버에서 스토리지 사용량이 증가할 수도 있습니다. 이 상황이 지속되는 경우 쓰기 집약적인 워크로드가 완료된 후 읽기 복제본을 삭제하고 다시 만드는 것이 지연과 관련하여 복제본을 양호한 상태로 되돌릴 수 있는 옵션입니다. 비동기식 읽기 복제본은 이러한 쓰기가 많은 워크로드에는 적합하지 않습니다. 애플리케이션에 대한 읽기 복제본을 평가할 때 워크로드 주기의 다양한 지점에서 가능한 지연 및 예상 RTO/RPO에 액세스할 수 있도록 사용량이 많은 시간과 사용량이 많지 않은 시간에서 전체 앱 워크로드 주기에 대한 복제본의 지연 시간을 모니터링합니다.
참고 항목
최대 4TB의 저장소 구성으로 구성된 복제본 서버에 대해 자동 백업이 수행됩니다.
지역 간 복제
주 서버와는 다른 지역에 읽기 복제본을 만들 수 있습니다. 지역 간 복제는 재해 복구 계획 또는 사용자에게 더 가까운 데이터 가져오기 등의 시나리오에 유용할 수 있습니다.
참고 항목
기본 계층 서버는 동일한 지역 복제만 지원합니다.
Azure Database for PostgreSQL 지역에 주 서버를 둘 수 있습니다. 주 서버는 쌍을 이루는 지역 또는 유니버설 복제본 지역에 복제본이 있을 수 있습니다. 아래 그림은 주 지역에 따라 사용할 수 있는 복제본 지역을 보여 줍니다.
유니버설 복제본 지역
주 서버가 있는 위치에 관계 없이 다음 지역에서 항상 읽기 복제본을 만들 수 있습니다. 다음은 유니버설 복제본 지역입니다.
오스트레일리아 동부, 오스트레일리아 남동부, 브라질 남부, 캐나다 중부, 캐나다 동부, 미국 중부, 동아시아, 미국 동부, 미국 동부 2, 일본 동부, 일본 서부, 한국 중부, 한국 남부, 미국 중북부, 북유럽, 미국 중남부, 동남 아시아, 영국 남부, 영국 서부, 서유럽, 미국 서부, 미국 서부2, 미국 중서부
쌍을 이루는 지역
유니버설 복제본 지역 외에도 주 서버의 Azure 쌍을 이루는 지역에서 읽기 복제본을 만들 수 있습니다. 해당 지역의 쌍을 모르는 경우 Azure 쌍을 이루는 지역 문서에서 자세히 알아볼 수 있습니다.
재해 복구 계획에 지역 간 복제본을 사용하는 경우 다른 지역 중 하나가 아닌 쌍을 이루는 지역에 복제본을 만드는 것이 좋습니다. 쌍을 이루는 지역은 동시 업데이트를 방지하고 물리적 격리 및 데이터 보존의 우선 순위를 지정합니다.
고려해야 할 제한 사항이 있습니다.
- 단방향 쌍: 일부 Azure 지역은 한 방향으로만 쌍으로 연결됩니다. 이러한 지역에는 인도 서부, 브라질 남부가 포함됩니다. 즉, 인도 서부의 주 서버는 인도 남부에서 복제본을 만들 수 있습니다. 그러나 인도 남부의 주 서버는 인도 서부에서 복제본을 만들 수 없습니다. 이는 인도 서부의 보조 지역은 인도 남부이지만 인도 남부의 보조 지역은 인도 서부가 아니기 때문입니다.
복제본 만들기
복제본 만들기 워크플로를 시작하면 빈 Azure Database for PostgreSQL 서버가 만들어집니다. 새 서버는 주 서버에 있는 데이터로 채워집니다. 생성 시간은 주 서버의 데이터 양과 지난 주 전체 백업 이후의 시간에 따라 달라집니다. 시간은 몇 분에서 몇 시간까지 걸릴 수 있습니다.
모든 복제본은 스토리지 자동 증가에 대해 사용하도록 설정됩니다. 자동 증가 기능을 사용하면 복제본에 복제된 데이터를 유지하고 스토리지 부족 오류로 인한 복제 중단을 방지할 수 있습니다.
읽기 복제본 기능은 PostgreSQL의 물리적 복제(논리 복제 아님)를 사용합니다. 복제 슬롯을 사용하는 스트리밍 복제가 기본 작동 모드입니다. 필요한 경우 따라잡기 위해 로그 전달이 사용됩니다.
Azure Portal에서 읽기 복제본을 만드는 방법을 알아봅니다.
원본 PostgreSQL 서버가 고객 관리형 키로 암호화된 경우 설명서에서 추가로 고려해야 할 사항을 참조하세요.
복제본에 연결
복제본을 만들면 주 서버의 방화벽 규칙 또는 VNet 서비스 엔드포인트를 상속하지 않습니다. 이러한 규칙은 복제본에 대해 별도로 설정해야 합니다.
복제본은 주 서버에서 해당 관리자 계정을 상속합니다. 주 서버의 모든 사용자 계정은 읽기 복제본으로 복제됩니다. 주 서버에서 사용 가능한 사용자 계정을 사용해야만 읽기 복제본에 연결할 수 있습니다.
일반 Azure Database for PostgreSQL 서버에서처럼 같이 해당 호스트 이름 및 유효한 사용자 계정을 사용하여 복제본에 연결할 수 있습니다. 관리 사용자 이름이 myadmin이고 서버의 이름이 my replica인 경우 다음과 같이 psql을 사용하여 복제본에 연결할 수 있습니다.
psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres
프롬프트가 표시되면 사용자 계정의 암호를 입력합니다.
복제 모니터링
Azure Database for PostgreSQL은 복제를 모니터링하기 위한 두 가지 메트릭을 제공합니다. 두 메트릭은 복제본 간 최대 지연 시간 및 복제본 지연 시간입니다. 이러한 메트릭을 보는 방법에 대한 자세한 내용은 읽기 복제본 방법 문서의 복제본 모니터링 섹션을 참조하세요.
복제본 간 최대 지연 시간 메트릭은 주 서버와 가장 오래 지연된 복제본 간의 지연 시간을 바이트 단위로 보여줍니다. 이 메트릭은 주 서버에서만 적용 및 사용할 수 있으며, 하나 이상의 읽기 복제본이 주 서버에 연결되고 주 서버가 스트리밍 복제 모드에 있는 경우에만 사용할 수 있습니다. 복제본이 주 서버에 보관된 로그를 사용하여 파일 발송 복제 모드에서 주 서버를 따라잡는 과정인 경우 지연 정보의 세부 정보가 표시되지 않습니다.
복제본 지연 시간 메트릭은 마지막으로 재생된 트랜잭션 이후의 시간을 보여 줍니다. 주 서버에서 트랜잭션이 발생하지 않으면 메트릭은 이 지연 시간을 반영합니다. 이 메트릭은 복제본 서버에만 적용 가능하고 사용할 수 있습니다. 복제본 지연 시간은 pg_stat_wal_receiver 보기에서 계산됩니다.
SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());
복제본 지연 시간이 워크로드에 적합하지 않은 값에 도달하면 알리도록 경고를 설정하십시오.
추가 인사이트를 얻으려면 주 서버를 직접 쿼리하여 모든 복제본의 복제 지연 시간(바이트)을 가져옵니다.
참고 항목
주 서버 또는 읽기 복제본이 다시 시작되면 다시 시작하여 따라잡는 데 걸리는 시간이 복제본 지연 시간 메트릭에 반영됩니다.
복제 중지/복제본 수준 올리기
언제든지 주 서버와 복제본 간의 복제를 중지할 수 있습니다. 중지 작업을 수행하면 복제본이 다시 시작되고 독립적인 독립 실행형 읽기-쓰기 가능 서버로 복제본이 승격됩니다. 독립 실행형 서버의 데이터는 복제가 중지될 때 복제본 서버에서 사용할 수 있던 데이터입니다. 주 서버의 모든 후속 업데이트는 복제본으로 전파되지 않습니다. 그러나 복제본 서버에는 아직 적용되지 않은 로그가 누적되었을 수 있습니다. 다시 시작 프로세스의 일부로 복제본은 클라이언트 연결을 허용하기 전에 보류 중인 모든 로그를 적용합니다.
참고 항목
복제본 서버에서 관리자 암호 재설정은 현재 지원되지 않습니다. 또한 동일한 요청에서 복제본 승격 작업과 함께 관리자 암호를 업데이트하는 것도 지원되지 않습니다. 이렇게 하려면 먼저 복제본 서버를 승격한 다음, 새로 승격된 서버에서 암호를 별도로 업데이트해야 합니다.
고려 사항
- 읽기 복제본에서 복제를 중지하기 전에 복제 로그를 확인하여 복제본에 필요한 모든 데이터가 있는지 확인하세요.
- 읽기 복제본이 독립 실행형 서버로 설정되기 전에 보류 중인 모든 로그를 적용해야 하는 경우 복제본에 상당한 지연이 있을 수 있으므로 복제가 중지될 때 쓰기 작업이 많은 워크로드에 대해 RTO가 더 높을 수 있습니다. 복제본을 승격할 계획인 경우 이에 주의하세요.
- 승격된 복제본 서버를 다시 복제본으로 설정할 수는 없습니다.
- 복제본을 주 서버로 승격하는 경우 복제를 이전 주 서버로 다시 설정할 수 없습니다. 이전 주 지역으로 돌아가려면 새 복제본 서버를 새 이름으로 설정하거나 이전 주 복제본을 삭제하고 이전 주 이름을 사용하여 복제본을 만듭니다.
- 여러 개의 읽기 복제본이 있고 그 중 하나를 주 서버로 승격하려는 경우 다른 복제본 서버는 여전히 이전 주 서버에 연결되어 있습니다. 새로 승격된 서버에서 복제본을 다시 만들어야 할 수 있습니다.
복제를 중지하면 복제본은 이전 서버와 다른 복제본에 대한 모든 링크를 잃게 됩니다.
복제본에 대한 복제를 중지하는 방법을 알아봅니다.
복제본으로 장애 조치(failover)
주 서버 오류가 발생하는 경우 해당 서버는 읽기 복제본으로 자동 장애 조치(failover)되지 않습니다.
복제는 비동기이므로 주 서버와 복제본 사이에는 상당한 지연이 있을 수 있습니다. 지연 시간은 주 서버에서 실행되는 워크로드의 유형, 주 서버와 복제 서버 사이의 대기 시간 등과 같은 여러 가지 요소에 의해 영향을 받습니다. 보통 명목상 쓰기 워크로드인 경우 몇 초에서 몇 분 사이의 복제본 지연이 예상됩니다. 그러나 주 서버에서 매우 많은 양의 쓰기 집약적인 워크로드를 실행하고 복제본이 충분히 빠르게 포착되지 않는 경우에는 지연 시간이 훨씬 더 길 수 있습니다. 복제본 지연 시간 메트릭을 사용하여 각 복제본에 대한 복제 지연 시간을 추적할 수 있습니다. 이 메트릭은 복제본에서 마지막으로 재생된 트랜잭션 이후의 시간을 보여 줍니다. 일정 기간 동안 복제본 지연 시간을 관찰하여 평균 지연을 확인하는 것이 좋습니다. 복제본 지연 시간에 대한 경고를 설정하여 예상 범위를 벗어나면 조치를 취하도록 알릴 수 있습니다.
팁
복제본으로 장애 조치(failover)하는 경우 복제본이 주 서버에서 분리될 때 발생하는 지연 시간이 손실된 데이터의 양을 나타냅니다.
복제본으로 장애 조치(failover)하기로 결정했으면 다음을 수행합니다.
복제본에 대한 복제를 중지합니다.
이 단계는 복제본 서버를 독립 실행형 서버로 만들고 쓰기를 허용하도록 하는 데 필요합니다. 이 프로세스의 일부로 복제본 서버가 다시 시작되고 주 서버에서 분리됩니다. 복제 중지를 시작하면 백엔드 프로세스가 일반적으로 아직 적용되지 않은 나머지 로그를 적용하고 읽기-쓰기 가능한 서버로 데이터베이스를 여는 데 몇 분 정도 걸립니다. 이 작업의 의미를 이해하려면 이 문서의 복제 중지 섹션을 참조하세요.애플리케이션이 (이전) 복제본을 가리키도록 합니다.
각 서버에는 고유한 연결 문자열이 있습니다. 주 서버 대신 (이전) 복제본을 가리키도록 애플리케이션 연결 문자열을 업데이트합니다.
애플리케이션이 읽기 및 쓰기를 성공적으로 처리하면 장애 조치(failover)를 완료한 것입니다. 응용 프로그램의 가동 중지 시간은 문제를 감지하고 위의 1단계와 2단계를 완료하는 시기에 따라 달라집니다.
재해 복구
가용성 영역 수준 또는 지역 오류와 같은 주요 재해 이벤트가 발생하는 경우 읽기 복제본을 승격시켜 재해 복구 작업을 수행할 수 있습니다. UI 포털에서 읽기 복제본 서버로 이동할 수 있습니다. 그런 다음 복제 탭을 선택하고 복제본을 중지하여 독립 서버로 승격할 수 있습니다. 또는 Azure CLI를 사용하여 복제본 서버를 중지하고 승격시킬 수 있습니다.
고려 사항
이 섹션에서는 읽기 복제본 기능의 고려 사항에 대한 요약이 제공됩니다.
필수 조건
읽기 복제본과 논리 디코딩은 모두 정보에 대한 Postgres WAL(Write Ahead Log)에 따라 달라집니다. 이러한 두 기능에는 Postgres의 다른 로깅 수준이 필요합니다. 논리 디코딩에는 읽기 복제본보다 높은 수준의 로깅이 필요합니다.
올바른 로깅 수준을 구성하려면 Azure 복제 지원 매개 변수를 사용하세요. Azure 복제 지원에는 다음 세 가지 설정 옵션이 있습니다.
- 해제 - WAL에 최소 정보를 저장합니다. 이 설정은 대부분의 Azure Database for PostgreSQL 서버에서 사용할 수 없습니다.
- 복제본 - 해제보다 자세한 정보를 표시합니다. 이는 읽기 복제본이 작동하는 데 필요한 최소 로깅 수준입니다. 이 설정은 대부분의 서버에서 기본값입니다.
- 논리 - 복제본보다 자세한 정보를 표시합니다. 논리 디코딩이 작동하기 위한 최소 로깅 수준입니다. 읽기 복제본도 이 설정에서 작동합니다.
새 복제본
읽기 복제본은 새로운 Azure Database for PostgreSQL 서버로 생성됩니다. 기존 서버를 복제본으로 만들 수 없습니다. 다른 읽기 복제본의 복제본은 만들 수 없습니다.
복제본 구성
복제본은 주 서버와 동일한 컴퓨팅 및 스토리지 설정을 사용하여 생성됩니다. 복제본을 만든 후 스토리지 및 백업 보존 기간을 포함하여 여러 가지 설정을 변경할 수 있습니다.
복제본을 만들 때나 그 후에 방화벽 규칙, 가상 네트워크 규칙 및 매개 변수 설정은 주 서버에서 복제본으로 상속되지 않습니다.
확장
vCore 간 또는 범용 및 메모리 최적화 간 크기 조정:
- PostgreSQL을 사용하려면 보조 서버의
max_connections설정이 주 서버의 설정보다 크거나 같아야 합니다. 그렇지 않으면 보조 서버가 시작되지 않습니다. - Azure Database for PostgreSQL에서는 연결이 메모리를 점유하므로 각 서버에 허용되는 최대 연결이 컴퓨팅 SKU로 고정됩니다. max_connections와 컴퓨팅 SKU 간의 매핑에 대해 자세히 알아볼 수 있습니다.
- 스케일 업: 먼저 복제본의 컴퓨팅을 스케일 업한 다음, 주 서버를 스케일 업합니다. 이 순서를 적용하면
max_connections요구 사항 위반에 따른 오류가 발생하지 않습니다. - 스케일 다운: 먼저 주 서버의 컴퓨팅을 스케일 다운한 다음, 복제본을 스케일 다운합니다. 복제본의 크기를 주 서버보다 작게 조정하려고 하면
max_connections요구 사항을 위반하므로 오류가 발생합니다.
스토리지 크기 조정:
- 모든 복제본은 스토리지 전체 복제본에서 복제 문제를 방지하기 위해 스토리지 자동 증가를 사용하도록 설정됩니다. 이 설정은 사용하지 않도록 지정할 수 없습니다.
- 다른 서버에서와 마찬가지로 스토리지를 수동으로 스케일 업할 수도 있습니다.
기본 계층
기본 계층 서버는 동일한 지역 복제만 지원합니다.
max_prepared_transactions
PostgreSQL에서는 읽기 복제본의 max_prepared_transactions 매개 변수 값이 주 서버 값보다 크거나 같아야 합니다. 그렇지 않으면 해당 복제본이 시작되지 않습니다. 주 서버에서 max_prepared_transactions을 변경하려면 먼저 복제본에서 해당 매개 변수를 변경합니다.
중지된 복제본
주 서버와 읽기 복제본 간의 복제를 중지하면 복제본이 다시 시작되어 변경 내용이 적용됩니다. 중지된 복제본은 읽기와 쓰기를 모두 허용하는 독립 실행형 서버가 됩니다. 독립 실행형 서버를 다시 복제본으로 만들 수 없습니다.
삭제된 주 서버 및 독립 실행형 서버
주 서버를 삭제하면 이 서버의 모든 읽기 복제본이 독립 실행형 서버가 됩니다. 이 변경 내용을 반영하기 위해 복제본이 다시 시작됩니다.