Azure Database for PostgreSQL - 유연한 서버의 읽기 복제본

적용 대상: Azure Database for PostgreSQL - 유연한 서버

읽기 복제본 기능을 사용하면 Azure Database for PostgreSQL 유연한 서버 인스턴스에서 읽기 전용 복제본으로 데이터를 복제할 수 있습니다. 복제본은 PostgreSQL 엔진의 기본 물리적 복제 기술을 사용하여 비동기식으로 업데이트됩니다. 복제 슬롯을 사용하는 스트리밍 복제가 기본 작동 모드입니다. 필요한 경우 파일 기반 로그 전달을 사용하여 이를 따라잡습니다. 주 서버에서 최대 5개의 복제본으로 복제할 수 있습니다.

복제본은 일반 Azure Database for PostgreSQL 유연한 서버 인스턴스와 유사하게 관리하는 새 서버입니다. 읽기 복제본의 경우, vCore 및 스토리지에 프로비저닝된 컴퓨팅에 대한 비용이 GB/월 단위로 청구됩니다.

복제본을 만들고 관리하는 방법을 알아봅니다.

읽기 복제본을 사용하는 경우

읽기 복제본 기능은 읽기 작업이 많은 워크로드의 성능과 규모를 향상시키는 데 도움이 됩니다. 읽기 워크로드는 복제본으로 분리할 수 있고 쓰기 워크로드는 주 서버로 보낼 수 있습니다. 읽기 복제본은 다른 지역에 배포할 수도 있으며 재해 복구가 필요한 경우 읽기-쓰기 서버로 승격할 수 있습니다.

일반적인 시나리오는 BI와 분석 워크로드가 보고를 위한 데이터 원본으로 읽기 복제본을 사용하도록 합니다.

복제본은 읽기 전용이기 때문에 주 서버에 대한 쓰기 용량 부담을 직접적으로 줄이지는 못합니다.

고려 사항

읽기 복제본은 주로 쿼리를 오프로드하는 것이 유리하고 약간의 지연을 관리할 수 있는 시나리오를 위해 설계되었습니다. 대부분의 워크로드에 대해 주 데이터베이스에서 거의 실시간으로 업데이트를 제공하도록 최적화되어 읽기가 많은 시나리오에 적합한 솔루션입니다. 그러나 최신 데이터 정확도가 필요한 동기식 복제 시나리오에는 해당되지 않는다는 점에 유의해야 합니다. 복제본의 데이터는 결국 주 복제본과 일치하게 되지만, 일반적으로 몇 초에서 몇 분까지의 데이터 지연이 발생할 수 있으며, 워크로드가 많거나 대기 시간이 긴 시나리오에서는 이 지연이 몇 시간까지 연장될 수 있습니다. 일반적으로 주 복제본과 동일한 지역의 읽기 복제본은 지리적 거리 때문에 발생한 대기 시간을 처리하는 경우가 많으므로 지역 복제본보다 지연 시간이 적습니다. 지역 복제의 성능에 미치는 영향에 대한 자세한 내용은 지역 복제 문서를 참조하세요. 복제본의 데이터는 결과적으로 주 서버의 데이터와 일치하게 됩니다. 이러한 지연 시간을 수용할 수 있는 워크로드에 이 기능을 사용합니다.

참고 항목

대부분의 워크로드에서 읽기 전용 복제본은 기본에서 거의 실시간 업데이트를 제공합니다. 하지만 쓰기 집약적 주 워크로드가 지속적으로 많은 경우 복제 지연이 계속 증가할 수 있으며 주 워크로드의 속도만 따라잡을 수도 있습니다. 또한 WAL 파일이 복제본에서 수신된 후에만 삭제되기 때문에 주 복제본에서 스토리지 사용량이 증가할 수 있습니다. 이 상황이 지속되는 경우 쓰기 집약적인 워크로드가 완료된 후 읽기 복제본을 삭제하고 다시 만들면 지연 없이 복제본을 양호한 상태로 되돌릴 수 있는 옵션입니다. 비동기식 읽기 복제본은 이러한 쓰기가 많은 워크로드에는 적합하지 않습니다. 애플리케이션에 대한 읽기 복제본을 평가할 때 가능한 지연 및 예상 RTO/RPO를 평가하도록 사용량이 많은 시간 및 사용량이 많지 않은 시간을 통해 전체 앱 워크로드 주기에 대한 복제본의 지연 시간을 모니터링합니다.

