이 기사의 번역은 코스의 학생들을 위해 특별히 준비되었습니다. "데이터 베이스". 이 방향으로 발전하는 데 관심이 있으십니까? 우리는 당신을 초대합니다 오픈데이, 프로그램, 온라인 형식의 기능, 교육 후 졸업생을 기다리는 역량 및 경력 전망에 대해 자세히 설명합니다.

PostgreSQL 및 연결별 쓰기 일관성 설정
Compose에서는 많은 데이터베이스를 다루며, 이를 통해 해당 데이터베이스의 기능과 단점에 더 익숙해질 수 있는 기회를 얻습니다. 새로운 데이터베이스의 기능을 사랑하는 법을 배우면서 우리는 오랫동안 우리가 사용해 온 보다 성숙한 도구에 비슷한 기능이 있다면 얼마나 좋을까 생각하기 시작합니다. PostgreSQL에서 보고 싶었던 새로운 기능 중 하나는 전체 클러스터에 걸쳐 연결별로 구성 가능한 쓰기 일관성이었습니다. 결과적으로 우리는 이미 그것을 가지고 있으며 오늘은 그것을 사용하는 방법에 대한 정보를 공유하고 싶습니다.

왜 내가 그것을 필요로합니까?

클러스터의 작동 방식은 애플리케이션에 따라 다릅니다. 예를 들어 청구서 결제 앱을 생각해 보세요. 클러스터 전반에 걸쳐 XNUMX% 일관성이 필요하므로 데이터베이스가 모든 변경이 이루어질 때까지 기다리도록 동기 커밋을 활성화해야 합니다. 그러나 귀하의 애플리케이션이 빠르게 성장하는 소셜 네트워크라면 아마도 XNUMX% 일관성보다 빠른 응답을 선호할 것입니다. 이를 달성하기 위해 클러스터에서 비동기 커밋을 사용할 수 있습니다.

타협을 만나다

데이터 일관성과 성능 간에 균형을 맞춰야 합니다. PostgreSQL은 기본 구성이 예측 가능하고 예상치 못한 문제가 발생하지 않기 때문에 일관성에서 멀어집니다. 이제 타협안을 살펴보겠습니다.

절충안 1: 성능

PostgreSQL 클러스터에 일관성이 필요하지 않은 경우 비동기식으로 실행할 수 있습니다. 쓰기는 클러스터 리더에 이루어지며 업데이트는 몇 밀리초 후에 복제본으로 전송됩니다. PostgreSQL 클러스터에 일관성이 필요한 경우 동기식으로 실행해야 합니다. 쓰기는 클러스터 리더에게 이루어지며, 클러스터 리더는 복제본에 업데이트를 보내고 쓰기가 성공했다는 확인을 쓰기를 시작한 클라이언트에 보내기 전에 각 복제본에 대한 확인을 기다립니다. 이러한 접근 방식의 실질적인 차이점은 비동기식 방법에는 두 개의 네트워크 홉이 필요한 반면 동기식 방법에는 네 개가 필요하다는 것입니다.

절충안 2: 일관성

이 두 가지 접근 방식에서 리더가 실패할 경우 결과도 달라집니다. 작업이 비동기식으로 수행되는 경우 이러한 오류가 발생하면 복제본이 모든 레코드를 커밋하지 않습니다. 얼마나 손실될 것인가? 애플리케이션 자체와 복제 효율성에 따라 다릅니다. Compose 복제는 정보의 양이 리더보다 1MB 적은 경우 복제본이 리더가 되는 것을 방지합니다. 즉, 비동기 작업 중에 최대 1MB의 레코드가 잠재적으로 손실될 수 있습니다.

이는 동기 모드에서는 발생하지 않습니다. 리더에 장애가 발생하면 리더에서 확인된 모든 쓰기가 복제본에서 확인되어야 하므로 모든 복제본이 업데이트됩니다. 이것이 일관성입니다.

일관성과 성능 간의 균형에서 일관성이 분명한 이점을 갖는 청구 애플리케이션에서는 동기식 동작이 적합합니다. 이러한 애플리케이션에서 가장 중요한 것은 유효한 데이터입니다. 이제 가능한 한 빨리 요청에 응답하여 사용자의 관심을 유지하는 것이 주요 임무인 소셜 네트워크에 대해 생각해 보십시오. 이 경우 네트워크 홉 수가 적고 커밋 대기 시간이 적은 성능이 우선시됩니다. 그러나 성능과 일관성 사이의 균형을 생각해야 하는 것은 아닙니다.

절충점 3: 충돌

장애 발생 시 클러스터가 어떻게 작동하는지 이해하는 것이 매우 중요합니다. 하나 이상의 복제본이 실패하는 상황을 생각해 보십시오. 커밋이 비동기식으로 처리되면 리더는 누락된 복제본을 기다리지 않고 계속해서 작동합니다. 즉, 쓰기를 수락하고 처리합니다. 복제본이 클러스터로 돌아오면 리더를 따라잡습니다. 동기 복제를 사용하면 복제본이 응답하지 않으면 리더는 선택의 여지가 없으며 복제본이 클러스터로 돌아와 쓰기를 수락하고 커밋할 수 있을 때까지 커밋 확인을 계속 기다립니다.

트랜잭션 당 하나의 연결?

모든 애플리케이션에는 일관성과 성능의 다양한 조합이 필요합니다. 물론 완전히 일관적이라고 생각되는 청구서 지불 앱이나 거의 일시적인 소셜 네트워킹 앱이 아니라면 말입니다. 다른 모든 경우에는 일부 작업은 동기식이어야 하고 일부 작업은 비동기식이어야 하는 경우가 있습니다. 채팅에 전송된 메시지가 커밋될 때까지 시스템이 기다리지 않기를 원할 수도 있지만 동일한 애플리케이션에서 결제가 처리되는 경우 기다려야 합니다.

