Odyssey 로드맵: 연결 풀러에서 또 무엇을 원합니까? 안드레이 보로딘 (2019)

그의 보고서에서 Andrey Borodin은 연결 풀러를 설계할 때 PgBouncer 확장 경험을 어떻게 고려했는지 설명합니다. 오디세이, 이를 프로덕션에 적용했습니다. 또한 새 버전에서 보고 싶은 풀러의 기능에 대해 논의할 것입니다. 요구 사항을 충족하는 것뿐만 아니라 사용자 커뮤니티를 개발하는 것도 중요합니다. 오디세이.

비디오 :

안녕하세요 여러분! 내 이름은 앤드류입니다.

Yandex에서 저는 오픈 소스 데이터베이스를 개발하고 있습니다. 오늘은 연결 풀러 연결에 대한 주제를 다루겠습니다.

러시아어로 연결 풀러를 호출하는 방법을 알고 있다면 알려주십시오. 나는 기술 문헌에서 확립되어야 할 좋은 기술 용어를 정말로 찾고 싶습니다.

많은 데이터베이스에 연결 풀러가 내장되어 있고 이에 대해 알 필요조차 없기 때문에 주제는 매우 복잡합니다. 물론 곳곳에 몇 가지 설정이 있지만 Postgres에서는 그런 식으로 작동하지 않습니다. 그리고 동시에 (HighLoad++ 2019에서) Postgres의 쿼리 설정에 대한 Nikolai Samokhvalov의 보고서가 있습니다. 그리고 내가 이해하기로는 이미 쿼리를 완벽하게 구성한 사람들이 여기에 왔고, 이들은 네트워크 및 리소스 활용과 관련된 좀 더 드문 시스템 문제에 직면한 사람들입니다. 그리고 어떤 곳에서는 문제가 명확하지 않다는 점에서 상당히 어려울 수 있습니다.

Yandex에는 Postgres가 있습니다. 많은 Yandex 서비스가 Yandex.Cloud에 있습니다. 그리고 Postgres에는 초당 최소 백만 건의 요청을 생성하는 수 페타바이트의 데이터가 있습니다.

그리고 우리는 모든 서비스에 대해 상당히 표준적인 클러스터를 제공합니다. 이는 노드의 기본 기본 노드, 일반적인 두 개의 복제본(동기식 및 비동기식), 백업, 복제본에 대한 읽기 요청 확장입니다.

각 클러스터 노드는 Postgres이며, Postgres 및 모니터링 시스템 외에도 연결 풀러도 설치됩니다. 연결 풀러는 펜싱 및 주요 목적으로 사용됩니다.

연결 풀러의 주요 목적은 무엇입니까?

Postgres는 데이터베이스 작업 시 프로세스 모델을 채택합니다. 이는 하나의 연결이 하나의 프로세스, 하나의 Postgres 백엔드임을 의미합니다. 그리고 이 백엔드에는 다양한 캐시가 많이 있는데, 이는 서로 다른 연결에 대해 다르게 만드는 데 비용이 많이 듭니다.

또한 Postgres 코드에는 procArray라는 배열이 있습니다. 여기에는 네트워크 연결에 대한 기본 데이터가 포함되어 있습니다. 그리고 거의 모든 procArray 처리 알고리즘은 선형적 복잡성을 가지며 전체 네트워크 연결 배열에서 실행됩니다. 이는 매우 빠른 주기이지만 들어오는 네트워크 연결이 많아지면 비용이 조금 더 높아집니다. 그리고 비용이 조금 더 비싸지면 많은 네트워크 연결에 대해 매우 높은 비용을 지불하게 될 수 있습니다.

가능한 접근 방식은 3가지입니다.

• 응용 프로그램 측면에서.
• 데이터베이스 측.
• 그리고 그 사이에는 모든 종류의 조합이 있습니다.

안타깝게도 내장 풀러는 현재 개발 중입니다. PostgreSQL Professional의 친구들이 주로 이런 일을 합니다. 언제 나타날지는 예측하기 어렵습니다. 실제로 건축가가 선택할 수 있는 두 가지 솔루션이 있습니다. 이는 애플리케이션 측 풀과 프록시 풀입니다.

애플리케이션 측 풀이 가장 쉬운 방법입니다. 그리고 거의 모든 클라이언트 드라이버는 다음과 같은 방법을 제공합니다. 즉, 수백만 개의 연결을 데이터베이스에 대한 수십 개의 연결로 코드에 표시합니다.

