일반적으로 데이터베이스 시스템을 구축할 때, 운영 서버와 대기 서버를 함께 구축한다면, 그 두 서버 환경은 최대한 비슷한 환경으로 구축하는 것이 제일 좋다. 물론 하드웨어 사양은 틀려도 크게 문제가 되지 않으나, 테이블스페이스 문제를 고려했을 때만 보아도, 운영 서버에서 CREATE TABLESPACE 명령으로 테이블스페이스를 조작할 일이 생겼을 때, 대기 서버에서도 똑 같은 작업이 정상적으로 진행되려면, 운영 서버와 같은 디렉터리 구조를 가지고 있어야한다. 물론 운영체제 전체를 운영하는 입장에서 본다면, 하드웨어와 운영체제도 똑 같은 사양이면, 보다 쉽게 운영 할 수 있을 것이다. 하드웨어 머신 아키텍쳐는 같아야한다. 로그 전달 방식의 복제를 사용할 경우, 운영 서버가 64bit이다면, 거기서 만든 로그 파일은 32bit 대기 서버에서는 사용할 수 없다.

일반적으로 로그 전달 방식 복제는 메이저 버전이 서로 다른 PostgreSQL 서버 간은 구현이 불가능하다. 디스크 자료 저장 포멧이 바뀔 경우에, PostgreSQL 개발 그룹에서는 메이저 버전을 바꾸어 릴리즈하는 것이 정책이기 때문이다. 물론 마이너 버전의 서로 틀린 경우는 이 복제 환경을 구축해도 잘 작동할 것이다. 이렇게 서로 마이너 버전이 틀린 경우 해결 하기 힘든 예상치 못한 문제가 발생할 수도 있기 때문에, 가능하다면, 운영 서버와 대기 서버의 버전을 최대한 같은 것을 사용하길 권장한다. 마이너 버전 업데이트가 필요하다면, 이 작업의 가장 좋은 순서는 먼저 대기 서버 쪽을 업데이트해서, 옛 버전의 WAL 파일을 잘 적용할 수 있는지 부터 확인하고, 운영 서버를 업데이트한다.

서버가 실행 될 때, 그 데이터 디렉터리 안에, standby.signal 파일이 있으면 대기 서버로 작동한다.

서버가 대기 모드로 실행되면, 서버는 마스터 서버에서 받는 WAL 파일을 계속해서 자신의 서버에 반영하는 작업만 한다. 대기 서버는 운영 서버가 보내는 파일을 보관해 두는 디렉터리에 새 WAL 파일이 있는지 확인해서, 새 WAL 파일을 반영하는 방식(warm standby)도 있고 (restore_command 참조), TCP 연결 방식을 이용해서 운영 서버와 직접 연결하고, 커밋된 트랜잭션을 즉시 대기 서버로 반영하는 방식(스트리밍 복제)도 있다. 또 내부적으로 보면, 대기 서버의 pg_wal 디렉터리에 있는 WAL 파일을 참조하는 경우도 있다. 이 경우는 스트리밍 복제 환경에서 운영 서버에서 보낸 트랜잭션을 미쳐 반영하기 전에 대기 서버가 중지 되었다가 다시 실행될 경우에 일어난다. 물론 관리자가 직접 pg_wal 디렉터리에 직접 WAL 파일을 두고 서버를 실행할 수도 있다.

대기 서버가 실행되면, 제일 먼저 restore_command 설정값에 지정된 명령어를 진행한다. 적용 해야할 WAL 세그먼트 파일이 아카이브 디렉터리에 있는지 확인하고 있으면 차례대로 적용한다. 이 작업이 끝나고 더 이상 적용할 파일이 없으면 restore_command 설정값에 지정된 명령은 실패로 끝나야한다. 그러면, 복구 환경이 스트리밍 복제 방식이라면, 운영 서버 쪽으로 접속 해서, 운영 서버가 데이터베이스 연결을 통해 보내는 트랜잭션들을 자신의 pg_wal 디렉터리 내 해당 WAL 로그 파일에 추가한다. 다음부터는 서버가 알아서 해당 작업을 수행하고, 커밋 되었다고 기록하고, 체크포인트 작업을 하는 등 일련의 자료 변경 작업을 수행한다. 반면, 복구 환경이 warm standy 방식이라면, restore_command 설정값에 지정된 명령이 실패로 끝나면, 원하는 WAL 세그먼트 파일이 새롭게 생길 때까지 기다렸다가 생기면, 다시 작업을 하고, 또 더 이상 없으면 실패로 끝나면서 대기하는 작업을 반복한다. 이 반복 작업은 서버가 중지되거나, 대기 작업을 이제 그만 하고 스스로 독립된 운영 서버 역할을 하라고 알려주는 트리거 파일이 생기기 전까지 계속 반복된다.