물론 이러한 모든 결정은 애플리케이션 개발자가 내립니다. 각 접근 방식을 언제 사용할지에 대해 올바른 결정을 내리는 것은 클러스터를 최대한 활용하는 데 도움이 됩니다. 개발자가 연결과 트랜잭션을 위해 SQL 수준에서 이들 사이를 전환할 수 있다는 것이 중요합니다.

실제로 제어 보장

기본적으로 PostgreSQL은 일관성을 제공합니다. 이는 서버 매개변수에 의해 제어됩니다. synchronous_commit. 기본적으로 위치에 있습니다 on하지만 세 가지 다른 옵션이 있습니다. local, remote_write 또는 off.

매개변수를 다음으로 설정할 때 off 로컬 시스템에서도 모든 동기 커밋이 중지됩니다. local 매개변수는 로컬 시스템에 대한 동기 모드를 지정하지만 복제본에 대한 쓰기는 비동기적으로 수행됩니다. Remote_write 더 나아가 복제본에 대한 쓰기는 비동기식으로 이루어지지만 복제본이 쓰기를 허용했지만 디스크에 쓰지 않은 경우 반환됩니다.

사용 가능한 옵션 범위를 고려하여 행동을 선택하고 다음 사항을 염두에 둡니다. on – 이것은 동기식 녹음이므로 다음을 선택하겠습니다. local 네트워크를 통한 비동기 커밋의 경우 로컬 커밋을 동기 상태로 유지합니다.

이제 잠시 후에 이를 설정하는 방법을 알려드리겠습니다. synchronous_commit в local 서버를 위해. 매개변수를 변경할 수 있는지 궁금했습니다. synchronous_commit 즉석에서 가능할뿐만 아니라 이를 수행하는 방법도 두 가지가 있다는 것이 밝혀졌습니다. 첫 번째는 연결 세션을 다음과 같이 설정하는 것입니다.

SET SESSION synchronous_commit TO ON;  
// Your writes go here

세션의 모든 후속 쓰기는 연결된 클라이언트에 긍정적인 결과를 반환하기 전에 복제본에 대한 쓰기를 승인합니다. 물론 설정을 바꾸지 않는 이상 synchronous_commit 다시. 부분은 생략하셔도 됩니다 SESSION 명령에서는 기본값이 되기 때문입니다.

두 번째 방법은 단일 트랜잭션에 대해 동기식 복제를 수행하려는 경우에 좋습니다. 많은 NoSQL 생성 데이터베이스에는 트랜잭션 개념이 존재하지 않지만 PostgreSQL에서는 존재합니다. 이 경우 트랜잭션을 시작한 다음 설정합니다. synchronous_commit в on 거래 항목을 실행하기 전에. COMMIT 매개변수 값을 사용하여 트랜잭션을 커밋합니다. synchronous_commit, 쓰기가 비동기적이지 않다는 것을 다른 개발자가 이해할 수 있도록 변수를 미리 설정하는 것이 가장 좋지만 당시에 설정되었습니다.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

이제 데이터베이스가 연결된 클라이언트에 긍정적인 응답을 반환하기 전에 모든 트랜잭션 커밋이 복제본에 기록된 것으로 확인됩니다.

PostgreSQL 구성

이전에 우리는 PostgreSQL 시스템을 상상했습니다. synchronous_commit,에 설치됨 local. 서버 측에서 이를 현실적으로 만들려면 두 가지 서버 구성 옵션을 설정해야 합니다. 매개변수가 하나 더 있습니다. synchronous_standby_names 언제쯤 저절로 드러날지 synchronous_commit 에있을 것이다 on. 동기식 커밋에 적합한 복제본을 결정하고 이를 다음과 같이 설정합니다. *, 이는 모든 복제본이 관련됨을 의미합니다. 이 값은 일반적으로 다음에서 구성됩니다. 구성 파일 추가하여:

synchronous_commit = local  
synchronous_standby_names='*'

매개변수를 설정하여 synchronous_commit 의미상 local, 로컬 디스크는 동기식으로 유지되지만 네트워크 복제본 커밋은 기본적으로 비동기식인 시스템을 만듭니다. 물론, 위에 표시된 것처럼 이러한 커밋을 동기식으로 만들기로 결정하지 않는 한.

개발 과정을 따라오셨다면 지사 프로젝트, 최근 변경된 사항을 확인하셨을 것입니다(1, 2)를 통해 주지사 사용자는 이러한 매개변수를 테스트하고 일관성을 모니터링할 수 있었습니다.

몇 마디 더...

불과 일주일 전만 해도 저는 PostgreSQL을 이렇게 세밀하게 조정하는 것은 불가능하다고 말씀드렸을 것입니다. 그때 Compose 플랫폼팀의 일원인 Kurt는 그러한 기회가 존재한다고 주장했습니다. 그는 내 반대 의견을 진정시키고 PostgreSQL 문서에서 이를 발견했습니다. 다음:

이 설정은 언제든지 변경할 수 있습니다. 모든 트랜잭션의 동작은 커밋 시 적용되는 설정에 따라 결정됩니다. 따라서 일부 트랜잭션은 동기식으로 커밋하고 다른 트랜잭션은 비동기식으로 커밋하는 것이 가능하고 유용합니다. 예를 들어, 강제로 multistatement 매개변수의 기본값이 반대인 경우 비동기적으로 커밋을 수행하는 트랜잭션을 설정합니다. SET LOCAL synchronous_commit TO OFF 거래에서.

구성 파일을 약간 수정하여 사용자가 일관성과 성능을 제어할 수 있게 했습니다.

출처 : habr.com