HAProxy 및 PGBouncer를 사용한 PostgreSQL 고 가용성 / 확장 성

웹 응용 프로그램을위한 여러 PostgreSQL 서버가 있습니다. 일반적으로 핫 스탠바이 모드 (비동기 스트리밍 복제)에서 하나의 마스터 및 여러 슬레이브.

연결 풀링에 PGBouncer를 사용합니다. localhost의 데이터베이스에 연결하는 각 PG 서버 (포트 6432)에 하나의 인스턴스가 설치되어 있습니다. 트랜잭션 풀 모드를 사용합니다.

슬레이브에서 읽기 전용 연결을로드 밸런싱하기 위해 다음과 같이 conf와 함께 HAProxy (v1.5)를 사용합니다.

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

따라서 내 웹 응용 프로그램은 각 PG 슬레이브에 구성된 여러 pgbouncer의 부하 분산 연결 인 haproxy (포트 10001)에 연결됩니다.

다음은 현재 아키텍처의 표현 그래프입니다.

이것은 이와 같이 잘 작동하지만 일부는 이것을 다르게 구현한다는 것을 알고 있습니다. 웹 응용 프로그램은 여러 PG 서버에서 부하 분산되는 HAproxy에 연결된 단일 PGBouncer 인스턴스에 연결합니다.

가장 좋은 방법은 무엇입니까? 첫 번째 (내 현재) 또는 두 번째? 하나의 솔루션이 다른 솔루션보다 장점이 있습니까?

감사

기존 HAProxy 구성-> PGBouncer-> PGServer 접근 방식이 더 좋습니다. 그리고 그것은 작동합니다. 이유는 다음과 같습니다. HAProxy가 다른 서버로 연결을 리디렉션합니다. 이로 인해 데이터베이스 연결에서 MAC 주소가 변경됩니다. 따라서 PGBouncer가 HAProxy보다 높으면 MAC 주소 변경으로 인해 풀의 연결이 무효화 될 때마다

pgbouncer는 postgres 서버가있는 풀에서 연결을 유지합니다. TCP 연결 설정 시간은 대량 환경에서 중요합니다.

많은 수의 DB 요청을하는 클라이언트는 각 요청에 대해 원격 PGBouncer와의 연결을 설정해야합니다. 이것은 PgBouncer를 로컬에서 실행하는 것보다 비용이 많이 들기 때문에 (응용 프로그램이 pgbouncer에 로컬로 연결됨) pgBouncer는 원격 PG 서버와의 연결 풀을 유지합니다.

따라서 IMO, PGBouncer-> HAProxy-> PGServer는 HAProxy-> PGBouncer-> PGServer보다 낫습니다. 특히 PGBouncer가 클라이언트 응용 프로그램에 로컬 인 경우.

donatello의 답변에 동의하지 않아야합니다.

애플리케이션이 로컬 풀을 사용하여 DB 연결을 관리하지 않으면 DB를 쿼리 할 때마다 새로운 연결이 생성됩니다. 이는 PgBouncer를 사용할 때와 동일하게 발생하므로이를 사용하면 매우 향상됩니다.

PgBouncer가 풀링하여 PostgreSQL 연결을 관리하는 경우 연결을 DB에 직접 열 때와 비교하여 앱에서 연결을 여는 데 소요되는 시간이 크게 줄어 듭니다. PG는 연결이 요청 될 때마다 자격 증명과 모든 것을 확인하고 확인하는 데 시간이 오래 걸리기 때문입니다.

따라서 PgBouncer가 연결 시간을 PG에 저장하므로 App-> HAProxy-> [PgBouncer-> PostgreSQL] 접근 방식이 더 좋습니다. 풀링 모드도 고려해야합니다. 앱의 작동 방식을 알고 있어야합니다. 주로 거래입니까? 아니면 동시성이 높은 작은 SQL 문장을 더 많이 실행합니까? 이러한 모든 매개 변수는 성능에 영향을줍니다.