복제 지연이 낮고 대기 서버에 접속도 되는데, 실제 장애 때 승격해도 되는지 판단하기 어렵습니다.
판정: 복제 지연이나 접속 가능 여부만으로는 통과시킬 수 없습니다. WAL 수신·재생, 계획된 승격, 애플리케이션 쓰기 복구, 논리 복제 슬롯, 되돌리기와 외부 백업을 각각 확인한 뒤 승인해야 합니다. 비동기 복제에서는 대기 서버에 도착하지 않은 트랜잭션이 유실될 수 있고, 복제는 백업을 대신하지 않습니다.
이 글은 PostgreSQL 18 운영 환경의 주 서버와 물리 대기 서버를 맡은 DBA를 위한 검수 기준을 다룹니다.
인프라 담당자는 서버 자원과 네트워크, 노드 격리 조건을 확인할 수 있습니다.
애플리케이션 담당자와 당직 책임자는 연결 복구, 쓰기 검증, 출시 승인 조건을 점검할 수 있습니다.
역할에 맞춰 통과 조건부터 나누기
한 팀이 데이터베이스 포트에 접속해 보는 것만으로 전체 구성을 승인하면, 실제 장애 시 놓치는 항목이 생깁니다. DBA는 WAL 상태와 노드 승격을 확인해야 합니다. 인프라 담당자는 두 서버 간 연결 경로와 장애 격리를 점검해야 합니다. 애플리케이션 담당자는 연결 복구와 쓰기 결과를, 하위 데이터 소비자를 맡은 팀은 논리 슬롯을 확인해야 합니다.
먼저 각 항목의 책임자, 확인 방법, 통과 기준, 실패 시 중단 책임자를 기록합니다. 확인 결과는 “정상” 한 단어로 끝내지 말고, 검사한 노드와 시점, 실행한 명령이나 조회 결과를 함께 남깁니다. 공식 문서의 버전별 안내는 PostgreSQL 버전 정책에서 확인하고, 운영 중인 서버에 적용된 PostgreSQL 18의 소버전과 설정을 기준으로 검사합니다.
DBA가 WAL을 대조해 복제 상태를 판정합니다
PostgreSQL 스트리밍 복제는 송신 연결이 살아 있는지와 WAL이 실제로 대기 서버에 반영됐는지를 따로 확인해야 합니다. 주 서버에서는 pg_stat_replication을 조회해 연결 상태와 sent_lsn, write_lsn, flush_lsn, replay_lsn을 비교합니다. 대기 서버에서는 pg_stat_wal_receiver와 pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn()을 확인합니다. 각 상태값의 의미와 모니터링 방법은 PostgreSQL 18의 대기 서버와 스트리밍 복제 안내를 기준으로 판독합니다.
여기서 핵심은 “연결됨”과 “재생 완료”를 구분하는 것입니다. WAL이 수신됐어도 재생이 따라오지 못할 수 있습니다. 반대로 트래픽이 거의 없는 구간에는 마지막 트랜잭션 재생 시각이 오래됐다는 사실만으로 장애라고 결론 내릴 수 없습니다. LSN의 변화와 실제 쓰기 부하를 함께 확인해야 합니다. 대기 서버가 승격 가능한지는 관리 함수 문서의 승격 관련 안내도 참고해 검증합니다.
PostgreSQL 18 대기 서버의 승격 가능성은 어떻게 확인하나요?
계획된 훈련 전후로 주 서버의 전송 위치와 대기 서버의 수신·재생 위치를 기록합니다. 테스트 쓰기를 발생시킨 뒤 대기 서버의 재생 위치가 그 변경을 반영했는지 확인하고, 역할 전환 후 새 주 서버에서 쓰기가 가능한지도 별도로 검증합니다. 접속만 성공했거나 복제 연결이 유지됐다는 사실은 승격과 쓰기를 보장하지 않습니다.
비동기 복제에서는 주 서버에 기록된 트랜잭션이 대기 서버에 도달하기 전에 주 서버가 중단될 수 있습니다. 이때 장애 전환 시 데이터 차이가 발생할 가능성을 운영 위험으로 기록하고, 허용 가능한 데이터 손실 범위는 서비스 담당자가 정해야 합니다. 복제 동작과 관련 설정은 PostgreSQL 18 복제 설정 문서에서 확인합니다.
복제 슬롯도 따로 살펴봅니다. 슬롯이 WAL을 계속 보유하면 소비자가 멈췄을 때 저장 공간이 고갈될 수 있으므로, 슬롯의 상태와 WAL 보유량, 소비자의 마지막 처리 위치를 확인합니다. 뷰 필드의 의미는 복제 슬롯 상태 문서에 따릅니다. 모니터링 결과가 정상이어도 보유량을 처리할 운영 기준과 대응 책임자가 없다면 검수를 끝내지 않습니다.
인프라 담당자가 노드 간 경계와 격리를 확인합니다
주 서버와 대기 서버가 서로 통신할 수 있는지만 확인해서는 부족합니다. 실제로 사용할 네트워크 경로에서 복제 트래픽이 오가는지, 방화벽과 접근 제어가 필요한 접속만 허용하는지, 한쪽 노드가 고장 났을 때 다른 쪽과 동시에 쓰기 상태가 되지 않도록 격리할 절차가 있는지 확인합니다.
| 판단 항목 | 통과 쪽 | 중단 또는 재검토 쪽 |
|---|---|---|
| 복제 경로 | 실제 운영 경로에서 송수신과 재생을 확인했습니다 | 테스트망에서만 확인했거나 경로가 불분명합니다 |
| 장애 격리 | 이전 주 서버의 쓰기를 막을 담당자와 절차가 정해져 있습니다 | 이전 주 서버가 계속 쓰기 가능한 상태로 남을 수 있습니다 |
| 서버 자원 | 실제 주문 구성의 CPU, 메모리, 저장 장치와 운영체제를 확인했습니다 | 소개 자료만 보고 실제 선택 가능 항목을 확인하지 않았습니다 |
| 네트워크 운영 | 접근 제어와 장애 시 연결 변경 책임자가 정해져 있습니다 | 전용망이나 자동 전환 기능이 제공된다고 가정했습니다 |
서버의 CPU와 메모리, 저장 장치, 운영체제, 접속 방법은 임의의 예시 사양으로 대신하지 않습니다. 실제 선택 가능한 구성은 SFP Cloud 서버 안내에서 대조해야 합니다. 두 대의 서버가 제공된다는 사실만으로 전용 사설망이나 자동 장애 조치가 포함된다고 판단해서도 안 됩니다. 네트워크 경로와 전환 관리는 계약 및 구성에서 확인된 범위만 검수표에 적습니다.
계획된 승격 뒤 애플리케이션 쓰기를 확인합니다
장애 조치 검수는 대기 서버를 승격한 순간에 끝나지 않습니다. 애플리케이션이 새 주 서버로 연결을 바꾸고, 업무상 필요한 쓰기를 완료하며, 결과를 안전하게 처리할 수 있어야 합니다. PostgreSQL 공식 대기 서버 장애 조치 안내를 바탕으로 계획된 훈련 절차를 만들되, 수동 승격을 자동 장애 전환으로 표현하지 않습니다.
PostgreSQL 주 서버 복제 지연이 낮으면 바로 전환해도 되나요?
아닙니다. 지연 지표 하나만으로 전환을 승인하면 안 됩니다. 훈련 직전의 전송·수신·재생 위치를 기록하고, 예상한 WAL이 대기 서버에 적용됐는지 확인합니다. 그다음 계획에 따라 승격을 수행하고, 새 주 서버에서 실제 쓰기와 읽기 방향을 검증합니다. 지연이 낮더라도 대기 서버에 전달되지 않은 트랜잭션이 있을 수 있으며, 복제 지연 측정만으로 데이터 손실 가능성을 없앨 수는 없습니다.
애플리케이션 담당자는 연결 풀과 재접속 설정을 확인합니다. 전환 후 기존 주 서버 주소에 계속 연결하려는 클라이언트가 있는지, 재시도 때문에 같은 요청이 중복 처리될 수 있는지 점검합니다. 테스트는 되돌릴 수 있는 트랜잭션으로 진행하고, 트랜잭션 결과를 확인하기 전에 요청을 다시 보내는 상황도 다룹니다. 단순히 데이터베이스 포트가 열렸는지가 아니라, 애플리케이션이 새 주 서버에서 기대한 쓰기 결과를 확인했는지를 통과 기준으로 삼습니다.
이전 주 서버를 다시 구성에 넣는 절차도 미리 정해야 합니다. 이전 노드가 여전히 쓰기를 받는 상태에서 새 주 서버와 함께 운영되면 데이터 분기 위험이 생깁니다. 접근을 차단하고 노드 역할과 데이터 상태를 확인한 다음, 공식 문서에 맞춰 재동기화 또는 재구성 방법을 결정합니다. 중단 조건과 재투입 권한이 정해지지 않았다면 승격 훈련은 통과가 아닙니다.
PostgreSQL 장애 조치 문서는 데이터베이스 노드를 승격하는 절차를 설명합니다. 애플리케이션의 연결 갱신과 중복 요청 처리는 별도의 책임이며, 노드 승격만으로 업무 복구가 입증되지는 않습니다.
하위 데이터 소비자와 논리 슬롯을 따로 승인합니다
물리 스트리밍 복제와 논리 복제는 같은 항목이 아닙니다. 변경 데이터 캡처나 논리 구독 등 논리 복제 슬롯에 의존하는 소비자가 있다면, 그 소비자와 슬롯을 별도의 검수 대상으로 등록합니다. 사용 여부를 확인하지 않은 채 “해당 없음”으로 처리하지 말고, 담당자가 구성과 소비자 목록을 확인한 뒤 실제로 사용하지 않는 경우에만 적용 제외를 기록합니다.
주 서버 전환 뒤 논리 복제 슬롯은 유지되나요?
항상 유지된다고 단정할 수 없습니다. 논리 복제 슬롯의 장애 조치 지원은 필요한 구성과 동기화 조건에 달려 있습니다. 전환 전에 대상 슬롯이 새 주 서버에서 이어서 사용할 수 있는 상태인지, 소비자가 중단 후 정상적으로 다시 연결되는지 확인해야 합니다. 세부 조건은 논리 복제 장애 조치 문서와 논리 복제 개요를 대조합니다.
검수 기록에는 슬롯별 담당 소비자, 전환 전후 상태, 재개 확인 결과를 남깁니다. 슬롯을 사용하지 않는 팀은 그 사실과 확인 근거를 기록하고, 논리 복제가 없는 구성에 논리 슬롯 검사를 강제로 적용하지 않습니다.
체크리스트와 외부 백업으로 최종 승인합니다
다음 항목을 책임자별로 완료하고, 하나라도 확인되지 않으면 출시 승인을 보류합니다.
- [ ] DBA가 주 서버의 전송 상태와 대기 서버의 수신·재생 위치를 확인했습니다.
- [ ] DBA가 복제 슬롯과 WAL 보유 위험, 소비자 상태를 점검했습니다.
- [ ] 인프라 담당자가 실제 네트워크 경로, 접근 제어, 이전 주 서버의 격리 절차를 확인했습니다.
- [ ] DBA와 당직 책임자가 계획된 승격을 수행하고, 노드 역할과 전환 기록을 남겼습니다.
- [ ] 애플리케이션 담당자가 새 주 서버의 연결 복구와 테스트 쓰기, 중복 요청 처리를 검증했습니다.
- [ ] 하위 데이터 담당자가 논리 복제 슬롯을 확인하거나, 적용 제외의 근거를 기록했습니다.
- [ ] 당직 책임자가 실패 시 중단·되돌리기 책임자와 이전 노드의 재투입 조건을 승인했습니다.
- [ ] 백업 담당자가 서버 밖에 저장한 백업에서 복구가 가능한지 별도로 시험했습니다.
복제본이 있어도 논리적 삭제나 손상된 변경이 복제될 수 있습니다. 저장 장치의 소프트웨어 미러링이나 다른 노드로의 복제도 외부 백업과 복구 훈련을 대신하지 않습니다. PostgreSQL 백업과 복구 안내에 맞춰 백업 보관 위치와 복구 절차를 검증하고, 실제 복구 결과를 기록합니다.
마지막으로 검수 결과와 복구 책임자를 한 문서에 모읍니다. 승인 문서에는 어떤 구성에서 시험했는지, 어떤 조건이면 전환을 중단할지, 데이터 차이가 발견되면 누가 판단할지를 분명히 적습니다. 이후 PostgreSQL 소버전이나 복제 구성, 서버 자원에 변경이 생기면 영향을 받은 항목을 다시 검수합니다.
공유 클라우드 인스턴스는 자원 경합 가능성, 저장 장치 성능 등급에 따른 비용, 디스크 구성이나 운영체제 선택의 제약이 의사결정에 영향을 줄 수 있습니다. 독점 자원과 디스크 구성을 직접 계획해야 하는 장기 운영 환경이라면, SFP Cloud의 서버 요금과 선택 가능한 구성을 확인한 뒤 필요한 메모리와 NVMe, 운영체제, 결제 주기를 실제 상품 정보와 대조하는 편이 합리적입니다. 다만 서버 임대만으로 주 서버·대기 서버 구성이나 자동 전환, 백업 운영이 제공되는 것은 아니므로, 복제 토폴로지와 외부 백업은 운영팀이 직접 설계하고 검증해야 합니다.