25.1. 여러 해결 기법 비교

공유 디스크를 이용한 장애처리는 하나의 물리적인 데이터베이스 자료 파일만 사용하기 때문에, 자료 동기화에 대한 비용을 최소화 할 수 있다. 하나의 디스크 영역을 여러 서버가 공유하는 방식이다. 운영 서버에 장애가 생기면, 대기 서버가 그 디스크 영역을 마운트 해서, 데이터베이스를 복구 모드로 실행한다. 이 방식은 자료 손실이 없이 빠르게 장애처리를 할 수 있다.

이 방식은 일반적으로 네트워크 저장 장치와 같이 하드웨어 기능을 이용해서 공유하는 방식이다. 네트워크 파일 시스템을 이용할 수도 있으나, 그 파일 시스템이 POSIX 모든 기능을 다 수용할 수 있어야한다. (자세한 이야기는 17.2.1절 참조) 이 방식의 한 가지 한계점은 운영서버가 그 디스크 영역을 쓰는 동안에는 대기서버가 전혀 그 디스크 영역을 사용할 수 없는 것이며, 만일 그 디스크 영역에 장애가 발생하면, 두 서버 모두 사용할 수 없다는 점이다.

하드웨어 기능을 이용한 또 다른 방식은 파일 시스템 자체를 복제하는 방식이다. 데이터베이스가 운영되어 데이터 파일의 변경이 있었다면, 그 변경 내용에 대해서 다른 서버에도 파일 시스템 차원에서 동기화한다. 제약 조건은 운영 서버의 변경 순서와 동일한 순서로 파일 시스템이 대기 서버에도 복제되어야한다. 이 방식을 이용한 리눅스 솔루션으로는 DRBD이다.

운영 서버의 미리 쓰는 로그(WAL)의 내용을 대기 서버로 옮겨 그대로 다시 실행해서, 운영 서버 상태와 같은 상태를 유지하도록 하는 방법이다. 운영 서버가 장애로 중지되면, 즉시, 대기 서버가 운영 서버로 운영 될 수 있다. WAL 내용을 전달하는 방식은 동기식 또는 비동기식으로 이루워지며, 데이터베이스 서버 전체를 대상으로 한다. 부분만 복제할 수 없다.

대기 서버를 구축하려면, WAL 내용을 대기 서버로 전달해야하 하는데, 그 전달하는 방법으로 파일 기반 로그 복사 (log shipping)를 하는 방식(25.2절)과 스트리밍 리플리케이션(25.2.5절) 방식, 이 두 방법을 혼용해서 사용할 수 있다. hot standby 서버 구축에 대한 자세한 설명은 25.5절 에서 자세히 다루고 있다.

운영-대기 복제 환경의 기본 기능은 운영 서버에 일어난 자료 변경에 관계된 모든 쿼리를 대기 서버 쪽에도 똑같이 실행해서 운영 서버와 같은 환경을 만든다. 그리고, 대기 서버에서는 읽기 전용 쿼리만 허용해서, 자료 통계 작업 같은 할 수 있도록 이용한다.

이 방식을 이용하는 제품으로는 Slony-I이 있다. 테이블 단위 복제가 가능하며, 여러 대의 대기 서버를 함께 운영 할 수 있다. 대기 서버의 자료 동기화 방식으로 비동기식이 사용됨으로, 장애 발생시 자료 손실이 있을 수 있다.

데이터베이스 서버로 보내는 모든 자료 변경 관련 쿼리를 미들웨어가 가로채서 관리되는 모든 데이터베이스 서버에 동시에 그 쿼리를 실행하는 방식이다. 각각의 서버들은 서로 의존적이지 않게 운영될 수 있다. 읽기 전용 작업이라면, 그냥 한 서버 쪽으로만 작업하면 되고, 쓰기 작업이라면, 모든 서버로 보낸다. 물론 변경 작업 뒤 변경이 반경된 자료를 조회 하고자 한다면, 조회 하는 서버에 변경 작업 완료가 보장되어야한다.