대기 모드는 pg_ctl promote 명령을 실행하거나, pg_promote() 함수를 호출 하거나, 트리거 파일(promote_trigger_file 설정값에 지정한 파일)이 생기면 끝난다. 물론 적용해야할 WAL 파일이, 아카이브 디렉터리에 아직 있거나, pg_wal 디렉터리 내에 있다면, 이것들을 모두 적용하고 대기 모드를 끝낸다. 이때 스트리밍 복제를 위한 운영 서버와의 연결도 더 이상 재시도하지 않는다.

첫번째 작업은 대기 서버로 보낼 WAL 세그먼트 파일을 그냥 버리지 않고, 달리 처리하는 설정을 해야한다. 이 방법에 대한 자세한 이야기는 25.3절에서 하고 있다. 그냥 버리지 않고 다르게 처리 한다는 것은 그 WAL 세그먼트 파일이 운영 서버가 중지되어도 대기 서버가 사용할 수 있는 위치로 옮겨 놓는다는 것을 의미한다. 이 방법에는 여러 방법이 있을 수 있다. 단순히 네트워크 드라이브에 복사를 하는 방법도 있을 수 있고, FTP를 이용해서, 대기 서버의 원하는 디렉터리로 업로드 하는 방법도 있고, 백업용 테이프 드라이브 쪽으로 보내는 방법도 있을 것이다. 중요한 것은 운영 서버를 더이상 사용할 수 없을 때도 대기 서버는 그 WAL 세그먼트 파일들을 사용할 수 있어야한다는 점이다.

스트리밍 복제 방식을 사용하려면, 대기 서버에서 요청하는 데이터베이스 접속을 허용하도록 설정하는 작업을 해야한다. 총 세가지 작업인데, 첫번째는 접속 계정의 권한을 복제 기능을 사용할 수 있도록 해야하고, 두번째는 pg_hba.conf 파일에 대기 서버가 운영되는 호스트가 등록되어야하고, 그곳에 데이터베이스 항목은 replication으로 지정되어야하며, 세번째는 서버 환경 설정에서 max_wal_senders 값이 대기 서버의 연결수 만큼은 지정되어야한다.

대기 서버를 실행하려면, 먼저 운영서버의 베이스 백업을 준비해야한다. 이것에 대한 자세한 이야기는 25.3.2절에서 다룬다.

대기 서버를 구축하려면, 먼저 운영서버의 베이스 백업 자료를 복원해야한다(25.3.4절 참조). 다음 대기 서버의 데이터 클러스터 디렉터리 안에 standby.signal 파일 파일을 만든다. restore_command 설정으로 아카이브된 WAL 조각 파일들을 대기 서버로 복사하는 명령을 restore_command 설정값으로 지정한다. 고가용성을 고려해서, 대기 서버가 여럿 있는 경우, 다른 대기 서버들이 failover 로 새롭게 운영 되는 주서버의 타임라인을 따르도록 recovery_target_timeline 설정값을 latest 로 설정할 수도 있다. (기본설정값이다.)

스트리밍 복제 기능을 사용하려면, primary_conninfo 설정값을 지정해야한다. 이 값은 libpq 라이브러리에서 사용하는 데이터베이스 연결 문자열이다. 이 값에는 운영서버의 호스트 이름(또는 IP 주소)은 반드시 지정해야하며, 그 외 접속에 필요한 정보를 지정한다. 운영 서버에서 데이터베이스 접속을 계정 비밀번호를 입력해야한다면, 이곳에 그 비밀번호를 지정하거나, 대기 서버를 실행하는 시스템 계정의 홈 디렉터리에 .pgpass 파일에 지정하면 된다.