복제본 만들기

Azure Database for PostgreSQL 유연한 서버의 주 서버는 서비스를 지원하는 모든 지역에 배포할 수 있습니다. 동일한 지역 내에서 또는 Azure Database for PostgreSQL 유연한 서버를 사용할 수 있는 다양한 글로벌 Azure 지역에 걸쳐 주 서버의 복제본을 만들 수 있습니다. 복제본을 만드는 기능은 이제 일부 특수 Azure 지역으로 확장됩니다. 복제본을 만들 수 있는 특수 지역 목록은 지역에서 복제 문서를 참조하세요.

복제본 만들기 워크플로를 시작하면 빈 Azure Database for PostgreSQL 유연한 서버 인스턴스가 만들어집니다. 새 서버는 주 서버에 있는 데이터로 채워집니다. 동일한 지역에서 복제본을 만들기 위해 스냅샷 접근 방식이 사용됩니다. 따라서 생성 시간은 데이터 크기와 무관합니다. 지역 복제본은 주 인스턴스의 기준 백업을 사용하여 만들어진 다음 네트워크를 통해 전송되므로 만들기 시간은 기본 크기에 따라 몇 분에서 몇 시간까지 다양할 수 있습니다.

복제본은 주 인스턴스의 전체 백업을 복제본에 복사해야 하고 트랜잭션 로그가 1GB 이하의 지연 시간으로 동기화되어야 한다는 두 가지 조건이 충족되는 경우에만 성공적으로 생성된 것으로 간주됩니다.

성공적인 만들기 작업을 수행하려면 트랜잭션 부하가 많은 시간에 복제본을 만들지 마세요. 예를 들어 다른 원본에서 Azure Database for PostgreSQL 유연한 서버로 마이그레이션하거나 대량 부하가 많은 작업 중에 복제본을 만들지 않아야 합니다. 지금 데이터를 마이그레이션하거나 많은 양의 데이터를 로드하는 경우 이 작업을 먼저 완료하는 것이 가장 좋습니다. 완료되면 복제본 설정을 시작할 수 있습니다. 마이그레이션 또는 대량 로드 작업이 완료되면 트랜잭션 로그 크기가 정상 크기로 반환되었는지 확인합니다. 일반적으로 트랜잭션 로그 크기는 인스턴스의 max_wal_size 서버 매개 변수에 정의된 값에 가까워야 합니다. 트랜잭션 로그에서 사용하는 스토리지 양에 대한 인사이트를 제공하는 사용되는 트랜잭션 로그 스토리지 메트릭을 사용하여 트랜잭션 로그 스토리지 공간을 추적할 수 있습니다. 이 메트릭을 모니터링하여 트랜잭션 로그 크기가 예상 범위 내에 있고 복제본 만들기 프로세스가 시작될 수 있는지 확인할 수 있습니다.

Important

읽기 복제본은 현재 범용 및 메모리 최적화 서버 컴퓨팅 계층에 대해 지원됩니다. 버스트 가능 서버 컴퓨팅 계층은 지원되지 않습니다.

Important

복제본 만들기, 삭제, 승격 작업을 수행할 때 주 서버는 업데이트 상태가 됩니다. 이 시간 동안 서버 매개 변수 수정, 고가용성 옵션 변경, 방화벽 추가, 방화벽 제거와 같은 서버 관리 작업을 수행할 수 없습니다. 업데이트 상태는 서버 관리 작업에만 영향을 주며 데이터 평면 작업에는 영향을 주지 않습니다. 즉, 데이터베이스 서버가 완벽하게 작동하고 연결을 수락할 수 있을 뿐만 아니라 읽기 및 쓰기 트래픽을 처리할 수 있습니다.

Azure Portal에서 읽기 복제본을 만드는 방법을 알아봅니다.

구성 관리

Azure Database for PostgreSQL 유연한 서버에 대한 읽기 복제본을 설정할 때는 조정할 수 있는 서버 구성, 주 서버에서 상속된 서버 구성, 관련 제한 사항을 이해해야 합니다.