발생하는 문제는 백엔드를 확장하고 싶은 특정 시점에서 이를 많은 가상 머신에 배포하고 싶다는 것입니다.

그런 다음 가용성 영역과 데이터 센터가 여러 개 더 있다는 것을 알게 됩니다. 그리고 클라이언트 측 풀링 접근 방식은 더 큰 숫자로 이어집니다. 큰 연결은 약 10개입니다. 정상적으로 작동할 수 있는 엣지입니다.

프록시 풀러에 관해 이야기하면 많은 일을 할 수 있는 두 명의 풀러가 있습니다. 그들은 단지 풀러가 아닙니다. 그들은 풀러 + 더 멋진 기능입니다. 이것 Pgpool и 크런치 프록시.

그러나 불행히도 모든 사람에게 이 추가 기능이 필요한 것은 아닙니다. 그리고 이는 풀러가 세션 풀링(예: 하나의 수신 클라이언트, 하나의 발신 클라이언트)만 데이터베이스로 지원한다는 사실로 이어집니다.

이는 우리 목적에 그다지 적합하지 않으므로 트랜잭션 풀링을 구현하는 PgBouncer를 사용합니다. 즉, 서버 연결은 트랜잭션 기간 동안에만 클라이언트 연결과 일치됩니다.

그리고 우리의 작업량에서는 이것이 사실입니다. 하지만 몇 가지 문제가 있습니다..

들어오는 모든 연결이 로컬이기 때문에 세션을 진단하려고 할 때 문제가 시작됩니다. 모두가 루프백을 가지고 왔고 왠지 세션을 추적하기가 어려워졌습니다.

물론 application_name_add_host를 사용할 수 있습니다. 이는 Bouncer 측에서 application_name에 IP 주소를 추가하는 방법입니다. 그러나 application_name은 추가 연결에 의해 설정됩니다.

이 그래프에서 노란색 선은 실제 요청이고 파란색 선은 데이터베이스로 유입되는 요청입니다. 그리고 이 차이점은 정확히 추적에만 필요하지만 전혀 무료가 아닌 application_name의 설치입니다.

또한 Bouncer에서는 하나의 풀, 즉 특정 데이터베이스당 특정 사용자당 데이터베이스 연결 수를 제한할 수 없습니다.

이것이 무엇으로 이어지는가? C++로 작성된 로드된 서비스가 있고 데이터베이스에 아무런 문제도 일으키지 않는 노드의 작은 서비스 근처 어딘가에 드라이버가 작동하지 않습니다. 20개의 연결이 열리고 다른 모든 것은 기다립니다. 코드도 정상입니다.

물론 우리는 클라이언트를 풀로 제한하는 설정을 추가하는 Bouncer용 작은 패치를 작성했습니다.

Postgres 측에서 이를 수행하는 것이 가능합니다. 즉, 연결 수에 따라 데이터베이스의 역할을 제한합니다.

그러나 서버에 연결되지 않은 이유를 이해하는 능력을 잃게 됩니다. PgBouncer는 연결 오류를 발생시키지 않으며 항상 동일한 정보를 반환합니다. 그리고 당신은 이해하지 못할 수도 있습니다. 비밀번호가 변경되었을 수도 있고, 데이터베이스가 손실되었을 수도 있고, 뭔가 잘못되었을 수도 있습니다. 그러나 진단은 없습니다. 세션을 설정할 수 없으면 왜 설정할 수 없는지 알 수 없습니다.

특정 시점에서 애플리케이션 그래프를 보고 애플리케이션이 작동하지 않는 것을 확인합니다.

상단을 보고 Bouncer가 단일 스레드인지 확인하세요. 이것은 서비스 인생의 전환점입니다. 당신은 XNUMX년 반 안에 데이터베이스 확장을 준비하고 있었고 풀러를 확장해야 한다는 것을 깨달았습니다.

우리는 더 많은 PgBouncer가 필요하다는 결론에 도달했습니다.

https://lwn.net/Articles/542629/

바운서가 약간 패치되었습니다.

그리고 TCP 포트를 재사용하여 여러 개의 Bouncer를 올릴 수 있도록 만들었습니다. 그리고 운영 체제는 라운드 로빈을 사용하여 이들 간에 들어오는 TCP 연결을 자동으로 전송합니다.

이는 클라이언트에게 투명합니다. 즉, 하나의 Bouncer가 있는 것처럼 보이지만 실행 중인 Bouncer 사이에 유휴 연결이 조각화되어 있음을 의미합니다.