만일 대기 서버가 고가용성을 고려해서 구축되는 경우라면, 대기 서버의 서버 환경도 운영 서버와 똑같이 아카이브 모드로 운영되어야하며, 서버 접근 인증 설정도 운영 서버와 같아야한다. 왜냐하며, 운영 서버 장애가 발생하면 이 대기 서버가 운영 서버 역할을 해야하기 때문이다.

운영 서버에서 넘겨 받은 WAL 파일을 사용한다면, archive_cleanup_command 설정으로 더 이상 필요없는, 이미 대기 서버에 반영이 완료된 파일을 지워서, 디스크 공간을 확보 할 수도 있다. 이 설정값으로 pg_archivecleanup 명령을 이용하면, 보다 쉽게 이 작업을 할 수 있다. 이 명령에 대한 자세한 설명은 pg_archivecleanup 명령 도움말을 참조하라. 반면, 대기 서버가 운영 서버의 백업 용도로 구성한다면, 운영 서버의 베이스 백업 뒤로 생긴 모든 WAL 세그먼트 파일을 지우지 않는 것이 좋다. 설령 그 파일이 대기 서버로 모두 반영되었다 하더라도, 어떤 방식으로 다시 복원 작업을 할지 모르기 때문에 모두 남겨두라. 물론 베이스 백업이 바뀌었다면, 이 베이스 백업 이전 로그 파일들은 기록 보관용적인 자료가 아니라면 삭제해도 무방할 것이다.

