pgpool-II 3.4의 신기능

본 기사는 2014 년 PostgreSQL Advent Calendar의 12/17의 기사입니다. 2014 년 11 월 7 일에 출시 된 pgpool-II 3.4의 새로운 기능을 소개합니다.

pgpool-II는

pgpool-II는 여러 PostgreSQL을 사용한 클러스터 시스템을 구축 할 수있는 미들웨어입니다. pgpool-II는 PostgreSQL 클라이언트와 여러 PostgreSQL 사이에 끼어 든 proxy처럼 작동합니다. 기존 PostgreSQL 애플리케이션을 거의 변경하지 않고 사용할 수 있습니다.

가장 많은 pgpool-II의 용도는 PostgreSQL를 여러 대 사용하는 스트리밍 복제 구성에 의한 클러스터의 관리 서버로 사용하는 것입니다. 다음과 같은 기능을 사용할 수 있습니다.

PostgreSQL의 사활 감시. 다운 PostgreSQL을 감지하여 클러스터 구성에서 분리하여 (장애) 클러스터로 계속 작동합니다.

PostgreSQL 주 서버가 다운되었을 때 다른 대기 서버를 자동 승격 할 수 있습니다.

검색 부하 분산. 검색어를 자동으로 PostgreSQL 서버에 배분함으로써 검색 성능을 향상시킵니다.

pgpool-II 구성도

pgpool-II는 오픈 소스로 제공되어 누구나 자유롭게 이용할 수 있습니다. 활발하게 개발이 이루어지고 있으며, PostgreSQL 마찬가지로 1 년에 한 번 주요 릴리스 일년에 몇 차례의 마이너 릴리스가 있습니다.

pgpool-II 3.4의 새로운 기능 1 : PostgreSQL 9.4 지원

이 기사를 여러분이 보게 될 무렵에는 PostgreSQL 9.4이 출시되고 있다고 생각 합니다만, pgpool-II 3.4는 이미 PostgreSQL 9.4에 대응했습니다. pgpool-II는 내부에 PostgreSQL에서 이식 한 SQL 파서를 가지고 있으며, 이것이 9.4 대응합니다. 예를 들어, ALTER SYSTEM, REFRESH MATERIALIZED VIEW CONCURRENTLY SELECT ... WITH ORDINALITY SELECT ... FOR UPDATE NOWAIT 같은 새로운 구문을 지원합니다.

또한 PostgreSQL 9.4에서는 to_regclass라는 새로운 기능이 추가되었습니다. 이 함수는 테이블 이름을 전달하면 OID (개체 식별자)를 반환하는 함수에서 존재하지 않는 테이블을 통과해도 에러가되지 않는 곳이 기존의 함수 (regclass)과 다릅니다. pgpool-II는 쿼리를 분석 할 때 regclass 해당 기능이 필요했던 것입니다 만, 존재하지 않는 테이블을 전달하고 오류를 일으키는 곤란하므로, 지금까지 자기 부담의 C 함수를 준비했습니다 . pgpool-II 3.4에서는 to_regclass 함수가 존재하는 경우에는 자동으로이 함수를 사용하기 때문에, 자기 부담의 함수를 설치할 필요가 없어졌습니다.

pgpool-II 3.4의 새로운 기능 2 : 성능 튜닝 매개 변수 추가

pgpool-II의 성능을 튜닝하는 매개 변수 추가되었습니다.

check_unlogged_table를 off로하면 unlogged 테이블 여부의 확인을 생략합니다. unlogged 테이블을 이용하지 않은 경우에는 pgpool-II가 unlogged 테이블 여부를 확인하기 위해 발행하는 쓸데없는 문의가 발행되는 것을 방지 할 수 있습니다.

connect_timeout은 pgpool-II가 PostgreSQL에 연결할 때 시간 제한을 지정합니다. 클라우드 환경에서 네트워크가 불안정해질 수있는 경우 connect 시스템 호출 시간 초과로 인해 자주 장애가 발생하는 것을 방지합니다.

listen_backlog_multiplier는 클라이언트의 연결을 기다리는위한 커널 요청 큐 (listen 큐)의 길이를 지정합니다. listen 큐의 길이가 너무 짧으면 TCP / IP 재 시도하면 클라이언트에서 연결에 매우 시간이 걸리고 극단적으로 성능이 저하됩니다. 이 현상에 대한 자세한 내용은 다른 문서를 참조하십시오.

pgpool-II 3.4의 새로운 기능 3 : 세분​​화 된 로그 설정이 가능

로그 출력 설정을 할 log_error_verbosity, client_min_messages, log_min_messages가 도입되었습니다. 아시는 분도 많을 거라 생각 합니다만, 이것은 PostgreSQL의 설정 항목과 전혀 이름에서 역할도 마찬가지입니다.

사실 이번이 기능을 실현할 수 있었던 것은 PostgreSQL의 로그 모듈이 도입 된 때문입니다. PostgreSQL에서는 로그 모듈과 예외 처리가 일체가되어있어 이번 pgpool-II에도 예외 처리 메커니즘이 구현 된 것입니다. 사용자에서 직접 보이지 않는 곳에 있지만, 예외 처리의 도입으로 코드가 단순 해지고 안정성도 오르는 장점이 나왔습니다했다.

