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

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

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

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

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

논리 복제란 한 데이터베이스에서 변경된 내용을 스트림으로 다른 서버로 보내는 것을 말한다. PostgreSQL 논리 복제는 WAL 기반으로 논리적 변경 내용을 흘려 보낸다(stream). 논리 복제는 개별 테이블 단위로 복제할 수 있다. 논리 복제를 위해 운영 서버와 복제 서버에서 특별하게 따로 준비해야할 것은 없으며, 여러 복제 서버를 하나의 운영 서버로부터 구축할 수 있다. 논리 복제에 대한 자세한 내용은 30장에서 다룬다. 또한 논리 디코딩을 이용한 제3제공자 확장 모듈 제작을 위한 인터페이스 설명은 48장에서 다룬다.

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

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

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

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

노트북들 사이, 또는 원격 서버들 간 연결 처럼, 서버간 연결 상태가 불안하거나, 네트워크 속도가 많이 느릴 때, 그 자료의 정합성을 유지한다는 것은 꽤 고급 기술이다. 비동기식 다중 운영 서버 환경에서 복제 기능은 다음 문제점을 해결 해야한다. 각 서버들은 독립적으로 운영되어야하며, 주기적으로 트랜잭션 충돌을 피하기 위해 서버간 통신을 해야한다. 충돌이 발생하면, 사용자가 해결 할 수 있는 방법을 제공하거나, 충돌 해결 정책에 따라 자동으로 해결 할 수 있는 기능이 있어야한다. 이 방식을 이용하는 제품으로는 Bucardo가 있다.

동기식 다중 운영 복제 환경에서는, 각 서버가 자료 변경이 가능하고, 그 변경 사항은 다른 모든 서버에 같이 반영 되어야 하나의 트랜잭이 커밋되었다고 처리한다. 많은 쓰기 작업이 있으면 성능을 저하시키는 많은 잠금과 커밋 지연이 일어날 수 있다. 읽기 작업은 아무 서버에서나 할 수 있다. 서버간 통신 작업 비용을 줄일기 위해서, 몇 몇 시스템은 공유 디스크를 사용하기도 한다. 자료 관리 입장에서 본다면, 이 방식이 가장 이상적인 방식이다. 하나의 자료 결과에 대해서도 서버간 자료가 공유되기 때문에, random() 함수와 같은 것은 문제 없이 사용할 수 있다.

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

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

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