상속된 구성

읽기 복제본이 만들어지면 주 서버에서 특정 서버 구성을 상속합니다. 이러한 구성은 복제본을 만드는 동안 또는 설정된 후에 변경할 수 있습니다. 그러나 지역 백업과 같은 특정 설정은 읽기 복제본에 복제되지 않습니다.

복제본을 만드는 동안 구성

• 계층, 스토리지 크기: ‘주 서버로 승격’ 작업의 경우 주 서버와 동일해야 합니다. ‘독립 서버로 승격하고 복제에서 제거’ 작업의 경우 주 서버보다 같거나 높을 수 있습니다.
• 성능 계층(IOPS): 조정 가능합니다.
• 데이터 암호화: 서비스 관리형 키에서 고객 관리형 키로의 이동을 포함하여 조정 가능합니다.

생성 후 구성

• 방화벽 규칙: 추가, 삭제, 수정할 수 있습니다.
• 계층, 스토리지 크기: ‘주 서버로 승격’ 작업의 경우 주 서버와 동일해야 합니다. ‘독립 서버로 승격하고 복제에서 제거’ 작업의 경우 주 서버보다 같거나 높을 수 있습니다.
• 성능 계층(IOPS): 조정 가능합니다.
• 인증 방법: 조정 가능합니다. 옵션에는 PostgreSQL 인증에서 Microsoft Entra로의 전환이 포함됩니다.
• 서버 매개 변수: 대부분은 조정할 수 있습니다. 그러나 공유 메모리 크기에 영향을 주는 항목은 특히 잠재적인 ‘주 서버로 승격’ 시나리오의 경우 주 서버와 일치해야 합니다. ‘독립 서버로 승격하고 복제에서 제거’ 작업의 경우 이러한 매개 변수는 주 서버의 매개 변수와 동일하거나 그 이상이어야 합니다.
• 유지 관리 일정: 조정 가능합니다.

읽기 복제본에서 지원되지 않는 기능

특정 기능은 주 서버로 제한되며 읽기 복제본에서 설정할 수 없습니다. 여기에는 다음이 포함됩니다.

• 지역 백업을 포함한 백업.
• HA(고가용성)

원본 Azure Database for PostgreSQL 유연한 서버 인스턴스가 고객 관리형 키로 암호화된 경우 다른 고려 사항에 대한 설명서를 참조하세요.

복제본에 연결

복제본을 만들면 주 서버의 방화벽 규칙 또는 가상 네트워크 서비스 엔드포인트를 상속합니다. 이러한 규칙은 복제본을 만드는 동안이나 생성 이후에 변경될 수 있습니다.

복제본은 주 서버에서 해당 관리자 계정을 상속합니다. 주 서버의 모든 사용자 계정은 읽기 복제본으로 복제됩니다. 주 서버에서 사용 가능한 사용자 계정을 사용해야만 읽기 복제본에 연결할 수 있습니다.

복제본에 연결하는 방법에는 다음 두 가지가 있습니다.

• 복제본 인스턴스로 직접 연결: 일반 Azure Database for PostgreSQL 유연한 서버 인스턴스에서와 마찬가지로 호스트 이름 및 유효한 사용자 계정을 사용하여 복제본에 연결할 수 있습니다. 관리 사용자 이름이 myadmin인 myreplica라는 이름의 서버의 경우 psql를 사용하여 복제본에 연결할 수 있습니다.

psql -h myreplica.postgres.database.azure.com -U myadmin postgres

프롬프트가 표시되면 사용자 계정의 암호를 입력합니다.

또한 연결 프로세스를 간소화하기 위해 Azure Portal에서 즉시 사용할 수 있는 연결 문자열을 제공합니다. 연결 페이지에서 찾을 수 있습니다. 두 libpq 변수와 Bash 콘솔에 맞게 조정된 연결 문자열을 모두 포함합니다.

• 가상 엔드포인트를 통해: 가상 엔드포인트 섹션에 설명된 대로 가상 엔드포인트를 사용하는 대체 연결 방법이 있습니다. 가상 엔드포인트를 사용하면 현재 어떤 서버가 복제본 역할을 맡고 있는지에 관계없이 복제본을 일관되게 가리키도록 읽기 전용 엔드포인트를 구성할 수 있습니다.