그리고 어떤 순간에는 이 3명의 바운서가 각각 코어를 100% 소모하는 것을 볼 수 있습니다. 꽤 많은 경비원이 필요합니다. 왜?

TLS가 있기 때문입니다. 암호화된 연결이 있습니다. 그리고 TLS가 있거나 없는 Postgres를 벤치마킹하면 TLS 핸드셰이크가 CPU 리소스를 소비하기 때문에 암호화가 활성화된 경우 설정된 연결 수가 거의 XNUMX배 정도 감소한다는 것을 알 수 있습니다.

그리고 상단에는 들어오는 연결이 있을 때 실행되는 몇 가지 암호화 기능을 볼 수 있습니다. 기본 영역은 가용성 영역 간에 전환할 수 있으므로 들어오는 연결의 물결은 매우 일반적인 상황입니다. 즉, 어떤 이유로 이전 기본을 사용할 수 없게 되어 전체 로드가 다른 데이터 센터로 전송되었습니다. 그들은 모두 동시에 TLS에 인사하러 올 것입니다.

그리고 다수의 TLS 악수는 더 이상 Bouncer에게 인사하지 않을 수도 있지만 그의 목을 쥐어짜게 될 것입니다. 시간 초과로 인해 들어오는 연결의 웨이브가 감쇠되지 않을 수 있습니다. 지수 백오프 없이 베이스로 재시도하면 일관성 있는 웨이브로 계속해서 오지 않을 것입니다.

다음은 16개 코어를 16% 로드하는 100개 PgBouncer의 예입니다.

우리는 캐스케이드 PgBouncer에 왔습니다. 이는 Bouncer를 사용한 로드에서 달성할 수 있는 최상의 구성입니다. 외부 바운서는 TCP 핸드셰이크에 사용되고 내부 바운서는 실제 풀링에 사용되므로 외부 연결을 너무 많이 조각화하지 않습니다.

이 구성에서는 원활한 재시작이 가능합니다. 이 18개의 바운서를 모두 하나씩 다시 시작할 수 있습니다. 그러나 그러한 구성을 유지하는 것은 매우 어렵습니다. 시스템 관리자, DevOps 및 이 서버를 실제로 담당하는 사람들은 이 배열에 별로 만족하지 않을 것입니다.

우리의 모든 개선 사항은 오픈 소스로 승격될 수 있는 것처럼 보이지만 Bouncer는 잘 지원되지 않습니다. 예를 들어, 한 포트에서 여러 PgBouncer를 실행하는 기능은 한 달 전에 커밋되었습니다. 몇 년 전에 이 기능에 대한 끌어오기 요청이 있었습니다.

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

아니면 하나 더 예를 들어보겠습니다. Postgres에서는 불필요한 인증 없이 다른 연결에 비밀을 전송하여 진행 중인 요청을 취소할 수 있습니다. 그러나 일부 클라이언트는 단순히 TCP 재설정을 보냅니다. 즉, 네트워크 연결이 끊어집니다. 경비원은 무엇을 할 것인가? 그는 아무것도 하지 않을 것입니다. 계속해서 요청을 실행합니다. 작은 요청으로 데이터베이스를 생성한 엄청난 수의 연결을 받은 경우 Bouncer에서 연결을 끊는 것만으로는 충분하지 않으며 데이터베이스에서 실행 중인 해당 요청도 완료해야 합니다.

이는 패치되었으며 이 문제는 아직 Bouncer의 업스트림에 병합되지 않았습니다.

그래서 우리는 문제를 신속하게 수정할 수 있고 물론 멀티스레드여야 하는 개발 및 패치가 가능한 자체 연결 풀러가 필요하다는 결론에 도달했습니다.

우리는 멀티스레딩을 주요 작업으로 설정했습니다. 들어오는 TLS 연결의 물결을 잘 처리할 수 있어야 합니다.

