[PostgreSQL] DB 이중화 - Pgpool -II - Running mode

1. Master Slave mode

이 모드는 Pgpool-II를 실제 데이터 복제를 담당하는 또 다른 master/slave 소프트웨어(예: Slony-I 및 스트리밍 복제)와 결합하는데 사용된다.

참고 : Slaver 노드수는 1개로 제한되지 않으며 Pgpool-II는 최대 127개의 Slave 노드를 가질 수 있다. Master/Slave 모드는 슬레이브 노드 없이 마스터 노드만 작동할 수 있다.

또한 Load balancing을 master/slave 모드와 함께 사용하여 standby 벡엔드 노드에 읽기 모드로 분산할 수 있다.

Master/Slave 모드에 대해 다음 옵션을 지정해야 한다.

 - master_slave_mode(boolean)

on으로 설정하면 master/slave 모드가 활성화 되며 기본값은 off 이다. 이 파라미터는 서버 시작 시에만 설정할 수 있다.

참고 : master/slave 모드와 replication 모드는 상호 베타적이며 한번에 하나만 활성화 할 수 있다.

 - master_slave_sub_mode(enum)

PostgreSQL 노드간의 데이터 복제에 사용되는 외부 복제 시스템을 지정하십시오. 아래 표에는 파라미터의 유효한 값 목록이 포함되어 있다.

Value	Description
'slony'	Slony-I에 적합
'stream'	PostgrreSQL의 기본 제공 복제시스템에 적합 (Streaming Replication)
'logical'	PostgrreSQL의 기본 제공 복제시스템에 적합 (Logical Replication)

기본 값은 'slony'이며 이 파라미터는 서버 시작시에만 설정 할 수 있다.

2. Replication mode

이 모드에서는 Pgpool-II가 PostgreSQL 백엔드에서 데이터를 복제한다. Load balancing을 복제모드와 함께 사용하여 로드를 백엔드 노드로 분산시킬수도 있다.

다음 옵션은 replication mode에서 Pgpool-II의 동작에 영향을 미친다.

 - replication_mode(boolean)

on으로 설정하면 replication 모드가활성화 되며 기본값은 off 이다. 이 파라미터는 서버 시작시에만 설정 할 수 있다.

참고 : replication모드와 master/slave모드는 상호 베타적이며 한번에 하나만 활성화 할 수 있다.

 - replication_stop_on_mismatch(boolean)

on으로 설정하면 모든 노드가 모든 backend 노드에 전송된 쿼리에 대해 동일한 패킷 종류로 응답하지 않으면, Pgpool-II에 의해 응답이 대부분인 백엔드 노드가 퇴화한다. replication_stop_on_mismatch가 off로 설정되고 유사한 상황이 발생하는 경우 Pgpool-II는 현재 사용자 세션만 종료하지만 백엔드 노드는 퇴화하지 않는다.

참고 : Pgpool-II는 백엔드에서 반환된 데이터를 조사하지 않고 결과 패킷 유형을 비교하는 것만으로 결정을 내린다.

replication_stop_on_mismatch를 활성화하는 일반적인 사용 사례는 백엔드 노드 간에 데이터 불일치를 방지하기 위해서이다. 예를 들어 한 백엔드 노드에서 UPDATE문이 다른 백엔데 노드에서는 실패하는 경우 백안드 노드를 퇴화할 수 있다. 기본값은 off 이며 이 파라미터는 Pgpool-II 구성을 다시 로드하여 변경할 수 있다.

 - failover_if_affected_tuples_mismatch(boolean)

on으로 설정했을 때 모든 노드가 INSERT/UPDATE/DELETE 쿼리에 대해 동일한 개수의 영향을 받는 튜플로 응답하지 않으면, Pgpool-II에 의해 응답이 대부분인 백엔드 노드가 퇴화한다. failover_if_affected_tuples_mismatch가 off로 설정되고 유사한 상황이 발생하는 경우 Pgpool-II는 현재 사용자 세션만 종료하지만 백엔드 노드는 퇴화시키지 않는다.

참고 : 겹칠 경우, 둘 이상의 그룹이 돌일한 노드를 가졌을 때, 마스터 노드(가장 낮은 노드 id를 가진 백엔드 노드)를 포함하는 그룹이 우선순위를 받는다.