복제 모니터링

Azure Database for PostgreSQL 유연한 서버의 읽기 복제본 기능은 복제 슬롯 메커니즘을 사용합니다. 복제 슬롯의 가장 큰 장점은 모든 복제 서버에 필요한 트랜잭션 로그(WAL 세그먼트)의 수를 자동으로 조정한다는 것입니다. 이렇게 하면 복제본으로 전송되기 전에 주 복제본에서 WAL 세그먼트가 삭제되는 것을 방지할 수 있으므로 복제본이 동기화되지 않는 것을 방지할 수 있습니다. 이 접근 방식의 단점은 복제 슬롯이 장기간 비활성 상태로 유지되는 경우 주 데이터베이스의 공간이 부족해질 위험이 있다는 것입니다. 이러한 상황에서 주 데이터베이스는 스토리지 사용량의 증분 증가를 일으키는 WAL 파일을 축적합니다. 스토리지 사용량이 95%에 도달하거나 사용 가능한 용량이 5GiB 미만인 경우 디스크가 가득 찬 상황과 관련된 오류를 방지하기 위해 서버가 자동으로 읽기 전용 모드로 전환됩니다.
따라서 복제 지연 및 복제 슬롯 상태를 모니터링하는 것은 읽기 복제본에 매우 중요합니다.

사전에 조치를 취하고, 스토리지 크기를 늘리고, 지연된 읽기 복제본을 삭제할 수 있도록 특정 임계값을 초과하는 경우 복제 지연뿐만 아니라 사용된 스토리지 또는 스토리지 비율에 대한 경고 규칙을 설정하는 것이 좋습니다. 예를 들어 스토리지 비율이 사용량의 80%를 초과하거나 복제본 지연 시간이 5분보다 길 경우 경고를 설정할 수 있습니다. 사용된 트랜잭션 로그 스토리지 메트릭은 WAL 파일 누적이 과도한 스토리지 사용의 주요 원인인지를 여부를 보여 줍니다.

Azure Database for PostgreSQL 유연한 서버는 복제 모니터링을 위한 두 가지 메트릭을 제공합니다. 두 가지 메트릭은 최대 물리적 복제 지연 및 읽기 복제본 지연입니다. 이러한 메트릭을 보는 방법에 대한 자세한 내용은 읽기 복제본 방법 문서의 복제본 모니터링 섹션을 참조하세요.

최대 물리적 복제 지연 메트릭은 주 서버와 가장 오래 지연된 복제본 간의 지연 시간을 바이트 단위로 보여 줍니다. 이 메트릭은 주 서버에서만 적용하여 사용할 수 있으며 최소 하나 이상의 읽기 복제본이 주 서버에 연결된 경우에만 사용할 수 있습니다. 지연 정보는 복제본이 주 서버를 따라잡는 중일 때, 복제본을 만드는 동안 또는 복제가 비활성화 될 때에도 나타납니다.

읽기 복제본 지연 메트릭은 마지막으로 재생된 트랜잭션 이후의 시간을 보여 줍니다. 예를 들어 주 서버에서 트랜잭션이 발생하지 않고 마지막 트랜잭션이 5초 전에 재생된 경우 읽기 복제본 지연이 5초 지연을 보여 줍니다. 이 메트릭은 복제본에만 적용 가능하고 사용할 수 있습니다.

복제본 지연 시간이 워크로드에 적합하지 않은 값에 도달하면 알리도록 경고를 설정하세요.

더 많은 인사이트를 얻으려면 주 서버를 직접 쿼리하여 모든 복제본의 복제 지연을 가져옵니다.

참고 항목

주 서버 또는 읽기 복제본이 다시 시작되면 다시 시작하여 따라잡는 데 걸리는 시간이 복제본 지연 시간 메트릭에 반영됩니다.

복제 상태

복제 및 승격 작업의 진행률 및 상태를 모니터링하려면 Azure Portal의 복제 상태 열을 참조하세요. 이 열은 복제 페이지에 있으며 읽기 복제본의 현재 상태와 주 복제본에 대한 링크에 대한 인사이트를 제공하는 다양한 상태를 표시합니다. Azure Resource Manager API를 사용하는 사용자의 경우 GetReplica API를 호출할 때 상태는 replica 속성 모음에 ReplicationState로 표시됩니다.