이를 위해 우리는 네트워크 연결의 기계 상태를 순차 코드로 기술하도록 설계된 Machinarium이라는 별도의 라이브러리를 개발해야 했습니다. libpq 소스 코드를 보면 결과를 반환하고 "나중에 전화하세요. "라고 말할 수 있는 꽤 복잡한 호출을 볼 수 있습니다. 지금 당장은 IO가 있지만 IO가 사라지면 프로세서에 부하가 걸리게 됩니다.” 그리고 이것은 다단계 계획입니다. 네트워크 통신은 일반적으로 상태 머신으로 설명됩니다. "이전에 N 크기의 패킷 헤더를 받았다면 이제 N 바이트를 기다리고 있습니다.", "SYNC 패킷을 보냈다면 이제 결과 메타데이터가 있는 패킷을 기다리고 있습니다."와 같은 많은 규칙이 있습니다. 그 결과는 마치 미로가 라인 스캔으로 변환된 것처럼 다소 어렵고 직관에 반하는 코드입니다. 우리는 상태 머신 대신 프로그래머가 일반적인 명령형 코드 형태로 상호 작용의 주요 경로를 설명하도록 만들었습니다. 이 명령형 코드에서는 네트워크에서 데이터를 기다리면서 실행 시퀀스를 중단하고 실행 컨텍스트를 다른 코루틴(녹색 스레드)으로 전달해야 하는 위치를 삽입해야 합니다. 이 접근 방식은 미로에서 가장 예상되는 경로를 연속으로 기록한 다음 거기에 분기를 추가한다는 사실과 유사합니다.

결과적으로 우리는 TCP를 수락하고 라운드 로빈 방식으로 TPC 연결을 많은 작업자에게 전달하는 하나의 스레드를 갖게 됩니다.

이 경우 각 클라이언트 연결은 항상 하나의 프로세서에서 실행됩니다. 이를 통해 캐시 친화적으로 만들 수 있습니다.

또한 시스템 TCP 스택을 완화하기 위해 작은 패킷을 하나의 큰 패킷으로 수집하는 기능을 약간 개선했습니다.

또한 Odyssey가 구성된 경우 네트워크 연결 실패 시 CANCEL 및 ROLLBACK을 보낼 수 있다는 점에서 트랜잭션 풀링을 개선했습니다. 즉, 아무도 요청을 기다리고 있지 않으면 Odyssey는 데이터베이스에 요청을 시도하지 말라고 지시합니다. 귀중한 자원을 낭비할 수 있는 요청을 이행합니다.

그리고 가능할 때마다 동일한 클라이언트에 대한 연결을 유지합니다. 이렇게 하면 application_name_add_host를 다시 설치할 필요가 없습니다. 이것이 가능하다면 진단에 필요한 매개변수를 추가로 재설정할 필요가 없습니다.

우리는 Yandex.Cloud의 이익을 위해 일합니다. 그리고 관리형 PostgreSQL을 사용하고 연결 풀러가 설치된 경우 외부로 논리적 복제를 생성할 수 있습니다. 즉, 원하는 경우 논리적 복제를 사용하여 우리를 떠날 수 있습니다. Bouncer는 외부에서 논리적 복제 흐름을 해제하지 않습니다.

논리적 복제를 설정하는 예입니다.

또한 외부로의 물리적 복제도 지원됩니다. 물론 클라우드에서는 이것이 불가능합니다. 왜냐하면 클러스터가 자체에 대해 너무 많은 정보를 제공하기 때문입니다. 그러나 설치 시 Odyssey의 연결 풀러를 통해 물리적 복제가 필요한 경우 이것이 가능합니다.

Odyssey는 PgBouncer와 완벽하게 호환되는 모니터링 기능을 갖추고 있습니다. 거의 모든 동일한 명령을 실행하는 동일한 콘솔이 있습니다. 누락된 항목이 있는 경우 끌어오기 요청을 보내거나 최소한 GitHub에서 문제를 보내주시면 필요한 명령을 완료해 드리겠습니다. 그러나 우리는 이미 PgBouncer 콘솔의 주요 기능을 갖추고 있습니다.

물론 전달 오류도 있습니다. 데이터베이스에서 보고된 오류를 반환합니다. 귀하는 귀하가 데이터베이스에 포함되지 않은 이유뿐만 아니라 귀하가 데이터베이스에 포함되지 않은 이유에 대한 정보를 받게 됩니다.

PgBouncer와 100% 호환성이 필요한 경우 이 기능은 비활성화됩니다. 우리는 안전을 위해 Bouncer와 같은 방식으로 행동할 수 있습니다.

Разработка

Odyssey 소스 코드에 대한 몇 마디.

https://github.com/yandex/odyssey/pull/66