윗 내용을 참고해서, 대기 서버로 구축하기 위한 설정은 다음과 같다:

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000'''
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

대기 서버는 다중으로 구성할 수 있지만, 스트리밍 복제 방식을 이용한다면, 운영 서버의 max_wal_senders 환경 설정값으로 이 대기 서버 모두가 동시에 접속 할 수 있도록 충분한 연결을 확보해야한다.

스트리밍 복제는 WAL 세그먼트 파일 전달 방식보다 운영 서버의 자료 상태를 거의 실시간으로 동기화 한다. 대기 서버는 운영 서버로 접속해서, WAL 레코드 단위로 그 정보를 가져오고, 그것을 반영하기 때문이다. WAL 세그먼트 파일 전달 방식을 이용하면, 운영 서버가 그 로그 파일을 다 채워서 다른 로그 파일을 쓰겠다고 하는 시점에 대기 서버로 옮겨지기 때문에, 그 동안은 대기 서버와 운영 서버 사이의 자료 불일치가 일어난다.

스트리밍 복제 방식은 기본적으로 비동기식으로 이루워진다. (26.2.8절 참조) 그래서, 운영 서버와 대기 서버간의 자료 불일치가 약간 있을 수는 있다. 하지만 대기 서버와 운영 서버 사이의 네트워크 환경이 양호하고, 대기 서버의 성능이 좋다면, 파일 기반 로그 전달 방식과는 비교도 안될 만큼 1초 미만의 지연시간이 생긴다. 운영 서버와 대기 서버가 같은 네트워크 대역대 안에 있다면, 거의 실시간으로 동기화 된다. 스트리밍 복제 환경에서는 archive_timeout 설정값을 짧게 해서, 자료 손실을 줄이겠다는 설정이 필요 없다.

파일 기반 로그 전달 방식을 함께 사용하지 않고, 단지 스트리밍 복제 기능만 사용한다면, 운영 서버에서 반드시 wal_keep_size 환경설정값을 지정해서, 아직 대기 서버로 반영되지 못한 WAL 파일을 남겨두는 최대 개수를 지정해 주어야한다. 운영 서버에는 WAL 파일을 재활용하기 때문에, 대기 서버의 중지 시간이 길어져, 이 대기 서버로 반영되지 못한 WAL 파일이 계속 쌓이면 사용할 수 있는 디스크 공간이 점점 줄어들 것이다. 또한 대기 서버의 중지 시간이 아주 길어졌고, 운영 서버쪽에서는 더 이상 로그를 보관할 수 없어 재활용 해 버렸다면, 더 이상 동기화 할 자료를 찾지 못하기 때문에 다시 대기 서버를 구축 해야한다. 만일 운영 서버 쪽에서 WAL 세그먼트 로그 파일을 대기 서버 쪽으로 보내는 설정을 해 두었고, 대기 서버 쪽에서 그 파일을 사용할 수 있는 환경이라면, wal_keep_segments 설정은 굳이 필요가 없다. 대기 서버 쪽으로 처리되어야할 WAL 로그 파일들은 로그 전달 설정을 통해서 이미 대기 서버 쪽으로 옮겨졌기 때문에, 충분히 운영 서버의 자료와 동기화 할 수 있을 것이다.

이런 이유로, 스트리밍 복제 기능을 이용 할 때도, 먼저 대기 서버에서 파일 기반 로그 전달 기능도 함께 설정 하는 것이 좋다. 자세한 것은 26.2절에서 설명하고 있다. 파일 기반 로그 전달 방식에서 스트리밍 복제 방식으로 바뀌려면, primary_conninfo 설정값에 접속할 운영 서버의 정보를 지정하면 된다. 운영 서버에서는 대기 서버가 접속할 수 있도록 listen_addresses 환경설정값이 바뀌어야하며, pg_hba.conf 파일에 대기 서버에서의 접속을 허용할 있도록 지정하며, 그 때 사용할 데이터베이스 이름은 replication 으로 지정한다. 자세한 사항은 26.2.5.1절 을 참조하라.

또한, 운영 서버 입장에서 클라이언트의 TCP 연결이 끊겼을 경우, 빠르게 그 소켓을 정리해서, TCP 연결을 원할하게 하기 위해, tcp_keepalives_idle, tcp_keepalives_interval, tcp_keepalives_count 설정값을 조정할 수도 있다.

또한 대기 서버의 최대 동시 연결수도 지정해야한다. (max_wal_senders 환경설정값 항목을 참조).

대기서버는 먼저 운영 서버에서 넘겨 받은 WAL 세그먼트 파일을 모두 자신의 서버에 적용하면, primary_conninfo 설정값에 지정한 운영 서버로 접속한다. 이 접속이 성공하면, 대기 서버는 walreceiver 프로세스를 만들어 운영 서버의 walsender 프로세스에서 보내는 트랜잭션 정보를 하나씩 받아서 자신의 서버에 적용한다.

# 아래 "foo" 는 스트리밍 복제를 위해 대기 서버가 사용할 운영 서버로 접속할
# 데이터베이스 사용자 이름이다. 인증 방식은 md5 비밀번호 인증을 사용한다.
# 그 대기 서버의 IP는 192.168.1.100 딱 하나다.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5

# 이 대기 서버는 호스트 IP 192.168.1.50, 포트 5432 운영 서버로
# "foo" 사용자, "foopass" 비밀번호로 접속한다.
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

대기 서버가 운영 서버로부터 복제 해야 할 내용을 미처 다 복제 하기도 전에 운영 서버가 자신의 트랜잭션 로그를 버리는 문제를 막을 수 있는 방법으로 복제 슬롯을 이용하면 된다. 또한 대기 서버와 운영 서버간 연결이 끊겨서 복구 충돌이 발생하는 상황에서도 운영 서버의 자료가 지워지는 것을 방지 할 때 이 기능을 이용할 수 있다.

복제 슬롯을 사용하지 않는 방법으로, wal_keep_size 환경 설정값에 지정된 크기 만큼 보관하는 방법과 archive_command 설정으로 WAL 조각 파일을 따로 보관하는 방법이 있다. 그런데, 이 방법은 남겨 놓은 WAL 조각들보다 더 오래된 것들을 필요로 하는 경우가 종종 생긴다. 이런 문제를 피해가는 방법으로 복제 슬롯을 사용해서 pg_wal 디렉터리 내에 대기 서버로 보내지 못한 WAL 조각 파일을 남겨 놓을 수는 있으나, 계속 남겨 놓게 되면 또 문제가 생긴다. 이 때는 max_slot_wal_keep_size 설정으로 남겨 놓을 최대 크기를 제한 할 수 있다.

In lieu of using replication slots, it is possible to prevent the removal of old WAL segments using wal_keep_size, or by storing the segments in an archive using archive_command. However, these methods often result in retaining more WAL segments than required, whereas replication slots retain only the number of segments known to be needed. On the other hand, replication slots can retain so many WAL segments that they fill up the space allocated for pg_wal; max_slot_wal_keep_size limits the size of WAL files retained by replication slots.

비슷하게, 이전 버전에서도 제공하고 있던 hot_standby_feedback 또는 vacuum_defer_cleanup_age 설정 값을 이용해서 vacuum 작업으로 인한 관계된 자료가 지워지는 문제점을 막을 수는 있었지만, 대기 서버 단절 시간이 길어 질 때는 방법이 없었다. 복제 슬롯은 이런 단점을 극복했다.

postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  slot_name  | lsn
-------------+-----
 node_a_slot |

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
  slot_name  | slot_type | active 
-------------+-----------+--------
 node_a_slot | physical  | f
(1 row)

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
primary_slot_name = 'node_a_slot'

순차적 복제 cascading replication 기능은 대기 서버가 마치 이어 달리기처럼 다른 대기 서버의 스트리밍 복제를 할 수 있도록 하는 것이다. 이 기능은 스트리밍 복제에 필요한 운영 서버의 부하를 최소화 할 수 있다.

대기 서버가 트랜잭션 로그를 받음과 동시에 또 다른 대기 서버로 보낼 수 있음을 의미한다. 이렇게 전달하는 방식을 순차적 복제라고 하며, 운영 서버에서 복제 정보를 받아오는 서버를 업스트림 서버라고 하고, 그 서버로부터 정보를 받아가는 서버를 다운스트림 서버라고 한다. 순차적 복제에서 다운스트림 서버수는 제한이 없다. 마치 기존 하나의 운영 서버에 여러 대의 대기 서버를 연결해서 복제를 구현 하는 것 같다.

순차적 복제에서는 운영서버에 만든 트랜잭션 로그 레코드를 전달하는 것뿐만 아니라, 아카이빙 모드로 보관된 로그들도 함께 전달한다. 그래서 업스트림 서버와의 연결이 끊기더라도, 자신의 트랜잭션 로그는 다운스트림 서버 쪽으로 모두 보낸다. (하위 노드 입장에서 보면 자신의 상위 노드가 대기 서버에서 운영 서버로 전환되어 새로운 트랜잭션 로그를 만들어도 여전히 복제를 할 수 있음을 뜻한다. - 옮긴이)

순차적 복제 기능은 현재 비동기식으로 구현되었다. 동기식 복제 설정(26.2.8절 참조)을 하더라도 순차적 복제 기능을 이용한다면, 그 설정은 무시된다.

대기 서버의 hot_standby_feedback 설정은 순차적 복제 환경에서도 그대로 작동 한다.

업스트림 대기 서버가 새로운 운영 서버가 된다면, 다운스트림 대기 서버의 recovery_target_timeline 설정값이 'latest' (기본값)이면 새 운영 서버로부터 복제를 계속한다.

순차적 복제 기능을 사용하려면, 업스트림 서버 쪽에서는 기본적인 복제 기능을 위해 운영 서버 쪽에서 설정했던 것을 그대로 설정하며 (max_wal_senders, hot_standby 설정값 조정하고, 호스트 기반 인증 설정을 한다), 다운스트림 대기 서버는 기존 대기서버 설정과 같이 하면서 primary_conninfo 설정에서 업스트림 대기 서버 정보를 지정하면 된다.

PostgreSQL 스트리밍 복제 기능은 기본이 비동기식이다. 이 말은 운영 서버가 장애로 멈추어, 대기 서버가 운영 서버로 역할 전환 작업(failover, 장애처리)을 할 때, 운영 서버와 대기 서버 사이 자료 동기화에 지연이 있었다면, 그 만큼의 자료를 잃어버린다는 뜻이다.

동기식 복제 방식은 하나의 트랜잭션을 하나 이상의 대기 서버에 반영하고, 그 결과를 운영 서버가 확인하는 방식이다. 이 방식은 트랜잭션 커밋으로 제공하는 기본 자료 안정성을 더 확장한 것이다. 이것을 컴퓨터 과학 이론에서는 이중 안전 복제라 하고, synchronous_commit 설정값이 remote_write 인 경우는 그룹 안전, 또는 단일 안전 복제라한다.

동기식 복제 기능을 이용하면, 운영 서버, 대기 서버 모두 트랜젹션이 트랜잭션 로그 파일에 기록되었을 경우에만 정상처리 되었다고 판단한다. 이렇게 하면, 운영 서버가 중지 되어도 대기 서버에서 자료 손실이 일어나지 않는다. 이렇게 해서, 자료의 안정성을 제공하지만, 대기 서버의 작업 완료 응답을 확인하는 작업까지 포함되어 운영 서버의 복제 기능을 이용하는 비용이 상대적으로 늘어난다. 직렬화 된 트랜잭션 전달 작업은 현재 전달할 트랜잭션의 응답을 받아야 다음 작업을 진행하기 때문에, 최소한 그 만큼의 지연시간이 생길 수 밖에 없다.

읽기 전용 트랜잭션과, 트랜잭션 롤백은 대기 서버의 응답을 받지 않는다. 최 상위 레벨의 트랜잭션에 대해서 응답을 확인하지, 그 하위 레벨 트랜잭션인 서브트랜잭션에 대해서는 응답을 확인하지 않는다. 대량 자료 등록이나, 인덱스 생성 작업 같이 시간이 많이 걸리는 트랜잭션에 대해서도 대기 서버의 마지막 커밋 메시지를 확인하지 않는다. 이중 커밋(2PC)에 대해서는 모든 작업에 대해서 확인한다.

A synchronous standby can be a physical replication standby or a logical replication subscriber. It can also be any other physical or logical WAL replication stream consumer that knows how to send the appropriate feedback messages. Besides the built-in physical and logical replication systems, this includes special programs such as pg_receivewal and pg_recvlogical as well as some third-party replication systems and custom programs. Check the respective documentation for details on synchronous replication support.

synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

연속된 트랜잭션 로그 조각들을 따로 보관하는 작업은 두 가지 상황을 고려해 볼 수 있다. 하나는 운영 서버에서만 따로 보관하는 작업(아카이빙)을 하는 경우이고, 다른 하나는 대기 서버도 자체적으로 동시에 그 작업을 중복해서 하는 것이다. 대기 서버에서도 아카이브 작업을 하려면, 대기 서버의 archive_mode 설정값을 always로 지정한다. 이 환경이면, 대기 서버 쪽으로 트랜잭션 로그 조각 파일이 전달 되거나, 스트리밍 복제 방식으로 트랜잭션 로그들이 전달 된 경우 모두 적정한 트랜잭션 로그 따로 보관하기 작업을 진행한다. 이렇게 트랜잭션 로그 조각 파일을 중복해서 보관하는 것은 쉽게 지정할 수 있으나, 운영 서버와 대기 서버에 각각 저장된 같은 이름의 파일 내용도 똑같다고는 보장할 수 없다. 그래서 완전한 트랜잭션 로그 조각 파일의 연속성을 보장하려면, archive_command 설정값을 보다 세밀하게 신경 써야 한다. 첫번째는 일단 같은 이름의 파일이 있는 경우 덮어쓰는 것은 막아야 하며, 두번째 이런 작업에 대한 예외처리가 정상적인 작업이었음을 서버 쪽으로 알려주어야 한다(이 작업의 쉘 반환 값이 0여야 한다).

archive_mode 설정값이 on으로 지정하면, 대기 서버로 실행되고 있는 경우나, 운영 전 복구 모드인 경우 트랜잭션 로그 아카이브 작업은 하지 않는다. 대기 서버가 운영 서버로 전환되면, 그때부터 아카이브 작업을 시작한다. 하지만, 따로 설정하지 않았다면, WAL 파일을 아카이브 하지 않고, 타임라인 내역 파일도 스스로 만들지 않는다. 이 때문에, 연속된 트랜잭션 로그 파일을 따로 보관하려면, 이전 운영 서버가 종료되는 시점의 모든 트랜잭션 로그가 따로 보관 되어야 한다 (아카이브 되어야 함). 스트리밍 복제 환경에서 운영 서버의 아카이브 작업이 완료되기 전에, 대기 서버가 운영 서버로 전환되면, 트랜잭션 로그의 아카이브 작업은 연속성을 잃게 될 수도 있다. 물론, 서버가 시작할 때 트랜잭션 로그를 재실행해야 하는 복구 모드 작업이 없다면, archive_mode 설정이 on 이나, always 모두 같은 트랜잭션 로그 아카이브 연속성을 보장한다.