이 방식에서는 random() 함수나, CURRENT_TIMESTAMP, 시퀀스 값과 같이 개별 서버 의존적인 쿼리들에 대해서는 의도되게 않게 일관성을 유지하지 못 할 수 있다. 이런 쿼리 들이 자료 변경 작업에 사용된다면, 전혀 엉뚱한 결과가 나올 수도 있다. 이런 문제에 대한 해결책을 미들웨어가 제시하지 못한다면, 응용 프로그램에서 이런 문제의 해결책을 반드시 찾고, 사용해야한다. 한 방법은 한 서버에 먼저 자료를 반영해서, 반영 결과를 가지고, 다른 서버에 모두 반영하는 방법이 있겠고, 다른 방법으로 자료 변경에 대해서는 특정 시점 복구 방식을 이용한 운영-대기 서버 형태로 구축해서 자료 변경은 반드시 운영서버에서만 일어나도록 미들웨어나 응용프로그램 사용하는 것이다. 또 한 가지 주의할 사항은 한 서버에서 트랜잭션이 시작되어 커밋되었다면, 다른 모든 서버에서도 모두 커밋되어야 그 트랜잭션이 유효하다고 처리되어야한다. 특정 서버에서 롤백된다면, 그 트랜잭션은 모든 서버에서 롤백되어야한다. 이것을 구현하기 위해서는 미들웨어가 2중 커밋 two-phase commit 을 이용할 것이다 (PREPARE TRANSACTION, COMMIT PREPARED 명령). 이 방식을 이용하는 제품으로는 Pgpool-II와 Continuent Tungsten가 있다.

PC와 노트북, PC와 리모트 서버 연결 같이, 데이터베이스 서버간 연결이 항구적이지 않을 때, 그 자료의 정합성을 유지한다는 것은 꽤 고급 기술이다. 비동기식 다중 운영 서버 환경에서 복제 기능은 다음 문제점을 해결 해야한다. 각 서버들은 독립적으로 운영되어야하며, 주기적으로 트랜잭션 충돌을 피하기 위해 서버간 통신을 해야한다. 충돌이 발생하면, 사용자가 해결 할 수 있는 방법을 제공하거나, 충돌 해결 정책에 따라 자동으로 해결 할 수 있는 기능이 있어야한다. 이 방식을 이용하는 제품으로는 Bucardo가 있다.

모든 자료 변경이 모든 서버에 바르게 정리 되어야만, 다음 작업을 할 수 있도록 구축되기 때문에, 자료 변경이 빈번한 환경이라면, 단독 운영 서버 구축 환경 보다 성능이 더 떨어질 수 있다. 읽기 전용 작업이라면, 어느 서버에서도 작업할 수 있다. 서버간 통신 작업 비용을 줄일기 위해서, 몇 몇 시스템은 공유 디스크를 사용하기도 한다. 자료 관리 입장에서 본다면, 이 방식이 가장 이상적인 방식이다. 하나의 자료 결과에 대해서도 서버간 자료가 공유되기 때문에, random() 함수와 같은 것은 문제 없이 사용할 수 있다.

PostgreSQL에서는 이 방식의 복제 기능은 제공하지 않는다. 하지만, PostgreSQL 이중 커밋 two-phase commit (PREPARE TRANSACTION, COMMIT PREPARED) 명령이 이 방식을 구현 하는데 사용될 수 있다.

PostgreSQL은 소스가 공개 되어 있고, 쉽게 확장이 가능하기 때문에, 이것을 가지고, 독자적인 기법으로 장애처리, 복제, 부하 분산 기능을 포함 시켜, 소스를 공개하지 않은 채 상용으로 판매 할 수 있다. 이렇게 몇몇 솔루션들이 판매되고 있다.

자료 분산 방식은 하나의 테이블에 보관되는 자료를 여러 테이블로 나눠서, 각각의 테이블을 각각의 데이터베이스 서버가 처리하는 방식이다. 예를 들어, 런던 지사, 파리 지사 자료를 각각의 서버로 처리하는 방식이다. 만일 런던 지사 자료와, 파리 지사 자료를 합쳐서 조회를 해야한다면, 그 일은 응용 프로그램에서 맡던가, 아니면, 읽기 전용 복제 방식을 이용해서, 서로 자료를 공유하는 하는 방식을 이용한다.

위에서 언급한 방법들은 여러 서버 쪽으로 여러 쿼리를 사용하는 방법이지, 하나의 쿼리를 여러 서버에서 분산 처리하는 방식은 아니다. 이 방식으로, 먼저 중앙 서버가 있고, 한 쿼리는 중앙 서버에서 실행되고, 중앙 서버는 각각의 하위 서버로 쿼리를 나눠서 보내고, 결과를 중앙 서버가 취합해서 사용자에게 보내주는 방식이 사용된다. Pgpool-II 제품이 이런 기능을 사용할 수 있다. PL/Proxy 제품도 이런 방식을 사용할 수 있다.