예를 들어 '일시 중지/재개' 명령이 있습니다. 일반적으로 데이터베이스를 업데이트하는 데 사용됩니다. Postgres를 업데이트해야 하는 경우 연결 풀러에서 일시 중지하고 pg_upgrade를 수행한 다음 다시 시작하면 됩니다. 그리고 클라이언트 측에서 보면 데이터베이스 속도가 단순히 느려지는 것처럼 보일 것입니다. 이 기능은 커뮤니티의 사람들에 의해 제공되었습니다. 그녀는 아직 얼지 않았지만 곧 모든 것이 얼게 될 것입니다. (이미 냉동)

https://github.com/yandex/odyssey/pull/73 - 이미 얼어붙었어

또한 PgBouncer의 새로운 기능 중 하나는 Yandex.Cloud에서 일하지 않는 사람이 제공한 SCRAM 인증 지원입니다. 둘 다 기능이 복잡하고 중요합니다.

그러므로 지금 약간의 코드를 작성하고 싶은 경우를 대비해 Odyssey가 무엇으로 만들어졌는지 알려드리고 싶습니다.

두 개의 기본 라이브러리에 의존하는 Odyssey 소스 기반이 있습니다. Kiwi 라이브러리는 Postgres 메시지 프로토콜의 구현입니다. 즉, Postgres의 기본 proto 3은 프런트엔드와 백엔드가 교환할 수 있는 표준 메시지입니다. 이는 Kiwi 라이브러리에서 구현됩니다.

Machinarium 라이브러리는 스레드 구현 라이브러리입니다. 이 머시나리움의 작은 조각은 어셈블리 언어로 작성되었습니다. 하지만 놀라지 마세요. 줄은 15개뿐입니다.

오디세이 아키텍처. 코루틴이 실행되는 기본 머신이 있습니다. 이 시스템은 들어오는 TCP 연결을 수락하고 이를 작업자 간에 배포하는 기능을 구현합니다.

여러 클라이언트에 대한 핸들러가 하나의 작업자 내에서 작동할 수 있습니다. 또한 메인 스레드는 풀에서 더 이상 필요하지 않은 연결을 삭제하기 위해 콘솔 및 크론 작업 처리를 실행합니다.

Odyssey는 표준 Postgres 테스트 스위트를 사용하여 테스트되었습니다. Bouncer와 Odyssey를 통해 설치 확인을 실행하면 null div가 표시됩니다. Bouncer와 Odyssey에서 정확히 동일하게 통과하지 못하는 날짜 형식과 관련된 여러 테스트가 있습니다.

또한 자체 테스트를 수행하는 드라이버도 많이 있습니다. 그리고 우리는 그들의 테스트를 사용하여 Odyssey를 테스트합니다.

또한 캐스케이드 구성으로 인해 Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey와 같은 다양한 번들을 테스트하여 Odyssey가 캐스케이드의 일부에 포함된 경우에도 여전히 작동하는지 확인해야 합니다. 우리가 예상한 대로.

레이크

우리는 프로덕션에서 Odyssey를 사용합니다. 그리고 모든 것이 제대로 작동한다고 말하면 공평하지 않을 것입니다. 아니요, 그렇습니다. 하지만 항상 그런 것은 아닙니다. 예를 들어 프로덕션에서는 모든 것이 제대로 작동했는데 PostgreSQL Professional의 친구들이 와서 메모리 누수가 발생했다고 말했습니다. 정말 그랬습니다. 우리는 그것을 바로잡았습니다. 그러나 그것은 간단했습니다.

그런 다음 연결 풀러에 들어오는 TLS 연결과 나가는 TLS 연결이 있음을 발견했습니다. 그리고 연결에는 클라이언트 인증서와 서버 인증서가 필요합니다.

Bouncer 및 Odyssey 서버 인증서는 해당 pcache에서 다시 읽히지만 클라이언트 인증서는 pcache에서 다시 읽을 필요가 없습니다. 확장 가능한 Odyssey가 궁극적으로 이 인증서를 읽는 시스템 성능에 영향을 미치기 때문입니다. 그가 저항하는 데 오랜 시간이 걸리지 않았기 때문에 이것은 우리에게 놀라운 일이었습니다. 처음에는 선형적으로 확장되었지만 20개의 동시 연결이 들어오는 이후에 이 문제가 드러났습니다.

플러그형 인증 방법은 내장된 Lunux 도구를 사용하여 인증하는 기능입니다. PgBouncer에서는 PAM의 응답을 기다리는 별도의 스레드가 있고 현재 연결을 서비스하고 PAM 스레드에 존재하도록 요청할 수 있는 기본 PgBouncer 스레드가 있는 방식으로 구현됩니다.

