PostgreSQL archive_mode on과 always 차이, 운영 환경별 선택 기준

PostgreSQL WAL Archiving

PostgreSQL archive_mode on과 always 차이, 운영 환경별 선택 기준

PostgreSQL의 archive_mode는 WAL 파일을 아카이브할지 결정하는 핵심 설정이다. 특히 on과 always는 Primary 서버에서는 비슷해 보이지만, Standby 서버나 복구 상태에서는 동작 차이가 분명하다.

archive_mode가 하는 일

PostgreSQL은 데이터 변경 내용을 WAL, 즉 Write-Ahead Logging 파일에 먼저 기록한다. 이 WAL 파일을 별도 저장소에 보관하면 장애 복구, 백업 복원, 특정 시점 복구인 PITR에 활용할 수 있다.

archive_mode는 완료된 WAL 세그먼트를 아카이브 대상으로 보낼지 결정하는 설정이다. 실제 파일 복사나 업로드는 archive_command 또는 archive_library가 담당한다.

따라서 archive_mode만 켜는 것으로 충분하지 않다. 운영 환경에서는 아카이브 명령, 저장소 경로, 실패 재시도, 보관 기간, 복구 테스트까지 함께 설계해야 한다.

핵심 요약 archive_mode = on: 일반적인 Primary 서버 WAL 아카이빙에 사용
archive_mode = always: Standby 또는 복구 상태에서도 WAL 아카이빙을 수행할 때 사용
공통 조건: archive_command 또는 archive_library 설정 필요
대표 목적: 백업, PITR, 재해복구, 복제 환경의 WAL 보관

archive_mode = on 동작 방식

archive_mode = on은 PostgreSQL에서 가장 일반적으로 사용하는 WAL 아카이빙 설정이다. Primary 서버가 정상 운영 중일 때 완료된 WAL 세그먼트를 아카이브 대상으로 전달한다.

이 설정은 보통 베이스 백업과 함께 PITR 구성을 만들 때 사용한다. 데이터베이스 전체 백업을 확보한 뒤, 이후 생성되는 WAL 파일을 계속 보관하면 장애 발생 시 원하는 시점까지 복구할 수 있다.

다만 on은 Standby 서버가 받은 WAL을 다시 아카이브하는 용도로는 충분하지 않다. Standby 자체에서 WAL 아카이빙을 보장해야 하는 구조라면 always를 검토해야 한다.

archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'

archive_mode = always 동작 방식

archive_mode = always는 Primary 정상 운영 중에는 on과 큰 차이가 없어 보인다. 차이는 서버가 Standby 모드이거나 archive recovery 상태일 때 나타난다.

always로 설정하면 Standby 서버도 자신이 받은 WAL 세그먼트를 아카이브할 수 있다. 이 WAL은 Primary에서 스트리밍 복제로 받은 것일 수도 있고, 복구 과정에서 아카이브 저장소로부터 복원한 것일 수도 있다.

즉, always는 “Standby에서도 WAL 아카이빙을 수행해야 하는가”라는 질문에 대한 설정이다. 단순 Primary 운영 환경에서는 보통 on으로 충분하지만, Standby를 백업 또는 재해복구 체계의 일부로 활용한다면 always가 필요할 수 있다.

archive_mode = always
archive_command = 'test ! -f /standby_archive/%f && cp %p /standby_archive/%f'

on과 always 차이 정리

두 설정값의 차이는 “아카이빙을 켜느냐 끄느냐”보다 “Standby 또는 복구 상태에서도 아카이빙을 수행하느냐”에 있다. 그래서 운영자는 서버 역할과 백업 구조를 기준으로 선택해야 한다.

구분	archive_mode = on	archive_mode = always
Primary 정상 운영	완료된 WAL 세그먼트를 아카이브한다.	완료된 WAL 세그먼트를 아카이브한다.
Standby 서버	일반적으로 Standby가 받은 WAL을 다시 아카이브하지 않는다.	Standby가 받은 WAL도 아카이브할 수 있다.
복구 상태	복구 중인 WAL을 다시 아카이브하는 용도로 쓰지 않는다.	복구 또는 스트리밍으로 받은 WAL을 다시 아카이브할 수 있다.
주요 사용 목적	Primary 기준 PITR, 백업, 일반적인 WAL 보관	Standby 백업, cascading replication, 별도 Standby 아카이브 구성
운영 난이도	상대적으로 단순하다.	중복 아카이브와 저장소 충돌을 더 주의해야 한다.

언제 on을 선택하면 되나

단일 Primary 서버에서 WAL 아카이빙을 수행하고, 해당 WAL을 백업과 PITR에 활용하는 구조라면 archive_mode = on이 일반적인 선택이다.

Primary에서 생성된 WAL을 안정적으로 별도 저장소에 보관하고, 장애 시 베이스 백업과 WAL을 조합해 복구할 수 있도록 구성하는 방식이다. 대부분의 기본적인 PostgreSQL 백업 설계는 이 구조에서 시작한다.

• Primary 서버에서만 WAL 아카이빙을 수행한다.
• PITR을 위해 WAL 파일을 별도 저장소에 보관한다.
• Standby 서버가 별도의 WAL 아카이브 저장소를 운영하지 않는다.
• 복제 서버는 조회 분산 또는 장애조치 용도로만 사용한다.

언제 always를 선택하면 되나

archive_mode = always는 Standby 서버에서도 WAL 아카이빙을 수행해야 하는 환경에서 선택한다. 대표적으로 Standby에서 백업을 수행하거나, cascading replication 구조에서 중간 Standby가 WAL 보관 책임을 일부 가져야 할 때 필요하다.