기본값은 off 이며 이 파라미터는 Pgpool-II 구성을 다시 로드하여 변경할 수 있다.

 - replicate_select(boolean)

on으로 설정 시 Pgpool-II는 SELECT 쿼리 복제 모드를 활성화한다. SELECT 쿼리는 모든 백엔드 노드에 전송된다. 기본값은 off 이며 이 파라미터는 Pgpool-II 구성을 다시 로드하여 변경할 수 있다.

 - insert_lock(boolean)

on으로 설정 시 Pgpool-II는 그것에 대한 INSERT문이 발행되기 전에 PostgreSQL에 테이블을 자동으로 잠근다. SERIAL 데이터 유형을 사용하여 테이블을 복제할 때, SERAL 컬럼 값은 다른 백엔드에서 다른 값을 받아 올수 있다. 이 문제에 대한 해결방법은 INSERT를 발행하기 전에 테이블을 명시적으로 잠그는 것이다. 따라서 Pgpool-II 테이블을 자동으로 잠그려면 다음 변환을 수행하십시오:

	      INSERT INTO ...
	    

to

	      BEGIN;
	      LOCK TABLE ...
	      INSERT INTO ...
	      COMMIT;

Pgpool-II V2.2 이상에서는 테이블에 SERIAL 컬럼이 있는지 여부를 자동으로 감지하므로 SERIAL 컬럼이 없으면 테이블을 잠그지 않는다.

Pgpool-II V3.0에서 Pgpool-II V3.0.4 까지 테이블을 잠그는 대신 시퀀스 관계에 대해 행잠금을 사용 한다. 이는 VACUUM(autovacuum 포함)과의 잠금 충돌을 최소화 하기 위한 것이다. 그러나 이것은 또 다른 문제로 이어 질 수 있다. 트랜젝션 처리 후 시퀀스 관계에 대한 행 잠금으로 인해 PostgreSQL 내부 오류가 발생함(정확히 말하면, 트랜잭션 상태를 유지하는 pg_clog의 엑세스 오류)

이를 방지하기 위해 PostgreSQL 핵심 개발자들은 시퀀스에 대한 행잠금을 허용하지 않기로 결정했고, 이것은 Pgpool-II를 깨뜨렸다. (PostgreSQL의 고정버전은 9.0.5, 8.4.9, 8.3.16 및 8.2.22로 출시되었다.)

Pgpool-II V3.0.5 이상에서는 pgpool_catalog.insert_lock 테이블에 대한 행잠금을 사용한다. 새로운 PostgreSQL은 시퀀스 관계에 대해 행 잠금을 허용하지 않기 때문이다. 그러므로 사전에 Pgpool-II를 통해 접속되는 모든 데이터베이스에 inert_lock 테이블을 만들어야 한다. inert_lock 테이블이 없는 경우 Pgpool-II는 입력 대상 테이블을 잠근다. 이 동작은 pgpool-II V2.2 와 V2.3 시리즈와 동일하다.

미세조정

insert_lock을 true로 설정하고 테이블 잠금을 획득하지 않을 INSERT 문장의 시작 부분에 /*NO INSERT LOCK*/를 추가하십시오.

insert_lock을 false로 설정하고 테이블 잠금을 획득할 INSERT 문의 시작 부분에 /*INSERT LOCK*/를 추가하십시오.

참고: insert_lock이 활성화 된 경우, PostgreSQL 8.0에 대한 회귀 테스트는 트랜젝션, 권한, 규칙 및 alter_table에서 실패할 수 있다. 그 이유는 Pgpool-II가 규칙 실험을 위해 VIEW를 LOCK하려고 하고, 그것은 다음과 같은 오류 메시지를 생성하기 때문이다.

		! ERROR: current transaction is aborted, commands ignored until
		end of transaction block

예를 들어 트랜젝션 테스트는 존재하지 않는 테이블에 INSERT를 시도하며, Pgpool-II는 PostgreSQL이 테이블에 대한 잠금을 획득 하도록 한다. 원인에 의해 오류가 발생한다. 트랜젝션이 중단되며, 다음 INSERT 문장은 위의 오류메시지를 생성한다.

기본값은 off 이며 이 파라미터는 Pgpool-II 구성을 다시 로드하여 변경할 수 있다.

 - lobj_lock_table(string)