우리는 한 가지 간단한 이유로 이것을 구현하지 않았습니다. 우리에게는 많은 스레드가 있습니다. 이것이 왜 필요한가요?

이로 인해 PAM 인증과 비PAM 인증이 있는 경우 PAM 인증이 대량으로 발생하면 비PAM 인증이 상당히 지연될 수 있다는 점에서 궁극적으로 문제가 발생할 수 있습니다. 이는 우리가 해결하지 못한 문제 중 하나입니다. 하지만 문제를 고치고 싶다면 이렇게 할 수 있습니다.

또 다른 문제는 들어오는 모든 연결을 허용하는 하나의 스레드가 있다는 것입니다. 그런 다음 TLS 핸드셰이크가 수행되는 작업자 풀로 전송됩니다.

결론적으로, 20개의 일관된 네트워크 연결이 있다면 모두 허용됩니다. 그리고 클라이언트 측에서 libpq는 시간 초과 보고를 시작합니다. 기본적으로 000초인 것 같습니다.

모두가 동시에 데이터베이스에 들어갈 수 없다면, 비지수 재시도로 이 모든 것을 처리할 수 있기 때문에 데이터베이스에 들어갈 수 없습니다.

우리는 우리가 허용하는 TCP 연결 수를 제한한다는 사실과 함께 PgBouncer의 구성표를 여기에서 복사했다는 결론에 도달했습니다.

연결을 수락하고 있지만 궁극적으로 핸드셰이크할 시간이 없는 경우 CPU 리소스를 낭비하지 않도록 해당 연결을 대기열에 넣습니다. 이로 인해 도착한 모든 연결에 대해 동시 핸드셰이크가 수행되지 않을 수 있습니다. 그러나 부하가 상당히 크더라도 적어도 누군가는 데이터베이스에 들어갈 것입니다.

로드맵

앞으로 Odyssey에서 무엇을 보고 싶나요? 우리는 스스로 발전할 준비가 되어 있으며, 커뮤니티에서 무엇을 기대합니까?

2019년 XNUMX월 기준.

XNUMX월 Odyssey 로드맵은 다음과 같습니다.

• 우리는 SCRAM 및 PAM 인증을 원했습니다.
• 우리는 읽기 요청을 대기로 전달하고 싶었습니다.
• 온라인으로 다시 시작하고 싶습니다.
• 그리고 서버에서 일시 정지하는 기능도 있습니다.

이 로드맵의 절반은 완료되었으며 우리가 완료한 것이 아닙니다. 그리고 이것은 좋은 것입니다. 그럼 남은 내용에 대해 논의하고 더 추가해 보겠습니다.

읽기 전용 쿼리를 대기로 전달하는 방법? 요청을 실행하지 않고 단순히 공기를 가열하는 복제본이 있습니다. 장애 조치(failover) 및 전환(switchover)을 제공하려면 이러한 정보가 필요합니다. 데이터 센터 중 하나에 문제가 발생하면 그 곳에서 유용한 작업을 수행하고 싶습니다. 동일한 중앙 프로세서, 동일한 메모리를 다르게 구성할 수 없기 때문에 그렇지 않으면 복제가 작동하지 않습니다.

원칙적으로 Postgres에서는 10부터 접속 시 session_attrs를 지정하는 것이 가능합니다. 연결에 있는 모든 데이터베이스 호스트를 나열하고 데이터베이스로 이동하는 이유(쓰기 또는 읽기 전용)를 말할 수 있습니다. 그리고 드라이버는 목록에서 자신이 가장 좋아하는 첫 번째 호스트를 선택하게 되며, 이는 session_attrs의 요구 사항을 충족합니다.

그러나 이 접근 방식의 문제점은 복제 지연을 제어하지 못한다는 것입니다. 서비스에 대해 허용할 수 없는 시간 동안 지연된 일부 복제본이 있을 수 있습니다. 복제본에서 읽기 쿼리의 모든 기능을 실행하려면 읽을 수 없을 때 실행되지 않는 Odyssey 기능을 기본적으로 지원해야 합니다.

Odyssey는 수시로 데이터베이스에 가서 기본 데이터베이스로부터의 복제 거리를 요청해야 합니다. 그리고 제한 값에 도달한 경우 데이터베이스에 대한 새 요청을 허용하지 말고 클라이언트에 연결을 다시 시작해야 한다고 알리고 요청을 실행할 다른 호스트를 선택해야 할 수도 있습니다. 이를 통해 데이터베이스는 복제 지연을 신속하게 복원하고 요청에 응답하기 위해 다시 돌아올 수 있습니다.

