| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
주 서버가 고장나거나(고가용성), 일부 컴퓨터가 같은 데이터(로드 균형 조정(Load Balancing))를 처리할 수 있도록 하기 위해 데이터베이스 서버는 동시에 작동될 수 있습니다. 데이터베이스 서버는 공동으로 고르게 가동되는 것이 이상적입니다. 정적인 웹페이지를 제공하는 웹서버는 단순히 웹으로부터의 요구로 발생하는 부하를 다수의 기계에 분산하는 것만으로도 간단하게 결합될 수 있습니다. 사실상 읽기 전용(Read-only)의 데이터베이스 서버 또한 비교적 쉽게 결합됩니다. 그러나 대부분의 데이터베이스 서버는 읽고 쓰기가 혼재된 요청을 받아들이며, 읽고 기록하는 서버는 결합이 매우 어렵습니다. 향후 서버에서 읽기 요청이 들어왔을 경우 일관성 있는 결과를 돌려주어야만 하기 때문에 읽기 전용(Read-only) 데이터가 각 서버에 한번 생성되더라도, 어떤 서버든지 상관 없이 기록(write)은 모든 서버에 배포되어야만 합니다.
이 동기화 문제는 서버가 동시에 작동하는 것에 대한 근본적인 어려움이 있다는 것입니다. 이유는 동기화 문제에 대한 모든 경우를 처리할 수 있는 하나의 해법이 존재하지 않기 때문입니다. 다수의 해법이 존재합니다. 각각의 해법은 다양한 방식으로 이문제를 다루고 있으며, 이 특정한 작업 부하와 관련된 영향을 최소화시키고 있습니다.
일부 해법에서는 한 개 서버의 데이터 갱신을 허가함으로써 동기화를 처리하고 있습니다. 데이터를 갱신할 수 있는 서버는 읽고 쓰는 서버 또는, 마스터 서버로 불려집니다. 읽기 전용(Read-only)의 쿼리에 응할 수 있는 서버는 슬레이브 서버라고 합니다. 마스터 서버가 변경될 때까지 사용자가 접근할 수 없는 서버는 스탠바이 서버라고 합니다.
일부 장애 조치(failover)와 로드 균형 조정(Load Balancing) 해법은 동시에 진행됩니다. 즉 데이터를 갱신하는 트랜잭션(transaction)의 경우, 모든 서버가 트랜젝션을 처리할 때까지 처리 대상이 되지 못합니다. 이 사실은 장애 조치(failover)로 인해 어떤 데이터의 손실도 일어나지 않으며, 어떤 서버가 쿼리 대상인지 상관없이 동일한 결과가 모든 load sharing 서버에게 돌아갈 것을 보증합니다. 비동기 해법의 경우, 다른 서버로의 배포 시간과 처리 시간에 있어 지연이 있을 수 있습니다. 몇몇 트랜젝션은 백업 서버를 교환할 때 손실될 가능성이 있으며, load sharing 서버는 오래된 결과를 받을 수도 있습니다. 서버간의 비동기 통신은 동기화가 너무 늦게 이루어졌을 때 사용합니다.
해법은 처리하는 범위에 의해 분류할 수도 있습니다. 어느 해법에서는 전체 데이터베이스 서버만을 처리하지만, 다른 해법에서는 각 테이블 또는 각 데이터베이스 수준을 관리할 수 있습니다.
어떤 장애 조치(failover) 또는, 로드 균형 조정(load balancing)의 선택에서든지, 작업의 효율성은 충분히 고려되어야 합니다. 일반적으로 기능성과 작업 효율성은 상반 관계입니다. 예를 들면, 느린 네트워크의 경우, 완전히 동기화 해법을 적용하면 작업 효율은 반이하가 되지만, 비동기의 해법을 사용하면 작업 효율성에 최소의 영향을 미칩니다.
본 절을 통해 장애 조치(failover), 복제(replication)와 로드 균형 조정(load balancing) 해법을 살펴 보실 수 있습니다.
공유 디스크 장애 조치는 데이터베이스의 사본을 하나만 보유함으로서 동기화 오버헤드를 피할 수 있습니다. 공유 디스크 장애 조치에서는 다수의 서버에 의해 공유되는 하나의 디스크 어레이를 사용합니다. 만약 주 데이터베이스 서버가 작동되지 않는다면, 마치 데이터베이스 파손이 해결된 것처럼 스텐바이 서버에 의해 데이터베이스가 설치되고 실행되어 집니다. 이는 데이터 손실이 전혀 발생하지 않는 빠른 장애 조치를 실현합니다.
공유된 하드웨어 기능은 네트워크상의 기억장치에서 빈번하게 이루어집니다. 네트워크 파일 시스템을 사용하는 것은 가능하지만, 모든 파일 시스템이 충분한 POSIX사양을 가지는지 주의해야만 합니다. 이 방법의 경우 중요한 제한을 가지고 있는데, 공유된 디스크 어레이의 고장, 또는 파손되었을 경우, 주 서버와 스탠바이 서버는 둘다 작동되지 않는다는 것입니다. 또한 스텐바이 서버는 주 서버가 작동되고 있을 때는 공유 기억장치에 접근하지 말아야합니다.
공유된 하드웨어 기능의 개정 버전은 파일 시스템의 사본(replication)이며, 파일 시스템의 모든 변경은 다른 컴퓨터에 설치된 파일 시스템에 반영되어집니다. 한가지 제약은 미러링(mirroring)이 스텐바이 서버가 파일 시스템의 일관된 사본을 가지도록 해야한다는 것입니다. 특히, 스텐바이 서버에 기입하는 것은 마스터 서버와 같은 일관된 순서로 이루어져야 합니다. DRBD는 Linux를 위한 인망있는 파일 시스템 복제(replication) 해법입니다.
웜 스탠바이 서버(Section 23.4를 참조)는 로그 우선 출력 기법(WAL)을 해석하여 현재 상태를 유지할 수 있습니다. 주 서버가 고장나게 되면, 웜 스텐바이 서버는 거의 대부분의 데이터를 보존하고, 신속하게 새로운 마스터 데이터베이스를 가동시킵니다. 이는 비동기이며, 전체 데이터베이스 서버에 의해서만 행해질 수 있습니다.
master-slave 복제 구조에서는 모든 데이터 갱신 쿼리를 마스터 서버로 전송합니다. 마스터 서버는 변경된 데이터를 슬레이브 비동기로 전송합니다. 마스터 서버가 작동하고 있을 경우에 한해서, 슬레이브 서버는 읽기 전용(Read-only) 쿼리에 응답할 수 있습니다. 슬레이브 서버는 데이터웨어하우스 쿼리에 적합합니다.
Slony-I는 복제(replication) 타입의 한 예이며, 각각의 테이블이 처리하는 범위가 되어, 다수의 슬레이브 서버를 지원합니다. 왜냐하면 슬레이브 서버가 비동기로(일괄(batch)처리에 의해) 갱신되어져, 장애 조치(fail over)시 데이터 분실의 위험이 존재하기 때문입니다.
문장에 근거한 복제(replication) 미들웨어에서는 프로그램이 모든 SQL 쿼리를 받아 하나 또는 모든 서버로 전송합니다. 각 서버는 독립적으로 실행합니다. 읽어들이는 작업의 부하를 분산시키기 위해 읽기 전용(Read-only) 쿼리가 하나의 서버로 보내질 수 있는 반면에 Read-write 쿼리는 모든 서버에게 전송됩니다.
쿼리가 변경되지 않고 전송되었거나, random(), CURRENT_TIMESTAMP와 같은 함수와 결과는 다른 서버에서 상이한 값을 가지게 됩니다.
이는 각 서버가 독립적으로 작동하기 때문이며, SQL 쿼리가 실제로 변경된 행(row)를 전송하지 않기 때문입니다.
이와 같은 사실이 허용될 수 없는 경우는, 미들웨어나 어플리케이션에 대해 하나의 서버로부터의 값이 문의되어, 그 결과를 기입해 쿼리로 사용하지 않으면 안되는 경우입니다.
또한, 모든 트랜젝션이 모든 서버에서 처리되거나 중단되는지 또는 두개의 실행 구문(
PREPARE TRANSACTION
and
COMMIT PREPARED
)을 사용하는 지에 대해 주의를 기울여야 합니다.
복제(replication)의 타입에 관해 Pgpool와 Sequoia 예가 있습니다.
동기 멀티 마스터 복제(replication)에서는 각각의 서버들이 요구를 쓸 수 있고, 변경된 데이터는 각각의 트랜젝션이 처리되기 전에 본래의 서버에서 모든 서버로 전송될 수 있습니다.
무거운 입력 활동은 초과적인 잠금(locking)을 발생킬 수 있으며, 작업 효율성이 저하되도록 만듭니다.
실제 입력의 작업 효율성은 단일 서버보다 좋지 않은 경우가 대부분입니다.
Read 요청은 어떤 서버로도 보내질 수 있습니다.
일부 실행은 공유된 디스크를 사용하여 통신에 의한 오버헤드를 줄이고 있습니다.
동기 멀티 마스터 복제((replication)는 주로 작업의 부하를 읽는데 최적이지만, 가장 큰 장점은 어떤 서버라도 입력 요청을 받아들일 수 있다는 것입니다.
여기에는 마스터와 슬레이브 서버 간의 어떠한 작업 부하의 분할을 필요로 하지 않습니다. 또한 데이터 변경은 하나의 서버에서 다른 서버로 보내지게 됩니다.
그리고 random()와 같은 결정되지 않은 함수의 경우도 문제가 일어나지 않습니다.
PostgreSQL는 이와 같은 종류의 복제(replication)를 제공하지 않습니다. 그러나 PostgreSQL 두 처리 구문( PREPARE TRANSACTION 과 COMMIT PREPARED )은 어플리케이션 코드나 미들웨어와 관련해 실행되어질 수 있습니다.
랩탑이나 원격 서버와 같이 규칙적으로 연결되어 있지 않는 서버간에 있어, 데이터의 일관성을 유지하는 것은 도전적인 과제입니다. 비동기 멀티 마스터 복제(replication)을 사용하여 각 서버는 독립적으로 실행될 수 있으며, 주기적으로 다른 서버들과 충돌되는 트렌잭션을 식별하기 위한 통신이 이루어질 수 있습니다. 트랜젝션의 충돌은 사용자 또는 충돌 회피법에 의해 해결될 수 있습니다.
데이터 분할은 테이블을 데이터의 세트로 나누는 것입니다. 각 세트는 오직 하나의 서버에 의해 변경될 수 있습니다. 예를 들면, 데이터는 각각 하나의 서버를 가진 런던과 파리의 영업소에 의해 분할되어질 수 있습니다. 만약 런던과 파리의 데이터가 결합되는 쿼리가 요구되어 질 경우, 어플리케이션은 두 서버에서 쿼리를 진행하거나, 마스터/슬레이브 복제(replication)을 사용해 다른 영업소의 데이터를 읽기 전용으로 보관하여 사용할 수 있습니다.
위의 해법 중 많은 부분은 다수의 서버가 다수의 쿼리를 처리하도록 합니다. 그러나 어떠한 해법도 처리 속도를 향상시키기 위해, 하나의 쿼리를 다수의 서버가 처리하도록 하지 않습니다. 이 해법은 다수의 서버가 하나의 쿼리를 동시에 실행하도록 합니다. 이는 보통 서버 간에 데이터를 분할함으로써 수행되어지며, 각 서버는 맡은 쿼리의 부분을 수행하며, 주서버에서 다시 결합되기 위해 결과가 리턴되며, 이는 다시 사용자에게 돌아갑니다. Pgpool-II는 이와 같은 성능을 가지고 있습니다.
PostgreSQL는 오픈 소스이며, 용이하게 확장이 가능합니다. 대다수의 기업들은 PostgreSQL를 가지고, 새로운 장애 조치(failover), 복제(replication) 그리고 로드 균형 조정(load balancing) 기능을 가진 폐쇄된 소스를 개발하였습니다.