가능한 값은 다음과 같습니다.

복제 상태	설명	승격 순서	복제본 만들기 순서 읽기
다시 구성	복제본-주 링크의 시작을 기다리고 있습니다. 예를 들어 재해로 인해 복제본 또는 해당 지역을 사용할 수 없는 경우 더 오래 유지될 수 있습니다.	1	해당 없음
프로비전	읽기 복제본이 프로비전되고 있으며 두 서버 간의 복제가 아직 시작되지 않았습니다. 프로비전이 완료될 때까지 읽기 복제본에 연결할 수 없습니다.	해당 없음	1
업데이트 중	승격 또는 읽기 복제본 만들기와 같은 트리거된 작업에 따라 서버 구성이 준비 중입니다.	2	2
Catchup	WAL 파일이 복제본에 적용되고 있습니다. 승격 중에 이 단계의 기간은 선택한 데이터 동기화 옵션(계획 또는 강제)에 따라 달라집니다.	3	3
활성	읽기 복제본이 주 복제본에 성공적으로 연결되었음을 나타내는 정상 상태입니다. 서버가 중지되었지만 이전에 성공적으로 연결된 경우 상태는 활성 상태로 유지됩니다.	4	4
끊어짐	승격 작업이 실패했거나 복제본이 어떤 이유로 인해 주 복제본에 연결할 수 없음을 나타내는 비정상 상태입니다. 이 문제를 해결하려면 복제본을 삭제하고 복제본을 다시 만듭니다."	해당 없음	해당 없음

복제를 모니터링하는 방법을 알아봅니다.

고려 사항

이 섹션에서는 읽기 복제본 기능의 고려 사항에 대한 요약이 제공됩니다. 고려 사항은 다음과 같습니다.

• 전원 작업: 시작 및 중지 작업을 포함한 전원 작업은 주 서버와 해당 복제본 서버 모두에 적용될 수 있습니다. 그러나 시스템 무결성을 유지하려면 특정 시퀀스를 따라야 합니다. 읽기 복제본을 중지하기 전에 주 서버가 먼저 중지되었는지 확인합니다. 작업을 시작할 때 주 서버를 시작하기 전에 복제본 서버에서 시작 작업을 시작합니다.
• 서버에 읽기 복제본이 있는 경우 주 서버를 삭제하기 전에 먼저 읽기 복제본을 삭제해야 합니다.
• Azure Database for PostgreSQL 유연한 서버의 주 버전 현재 위치 업그레이드를 사용하려면 서버에서 현재 사용할 수 있는 읽기 복제본을 모두 제거해야 합니다. 복제본이 삭제되면 주 서버를 원하는 주 버전으로 업그레이드할 수 있습니다. 업그레이드가 완료되면 복제본을 다시 만들어 복제 프로세스를 다시 시작할 수 있습니다.
• 프리미엄 SSD v2: 현재 릴리스 기준으로 주 서버가 스토리지에 프리미엄 SSD v2를 사용하는 경우 읽기 복제본 만들기가 지원되지 않습니다.
• 관리자 암호 재설정: 복제본 서버에서 관리자 암호 재설정은 현재 지원되지 않습니다. 또한 동일한 요청에서 복제본 승격 작업과 함께 관리자 암호를 업데이트하는 것도 지원되지 않습니다. 이렇게 하려면 먼저 복제본 서버를 승격한 다음, 새로 승격된 서버에서 암호를 별도로 업데이트해야 합니다.

새 복제본

읽기 복제본은 새로운 Azure Database for PostgreSQL 유연한 서버로 생성됩니다. 기존 서버를 복제본으로 만들 수 없습니다. 다른 읽기 복제본의 복제본을 만들 수 없습니다. 즉, 연속 복제는 지원되지 않습니다.

리소스 이동

