Azure Database for PostgreSQL - 유연한 서버에서 읽기 복제본 승격

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

승격은 복제본이 복제본 모드를 종료하고 전체 읽기-쓰기 작업으로 전환하도록 명령되는 프로세스를 나타냅니다.

Important

승격 작업은 자동으로 이루어지지 않습니다. 주 서버 오류가 발생할 경우 시스템은 읽기 복제본으로 독립적으로 전환되지 않습니다. 승격 작업에는 항상 사용자 작업이 필요합니다.

복제본 승격은 다음과 같은 두 가지 방식으로 수행할 수 있습니다.

주 서버로 승격

이 작업은 복제본을 주 서버의 역할로 승격합니다. 이 과정에서 현재 주 서버는 복제본 역할로 강등되어 역할이 바뀝니다. 성공적인 승격을 위해서는 현재 주 엔드포인트를 기록기 엔드포인트로, 승격하기 위한 복제본을 판독기 엔드포인트로 둘 다 가상 엔드포인트를 구성해야 합니다. 대상 복제본이 읽기 권한자 엔드포인트 구성에 포함된 경우에만 승격이 성공합니다.

다이어그램에서 승격 전 서버 구성과 승격 작업이 성공적으로 완료된 후의 결과 상태를 보여 줍니다.

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

이 옵션을 선택하면 복제본이 독립 서버로 승격되고 복제 프로세스에서 제거됩니다. 따라서 주 서버와 승격된 서버는 둘 다 독립적인 읽기-쓰기 서버 두 개로 작동합니다. 가상 엔드포인트를 구성할 수 있지만 이 작업에는 필요하지 않습니다. 새로 승격된 서버는 읽기 권한자 엔드포인트가 이전에 이를 가리켰더라도 더 이상 기존 가상 엔드포인트의 일부가 아닙니다. 따라서 애플리케이션이 새로 승격된 복제본으로 연결해야 하는 경우 애플리케이션의 연결 문자열을 새로 승격된 복제본으로 보내도록 업데이트해야 합니다.

다이어그램은 서버를 승격하기 전에 설정하는 방법과 독립 서버가 된 후의 구성을 보여줍니다.

Important

독립 서버로 승격 및 복제에서 제거 작업은 이전 승격 기능과 역호환됩니다.

Important

서버 대칭: 주 서버로 승격 작업을 사용하여 승격을 성공적으로 수행하려면 주 서버와 복제본 서버 모두 계층과 스토리지 크기가 동일해야 합니다. 예를 들어 주 복제본에 2vCore가 있고 복제본에 4vCore가 있는 경우 유일한 실행 가능한 옵션은 ‘독립 서버로 승격하고 복제에서 제거’ 작업을 사용하는 것입니다. 또한 공유 메모리를 할당하는 서버 매개 변수에 대해 동일한 값을 공유해야 합니다.

두 승격 방법 모두에 대해 고려해야 할 추가 옵션이 있습니다.

• 계획됨: 이 옵션은 승격하기 전에 데이터가 동기화되도록 합니다. 클라이언트 연결을 수락하기 전에 데이터 일관성을 보장하기 위해 보류 중인 모든 로그를 적용합니다.

• 강제: 이 옵션은 지역 가동 중단과 같은 시나리오에서 신속한 복구를 위해 설계되었습니다. 주 데이터베이스의 모든 데이터를 동기화하기 위해 기다리는 대신 가장 가까운 일관된 상태를 달성하는 데 필요한 WAL 파일을 처리하면 서버가 작동합니다. 이 옵션을 사용하여 복제본을 승격하는 경우 기본 복제본에서 복제본의 연결을 해제할 때의 지연은 손실된 데이터의 양을 나타냅니다.

Important

강제 승격 옵션은 지역적 중단을 해결하기 위해 특별히 설계되었으며, 이러한 경우 서버 대칭 요구 사항을 포함한 모든 확인을 건너뛰고 승격을 진행합니다. 재해 시나리오를 처리하기 위해 즉각적인 서버 가용성을 우선시하기 때문입니다. 그러나 설명서에 지정된 읽기 복제본에 대한 요구 사항, 특히 서버 대칭 요구 사항이 충족되지 않는 경우 복제 중단과 같은 문제가 발생할 수 있으므로 지역 다운 시나리오 외부에서 강제 옵션을 사용할 수 없습니다.

복제본을 주 서버로 승격하고 독립 서버로 승격하여 복제본에서 제거하는 방법을 알아봅니다.

구성 관리

읽기 복제본은 컨트롤 플레인 구성 측면에서 별도의 서버로 처리됩니다. 이 방식은 읽기 확장 시나리오에 유연성을 제공합니다. 그러나 재해 복구를 위해 복제본을 사용하는 경우 사용자는 구성이 원하는 대로 구성되었는지 확인해야 합니다.