예를 들어 Primary와 Standby가 서로 다른 지역에 있고, Standby 쪽에서도 별도 아카이브 저장소를 유지해야 한다면 always가 유용할 수 있다. 장애조치 이후에도 복구 체계를 유지하려면 Standby의 WAL 보관 전략이 중요해진다.

관리자 입장에서 always는 “더 강한 설정”이라기보다 “Standby까지 아카이브 책임을 확장하는 설정”으로 이해하는 편이 정확하다.

• Standby 서버에서 베이스 백업을 수행한다.
• Standby가 자체 WAL 아카이브 저장소를 가진다.
• cascading replication 환경에서 중간 노드의 WAL 보관이 필요하다.
• Primary 장애 후 Standby 승격 상황까지 고려한 재해복구 체계를 만든다.
• 지역별 또는 데이터센터별로 WAL 아카이브를 분리해 보관한다.

주의할 점: always가 무조건 좋은 것은 아니다

archive_mode = always는 Standby에서도 WAL을 아카이브할 수 있게 해주지만, 그만큼 운영상 주의할 점이 늘어난다. 특히 Primary와 Standby가 같은 아카이브 저장소를 바라보는 경우 중복 파일 처리 정책이 중요하다.

같은 WAL 파일명이 이미 저장소에 있을 때 무조건 덮어쓰도록 구성하면 위험하다. 반대로 동일한 파일을 다시 저장하려는 시도가 모두 실패하면 아카이브 프로세스가 계속 재시도하면서 지연이 발생할 수 있다.

운영 환경에서는 아카이브 저장소를 서버별로 분리하거나, 동일 파일 여부를 안전하게 검증하는 방식으로 archive_command를 작성해야 한다. 또한 아카이브 실패는 WAL 파일 증가로 이어질 수 있으므로 디스크 사용량 모니터링도 필요하다.

always는 Standby 아카이빙이 필요한 경우에만 신중하게 적용하는 것이 좋다. 단순히 “더 안전해 보인다”는 이유로 모든 서버에 적용하면 중복 아카이브, 저장소 충돌, 운영 복잡도가 커질 수 있다.

설정 변경 시 확인할 항목

archive_mode는 서버 시작 시 적용되는 설정이다. 값을 바꾼 뒤 단순 reload만으로 적용되지 않을 수 있으므로, 계획된 재시작 절차를 포함해 변경해야 한다.

또한 wal_level이 너무 낮게 설정되어 있으면 아카이빙 요구사항과 맞지 않을 수 있다. 백업, 복제, PITR 구성을 함께 운영한다면 WAL 관련 설정 전체를 한 번에 검토하는 것이 좋다.

점검 항목	확인 내용
archive_mode	on 또는 always 중 서버 역할에 맞는 값을 선택한다.
archive_command	파일 복사, 업로드, 중복 처리, 실패 시 반환값이 안전하게 구성되어 있는지 확인한다.
archive_library	라이브러리 기반 아카이빙을 사용할 경우 archive_command와 충돌하지 않게 설정한다.
아카이브 저장소	Primary와 Standby가 같은 저장소를 쓰는지, 서버별 분리 저장소를 쓰는지 확인한다.
복구 테스트	베이스 백업과 WAL 아카이브만으로 원하는 시점까지 복구되는지 실제로 검증한다.
모니터링	아카이브 실패, WAL 적체, 디스크 사용량, 저장소 지연을 감시한다.

추천 선택 기준

일반적인 운영 기준에서는 먼저 archive_mode = on으로 Primary WAL 아카이빙을 안정화하는 것이 좋다. 이후 Standby 백업, 원격 재해복구, cascading replication처럼 추가 요구사항이 있을 때 always를 검토하는 흐름이 안전하다.

실제 사용 시 중요한 것은 설정값 이름보다 복구 시나리오다. 장애가 발생했을 때 어떤 서버의 백업을 사용할 것인지, 어떤 저장소의 WAL을 적용할 것인지, Standby 승격 후에도 아카이브가 이어져야 하는지를 기준으로 결정해야 한다.

운영 시나리오	권장 설정	이유
단일 Primary 백업과 PITR	archive_mode = on	Primary에서 생성된 WAL만 안정적으로 보관하면 충분하다.
Primary + Standby 조회 분산	archive_mode = on	Standby가 별도 아카이브 책임을 갖지 않는다면 일반적으로 충분하다.
Standby에서 백업 수행	archive_mode = always	Standby 기준 백업 완료와 WAL 보관 흐름을 맞출 수 있다.
cascading replication	archive_mode = always	중간 Standby가 받은 WAL을 별도 아카이브해야 할 수 있다.
지역별 재해복구 아카이브	archive_mode = always	Standby 지역에서도 독립적인 WAL 보관 체계를 만들 수 있다.

결론

PostgreSQL에서 archive_mode = on은 Primary 서버의 일반적인 WAL 아카이빙 설정이고, archive_mode = always는 Standby 또는 복구 상태에서도 WAL 아카이빙을 수행해야 할 때 사용하는 설정이다.

단순 PITR과 Primary 중심 백업 구조라면 on으로 충분한 경우가 많다. 반면 Standby 백업, cascading replication, 원격 재해복구처럼 Standby가 자체적으로 WAL을 보관해야 하는 구조라면 always가 필요할 수 있다.

핵심은 “Primary에서만 아카이빙할 것인가, Standby에서도 아카이빙할 것인가”다. 이 기준으로 선택하면 archive_mode 설정을 더 명확하게 결정할 수 있다.