사용자는 주 리소스 그룹과 다른 리소스 그룹에 읽기 복제본을 만들 수 있습니다. 그러나 읽기 복제본을 만든 후 다른 리소스 그룹으로 이동하는 것은 지원되지 않습니다. 또한 복제본을 다른 구독으로 이동하고 읽기 복제본이 있는 주 복제본을 다른 리소스 그룹 또는 구독으로 이동하는 것은 지원되지 않습니다.

스토리지 자동 증가

Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 읽기 복제본을 구성할 때 복제본의 스토리지 자동 증가 설정이 주 서버의 스토리지 자동 증가 설정과 일치하는지 확인해야 합니다. 스토리지 자동 증가 기능을 사용하면 데이터베이스 스토리지가 자동으로 증가하여 공간이 부족하여 데이터베이스가 중단될 수 있습니다. 스토리지 자동 증가 설정을 효과적으로 관리하는 방법은 다음과 같습니다.

• 주 서버의 설정에 관계없이 모든 복제본에서 스토리지 자동 증가를 사용하도록 설정할 수 있습니다.
• 주 서버에서 스토리지 자동 증가를 사용하도록 설정한 경우 스토리지 크기 조정 동작의 일관성을 보장하기 위해 복제본에서도 사용하도록 설정해야 합니다.
• 주 복제본에서 스토리지 자동 증가를 사용하도록 설정하려면 먼저 복제본에서 스토리지를 사용하도록 설정해야 합니다. 이 작업 순서는 복제 무결성을 유지하는 데 중요합니다.
• 반대로, 스토리지 자동 증가를 사용하지 않도록 설정하려면 먼저 복제본 전에 주 서버에서 사용하지 않도록 설정하여 복제 복잡성을 방지합니다.

백업 및 복원

Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 백업 및 복원을 관리할 때는 다양한 승격 시나리오에서 서버의 현재 및 이전 역할을 염두에 두어야 합니다. 기억해야 할 주요 사항이 있습니다.

주 서버로 승격

1. 읽기 복제본에서 백업이 수행되지 않습니다: 이전 역할에 관계없이 읽기 복제본 서버에서 백업을 가져오지 않습니다.

2. 과거 백업 보존: 서버가 한때 주 서버였고 해당 기간 동안 수행된 백업이 있는 경우 해당 백업이 유지됩니다. 사용자 정의 보존 기간까지 보존됩니다.

3. 복원 작업 제한: 읽기 복제본으로 전환된 서버에 대한 이전 백업이 있더라도 복원 작업이 제한됩니다. 서버가 주 역할로 다시 승격된 경우에만 복원 작업을 시작할 수 있습니다.

이해를 돕기 위해 이러한 사항을 다음 표로 정리했습니다.

서버 역할	백업 수행	복원 허용됨
기본 항목	예	예
읽기 복제본	아니요	아니요
주 복제본으로 승격된 읽기 복제본	예	예

독립 서버로 승격 및 복제에서 제거

서버가 읽기 복제본인 동안에는 백업이 수행되지 않습니다. 그러나 독립 서버로 승격되면 승격된 서버와 주 서버 모두 백업이 수행되고 두 서버 모두에서 복원이 허용됩니다.

네트워킹

읽기 복제본은 Azure Database for PostgreSQL 유연한 서버에서 지원하는 모든 네트워킹 옵션을 지원합니다.

Important

주 서버와 읽기 복제본 간의 양방향 통신은 Azure Database for PostgreSQL 유연한 서버 설정에 매우 중요합니다. Azure 가상 네트워크 서브넷 내의 대상 포트 5432에서 트래픽을 보내고 받는 프로비전이 있어야 합니다.

위의 요구 사항은 동기화 프로세스를 용이하게 할 뿐만 아니라 복제본에서 주 복제본으로의 역순으로 통신해야 할 수 있는 승격 메커니즘의 적절한 작동을 보장합니다. 또한 WAL(Write-Ahead Logging) 보관 파일을 저장하는 Azure Storage 계정에 대한 연결은 데이터 내구성을 유지하고 효율적인 복구 프로세스를 사용하도록 허용되어야 합니다.

읽기 복제본에 대한 프라이빗 액세스(가상 네트워크 통합)를 구성하고 프라이빗 네트워킹 컨텍스트 내의 Azure 지역 및 가상 네트워크에서 복제에 미치는 영향을 이해하는 방법에 대한 자세한 내용은 프라이빗 네트워킹을 사용하여 Azure 지역 및 가상 네트워크에 대한 복제 페이지를 참조하세요.