승격 작업은 특정 구성 및 매개 변수를 수행하지 않습니다. 몇 가지 주목할 만한 항목은 다음과 같습니다.

• PgBouncer: 기본 제공 PgBouncer 연결 풀러의 설정 및 상태는 승격 프로세스 중에 복제되지 않습니다. 주 복제본에서 PgBouncer를 사용하도록 설정했지만 복제본에서는 사용하도록 설정되지 않은 경우 승격 후 복제본에서 비활성화된 상태로 유지됩니다. 새로 승격된 서버에서 PgBouncer를 사용하려면 승격 작업 전이나 다음에 사용하도록 설정해야 합니다.
• 지역 중복 백업 스토리지: 지역 백업 설정은 전송되지 않습니다. 복제본은 지역 백업을 사용하도록 설정할 수 없으므로 승격된 주 복제본(이전의 복제본)에는 승격 후 해당 복제본이 없습니다. 이 기능은 표준 서버의 생성 시간에만 활성화할 수 있습니다(복제본은 안 됨).
• 서버 매개 변수: 해당 값이 주 복제본과 읽기 복제본에서 다른 경우 승격 중에 변경되지 않습니다. 공유 메모리 크기에 영향을 주는 매개 변수는 주 복제본과 복제본 모두에서 동일한 값을 가져야 합니다. 이 요구 사항은 서버 매개 변수 섹션에 자세히 설명되어 있습니다.
• Microsoft Entra 인증: 주 복제본에 Microsoft Entra 인증이 구성되었지만 복제본이 PostgreSQL 인증으로 설정된 경우 승격 후 복제본이 자동으로 Microsoft Entra 인증으로 전환되지 않습니다. PostgreSQL 인증을 유지합니다. 사용자는 승격 프로세스 전후에 승격된 복제본에서 Microsoft Entra 인증을 수동으로 구성해야 합니다.
• HA(고가용성): 승격 후 HA가 필요한 경우 역할 반전에 따라 새로 승격된 주 서버에서 구성해야 합니다.

고려 사항

승격 중 서버 상태

계획 및 강제 승격 시나리오 모두에서 서버(기본 및 복제본 모두)가 "사용 가능" 상태여야 합니다. 서버 상태가 "사용 가능" 이외의 상태(예: "업데이트 중" 또는 "다시 시작 중")인 경우 일반적으로 승격이 문제 없이 진행될 수 없습니다. 다만, 지역정지의 경우에는 예외로 합니다.

이러한 지역적 중단 기간 동안 주 서버의 현재 상태에 관계없이 강제 승격 방법을 구현할 수 있습니다. 이 방식을 사용하면 서버 가용성에 대한 일반적인 검사를 무시하여 잠재적인 지역 재해에 응답하여 신속한 조치를 취할 수 있습니다.

복제본을 승격하는 동안 이전 주 서버가 복구를 초과하여 실패하는 경우 유일한 옵션은 이전 주 서버를 삭제하고 복제본 서버를 다시 만드는 것입니다.

쌍이 없는 지역에서 승격하는 동안 여러 복제본 표시 여부

여러 복제본을 처리할 때 주 지역에 쌍을 이루는 지역이 없는 경우 특별한 고려 사항을 고려해야 합니다. 기본 복제본에 영향을 미치는 지역 중단이 발생하는 경우 새로 승격된 복제본은 다른 복제본을 자동으로 인식하지 않습니다. 계속 작업을 위해 애플리케이션을 승격된 복제본으로 계속 보낼 수 있지만, 인식할 수 없는 복제본은 중단 중에 연결이 끊어진 상태로 유지됩니다. 이러한 추가 복제본은 원래 주 지역이 복원된 후에만 역할을 다시 연결하고 다시 시작합니다.

자주 묻는 질문

• 주 서버에 HA(고가용성)가 사용하도록 설정된 경우 복제본을 승격할 수 있나요?

  예, 주 서버는 HA 사용 여부에 관계없이 읽기 복제본을 승격할 수 있습니다. 읽기 복제본을 주 서버로 승격하는 기능은 주 서버의 HA 구성과 무관합니다.

• HA 지원 기본 복제본과 읽기 복제본이 있고 복제본을 승격한 다음 원래 기본 복제본으로 다시 전환하면 서버가 여전히 HA에 있나요?

  아니요, HA 사용 읽기 복제본을 지원하지 않으므로 초기 승격 중에 HA를 사용하지 않도록 설정합니다. 읽기 복제본을 기본 복제본으로 승격한다는 것은 원래 기본 복제본의 역할이 복제본으로 변경된다는 의미입니다. 다시 전환하는 경우 원래 주 서버에서 HA를 사용하도록 설정해야 합니다.

관련 콘텐츠

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