오픈소스이기 때문에 구현 시기를 말씀드리기가 어렵습니다. 하지만 PgBouncer의 동료들처럼 2,5년은 아니길 바랍니다. 이것이 제가 오디세이에서 보고 싶은 기능입니다.

커뮤니티에서는 준비된 성명서에 대한 지지를 묻는 질문이 있었습니다.. 이제 두 가지 방법으로 준비된 문을 만들 수 있습니다. 먼저 "준비됨"이라는 SQL 명령을 실행할 수 있습니다. 이 SQL 명령을 이해하려면 Bouncer 측의 SQL을 이해하는 방법을 배워야 합니다. 전체 파서가 필요하기 때문에 이는 과잉입니다. 모든 SQL 명령을 구문 분석할 수는 없습니다.

그러나 proto3의 메시지 프로토콜 수준에는 준비된 명령문이 있습니다. 그리고 준비된 명세서가 생성된다는 정보가 구조화된 형태로 들어오는 곳이다. 그리고 일부 서버 연결에서 클라이언트가 준비된 명령문을 생성하도록 요청했다는 이해를 지원할 수 있습니다. 그리고 트랜잭션이 종료되더라도 서버와 클라이언트 간의 연결을 유지해야 합니다.

그러나 여기에서 대화에 불일치가 발생합니다. 누군가가 클라이언트가 어떤 종류의 준비된 명령문을 생성했는지 이해하고 이 서버 연결을 생성한 모든 클라이언트, 즉 준비된 명령문을 생성한 모든 클라이언트 간에 서버 연결을 공유해야 한다고 말하기 때문입니다.

Andres Freund는 다른 서버 연결에서 이미 준비된 진술을 작성한 클라이언트가 당신에게 오면 그를 위해 그것을 작성한다고 말했습니다. 하지만 클라이언트 대신 데이터베이스에서 쿼리를 실행하는 것은 조금 잘못된 것 같지만, 데이터베이스와 상호 작용하기 위한 프로토콜을 작성하는 개발자의 관점에서는 단순히 네트워크 연결만 제공된다면 편리할 것입니다. 이렇게 준비된 쿼리가 있습니다.

그리고 구현해야 할 기능이 하나 더 있습니다. 이제 PgBouncer와 호환되는 모니터링이 가능해졌습니다. 평균 쿼리 실행 시간을 반환할 수 있습니다. 그러나 평균 시간은 병원의 평균 온도입니다. 일부는 춥고 일부는 따뜻합니다. 평균적으로 모두가 건강합니다. 사실이 아닙니다.

리소스를 낭비하고 모니터링을 보다 수용 가능하게 만드는 느린 쿼리가 있음을 나타내는 백분위수에 대한 지원을 구현해야 합니다.

가장 중요한 것은 버전 1.0을 원한다는 것입니다(버전 1.1은 이미 출시되었습니다). 사실 Odyssey는 현재 버전 1.0rc, 즉 릴리스 후보에 있습니다. 그리고 제가 나열한 모든 문제는 메모리 누수를 제외하고는 정확히 동일한 버전으로 수정되었습니다.

버전 1.0은 우리에게 무엇을 의미합니까? 우리는 Odyssey를 기지에 출시하고 있습니다. 이미 우리 데이터베이스에서 실행되고 있지만 초당 1 요청 지점에 도달하면 이것이 릴리스 버전이라고 말할 수 있으며 이것이 000이라고 할 수 있는 버전입니다.

커뮤니티의 몇몇 사람들은 버전 1.0에 일시정지 및 SCRAM이 포함되도록 요청했습니다. 그러나 이것은 SCRAM이나 일시 중지가 아직 종료되지 않았기 때문에 다음 버전을 프로덕션에 출시해야 함을 의미합니다. 그러나 아마도 이 문제는 매우 빨리 해결될 것입니다.

나는 당신의 풀 리퀘스트를 기다리고 있습니다. Bouncer에 어떤 문제가 있는지도 듣고 싶습니다. 그것들에 대해 토론해 봅시다. 아마도 필요한 일부 기능을 구현할 수 있을 것입니다.

이것이 내 역할의 끝입니다. 당신의 말을 듣고 싶습니다. 감사합니다!