pgpool-II 3.4의 새로운 기능 그 4 : 검색 부하 분산의 섬세한 제어

 pgpool-II는 검색 처리를 여러 PostgreSQL 세션에 할당하고 실행 전체적으로 검색 성능을 높일 수있는 기능을 가지고 있으며이를 "부하 분산"라고 부르고 있습니다. 또한 PostgreSQL 서버마다 부하를 거는 상태를 조정할 수 있습니다. 구체적으로는 설정 파일에 PostgreSQL 당 상대적인 "무게"를 숫자로 지정할 수 있습니다.

예를 들어 대체로 부하가 높아지기 쉬운 기본 서버의 가중치를 0으로두면 검색 처리가 대기 서버에서만 실행되기 때문에 주 서버의 부하가 낮아 업데이트 성능을 높일 수 있습니다.

그러나 한편으로 "무게"가 물리적 PostgreSQL 서버 (pgpool-II는 DB 노드 ID라는 번호로 식별합니다)에 고정적으로 묶여 있기 때문에 만약 장애 · 승격하여 주 서버의 노드 ID가 변화는 기본 서버에 할당 된 가중치가 바뀌어 버리는 것입니다.

 또한, 대기 서버를 무거운 검색 처리 전용하려는 경우 기존에는 pgpool-II를 통해이라고 그랬다 SELECT가 얼마나 대기 서버에 가버 예측할 수 없으므로 응용 프로그램은 직접 PostgreSQL에 접속하는 것이 필요 했다.

그래서 pgpool-II 3.4에 도입 된이 새로운 부하 분산 지정 방식입니다.

새로운 매개 변수 : app_name_redirect_preference_list

 이 매개 변수는 쉼표로 구분 된 항목을 여러 설명합니다. 하나의 항목은 "응용 프로그램 이름 : DB 노드 번호"입니다. 응용 프로그램 이름은 PostgreSQL의 응용 프로그램 이름을 지정합니다. 예를 들어, "psql"이라든가 정규 표현식을 사용할 수 있습니다. 예를 들어 "abc *"라면 "abc"로 시작하는 응용 프로그램 이름입니다. DB 노드 번호는 0, 1, 2 등의 숫자를 지정하지만, 그 "primary"라면 주 서버를 "standby"라면 대기 서버를 지정한 것입니다. 여러 대기 서버가있는 때에는 「무게」에 따라 어느 하나의 대기 서버가 선택됩니다.

이용 예 : 주 서버가 움직이더라도 항상 검색어는 대기에 던져

방금 같은 장애에서 대기 서버의 DB 노드가 움직 곤란한 경우에는 다음과 같이 지정하여 항상 대기 서버에만 검색 쿼리를 던질 수 있습니다.

 app_name_redirect_preference_list : * : standby

 이용 예 : 무거운 응용 프로그램의 검색은 항상 특정 DB에 던져

"heavy_app"라는 응용 프로그램이 있다고합시다. 이 응용 프로그램은 데이터 분석 응용 프로그램에서 매우 무거운 검색어를 던지기 때문에 전용 DB 서버를 두 번째 대기 준비했습니다. 이에 대한 설정은 다음과 같습니다.

app_name_redirect_preference_list : heavy_app : 2

이용 예 : 마스터 업데이트 응용 프로그램은 항상 기본 서버에서 검색하기

마스터 테이블 업데이트 응용 프로그램을 생각해 봅시다. 이러한 응용 프로그램은 업데이트 된 결과는 즉시 검색 할 수 없다고 등록 데이터의 무결성이 무너져 버릴지도 모릅니다. 이러한 앱은 업데이트 지연이 발생할 수있는 대기 서버가 아닌 주 서버를 검색하도록 싶습니다. 다음과 같이 설정하자.

app_name_redirect_preference_list : master_app : primary

이용 예 : 멀티 테넌으로 응용 프로그램마다 전용의 검색 DB를 제공하고 싶다

자원 관리의 관점에서 사용자 그룹마다 사용하는 검색 용 DB를 나누고 싶은 것이 있습니다. 예를 들어, 사용자 그룹 A는 "db_a"사용자 그룹 B는 "db_b"를 사용하는 것으로합니다. 그러나 같은 서버에 A, B가 접근하면 자원 쟁탈전이되어 버립니다. 그래서 db_a에 검색 서버 1에 db_b에 액세스 서버 2로의 분할하기로 결정합시다. 그 경우의 설정은 다음과 같습니다.

database_redirect_preference_list : db_a : 1, db_b : 2

"database_redirect_preference_list"응용 프로그램 이름이 아닌 데이터베이스 이름으로 부하 분산을 정의하기위한 설정입니다.

또한 app_name_redirect_preference_list과 database_redirect_preference_list 설정이 충돌하는 경우 app_name_redirect_preference_list가 우선됩니다.

yum 저장소 공개

이상 pgpool-II 3.4의 새로운 기능을 소개했습니다.

자, 여기 좋은 소식이 있습니다. 이전부터 rpm 파일을 다운로드 할 수는되어 있었지만, 이번 간신히 yum 저장소를 제공하기 시작하는 단계가되었습니다. rpm 다음의 마이너 릴리즈를 기다리지 않고 버그 수정도 포함되어 있기 때문에 재빨리 안정된 pgpool-II를 사용할 수 있습니다. 꼭 활용 해주십시오.

 (2014 년 12 월 17 일 게재)