복제 슬롯 문제 완화

드문 경우지만 복제 슬롯으로 인한 지연이 길어질 경우 WAL 파일이 누적되어 주 서버의 스토리지 사용량이 증가할 수 있습니다. 스토리지 사용량이 95%에 도달하거나 사용 가능한 용량이 5GiB 미만으로 떨어지면 서버는 디스크 가득 참 오류를 방지하기 위해 자동으로 읽기 전용 모드로 전환됩니다.

주 서버의 상태와 기능을 유지하는 것이 우선 순위이므로 이러한 예외 사례의 경우, 주 서버가 읽기 및 쓰기 트래픽에 대해 계속 작동하도록 복제 슬롯을 삭제할 수 있습니다. 따라서 복제는 파일 기반 로그 전달 모드로 전환되므로 복제 지연이 더 길어질 수 있습니다.

스토리지 사용량과 복제 지연을 면밀히 모니터링하고 잠재적인 문제를 완화하기 위해 필요한 조치를 취하는 것이 중요합니다.

서버 매개 변수

읽기 복제본이 만들어지면 주 서버에서 서버 매개 변수를 상속합니다. 이는 일관되고 신뢰할 수 있는 시작점을 보장하기 위한 것입니다. 그러나 읽기 복제본을 만든 후 만들어진 주 서버의 서버 매개 변수에 대한 변경 내용은 자동으로 복제되지 않습니다. 이 동작은 주 서버의 매개 변수를 수정하지 않고 읽기 집약적 작업에 대한 성능 향상과 같은 읽기 복제본의 개별 튜닝의 이점을 제공합니다. 유연성과 사용자 지정 옵션을 제공하지만 서버 매개 변수의 균일성이 필요한 경우 주 복제본과 복제본 간의 일관성을 유지하기 위해 신중하고 수동적인 관리가 필요합니다.

읽기 복제본 서버에서 서버 매개 변수를 자유롭게 변경하고 주 서버와 다른 값을 설정할 수 있습니다. 유일한 예외는 복제본의 복구에 영향을 줄 수 있는 매개 변수입니다. 아래의 ‘스케일링’ 섹션에서도 설명합니다. max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. 읽기 복제본의 복구가 원활하고 공유 메모리 제한이 발생하지 않도록 하려면 이러한 특정 매개 변수를 항상 주 서버에 구성된 값과 동일하거나 더 큰 값으로 설정해야 합니다.

확장

컴퓨팅(vCore)을 자유롭게 스케일링 업 및 스케일링 다운하여 서비스 계층을 범용 메모리 최적화(또는 그 반대로)로 변경하고 스토리지를 스케일링할 수 있지만 다음과 같은 주의 사항이 적용됩니다.

컴퓨팅 스케일링:

• Azure Database for PostgreSQL 유연한 서버는 복구하는 동안 복제본의 공유 메모리가 부족하지 않도록 복제본의 여러 매개 변수가 주 서버의 설정보다 크거나 같음으로 되었는지 확인하세요. 영향을 받는 매개 변수는 다음과 같습니다. max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

• 스케일 업: 먼저 복제본의 컴퓨팅을 스케일 업한 다음, 주 서버를 스케일 업합니다.

• 스케일 다운: 먼저 주 서버의 컴퓨팅을 스케일 다운한 다음, 복제본을 스케일 다운합니다.

• 주 서버의 컴퓨팅은 항상 가장 작은 복제본의 컴퓨팅보다 같거나 작아야 합니다.

스토리지 스케일링:

• 스케일 업: 먼저 복제본의 스토리지를 스케일 업한 다음, 주 서버를 스케일 업합니다.

• 주 서버의 스토리지 크기는 가장 작은 복제본 스토리지 크기보다 항상 같거나 작아야 합니다.

관련 콘텐츠

• 지역에서 복제
• 읽기 복제본 승격
• 가상 엔드포인트
• Azure Portal에서 읽기 복제본을 만들고 관리하는 방법
• 가상 네트워크를 사용하여 지역 간 복제