질문

내 자신의 application_name을 설정하면 Odyssey의 트랜잭션 풀링을 포함하여 올바르게 전달됩니까?

오디세이 또는 바운서?

오디세이에서. Bouncer에서는 던져집니다.

우리는 세트를 할 것입니다.

실제 연결이 다른 연결로 점프하면 전송되나요?

목록에 나열된 모든 매개변수 세트를 만듭니다. application_name이 이 목록에 있는지 알 수 없습니다. 거기서 그를 본 것 같아요. 우리는 모두 동일한 매개 변수를 설정합니다. 한 번의 요청으로 세트는 시작 중에 클라이언트가 설치한 모든 작업을 수행합니다.

보고해 주셔서 감사합니다, Andrey! 좋은 보고서입니다! 오디세이가 매분마다 점점 더 빠르게 발전하고 있어서 기쁘네요. 나는 이대로 계속하고 싶다. 우리는 이미 Odyssey가 서로 다른 데이터베이스, 즉 마스터 슬레이브에 동시에 연결할 수 있도록 다중 데이터 소스 연결을 요청한 다음 장애 조치 후 자동으로 새 마스터에 연결할 수 있도록 요청했습니다.

네, 이 토론이 기억나는 것 같아요. 이제 여러 저장소가 있습니다. 그러나 그들 사이에는 전환이 없습니다. 우리 측에서는 서버가 아직 살아 있는지 폴링하고 pg_recovery를 호출하는 장애 조치가 발생했음을 이해해야 합니다. 나는 우리가 주인에게 오지 않았다는 것을 이해하는 표준적인 방법을 가지고 있습니다. 그리고 우리는 실수로부터 어떻게든 이해해야 합니까? 즉, 아이디어가 흥미롭고 논의되고 있습니다. 더 많은 댓글을 작성하세요. C를 아는 작업자가 있다면 좋습니다.

우리는 애플리케이션 개발자가 복제된 클러스터를 최대한 간단하게 채택할 수 있도록 하고자 하기 때문에 복제본 전체에 걸쳐 확장하는 문제에도 관심이 있습니다. 하지만 여기에는 더 많은 의견, 즉 정확히 어떻게 해야 하는지, 어떻게 하면 잘 해야 하는지에 대한 의견이 필요합니다.

문제는 복제본에 관한 것이기도 합니다. 마스터와 여러 복제본이 있는 것으로 나타났습니다. 그리고 차이가 있을 수 있기 때문에 연결을 위해 마스터보다 복제본으로 이동하는 빈도가 적다는 것이 분명합니다. 데이터의 차이가 너무 커서 비즈니스를 만족시키지 못할 수 있으며 복제될 때까지 거기에 가지 않을 것이라고 말씀하셨습니다. 동시에 오랫동안 거기에 가지 않았다가 가기 시작하면 필요한 데이터를 즉시 사용할 수 없습니다. 즉, 지속적으로 마스터로 이동하면 캐시가 워밍업되지만 복제본에서는 캐시가 약간 지연됩니다.

그래 그건 사실이야. pcache에는 원하는 데이터 블록이 없으며 실제 캐시에는 원하는 테이블에 대한 정보가 없으며 계획에는 구문 분석된 쿼리가 없으며 전혀 아무것도 없습니다.

어떤 종류의 클러스터가 있고 거기에 새 복제본을 추가하면 시작하는 동안 모든 것이 잘못됩니다. 즉, 캐시가 늘어납니다.

나는 아이디어를 얻었다. 올바른 접근 방식은 먼저 복제본에서 적은 비율의 쿼리를 실행하여 캐시를 준비하는 것입니다. 대략적으로 말하면 마스터보다 10초 이상 늦지 않아야 한다는 조건이 있습니다. 그리고 이 조건은 하나의 물결에 포함되지 않지만 일부 고객에게는 원활하게 포함됩니다.

응, 체중을 늘려라.

이것은 좋은 생각입니다. 하지만 먼저 이 종료를 구현해야 합니다. 먼저 전원을 꺼야 하고, 그런 다음 켜는 방법을 생각해 보겠습니다. 원활하게 활성화할 수 있는 좋은 기능입니다.

Nginx에는 이 옵션이 있습니다 slowly start 서버용 클러스터에 있습니다. 그리고 그는 점차적으로 부하를 증가시킵니다.

네, 좋은 생각이에요. 기회가 생기면 시도해 보겠습니다.

출처 : habr.com