EDB Failover Manager 5.0의 새로운 기능 두 가지
Bobby Bissett
2025년 5월 23일
Postgres의 다운타임과 서비스 중단을 최소화하는 것은 기업에게 있어 수익 손실, 운영 중단, 사용자 경험 저하를 방지하는 데 매우 중요합니다.
EDB Postgres AI는 이러한 과제를 해결하기 위해 EDB Failover Manager(EFM)를 제공하며, 이는 스트리밍 복제를 기반으로 한 primary-standby 환경에서 고가용성을 지원합니다.
이전 블로그에서는 주요 버전 번호 변경을 유발한 변화들에 대해 설명했으며, 이번 글에서는 EFM 5.0에 추가된 두 가지 주요 기능을 릴리스 노트나 Q1 발표 블로그보다 더 자세히 다룹니다.
1. 스탠바이 데이터베이스 생성 기능
v5.0 주의 사항:
이 명령어를 스탠바이 노드에서 실행할 경우(해당 노드에서 로컬 DB가 실행 중이며 모니터링되고 있는 상태), 명령 실행 후 에이전트를 재시작해야 합니다.
현재 알려진 이슈로 인해 에이전트가 내부적으로 잘못된 상태에 놓일 수 있으며, 이 상태에서 해당 노드가 이후 primary로 승격되었다가 장애가 발생하면 failover가 일어나지 않을 수 있습니다.
이 이슈는 “Idle” 상태 노드(DB가 꺼져있거나 모니터링되지 않는 상태)에는 영향을 주지 않으며, v5.1에서 해결될 예정입니다.
EFM 5.0에는 efm 유틸리티에 **새로운 명령어 efm create-standby**가 추가되었습니다. 이 명령은 pg_basebackup을 사용해 명령이 실행된 노드에 스탠바이 DB를 생성합니다.
이 명령어를 사용하려면 에이전트가 해당 노드에서 이미 실행 중이어야 하며, 이는 해당 노드의 properties 파일에 유효한 값이 설정되어 있어야 함을 의미합니다. (예: 데이터 디렉토리 경로 및 바이너리 위치)
efm create-standby 명령은 다음 작업을 자동으로 수행합니다:
- 현재 primary 노드 파악
- physical replication slot 생성(기존에 존재할 경우 삭제 후 생성)
db.data.dir속성에 명시된 기존 데이터 디렉토리 제거pg_basebackup실행- 새로운 스탠바이 DB 시작
- DB 모니터링 재개
- 옵션 설정 시 위 작업에 대해 사용자에게 실행 여부를 묻는 프롬프트 제공
자세한 사용 방법은 공식 문서에 명시되어 있으며, 실제 명령 실행 시 출력 예시도 포함되어 있습니다.
생성 후 추가 설정 필요 여부
스탠바이 DB 생성 후, 추가 설정이 필요할 수 있습니다.
예를 들어 기존 DB 설정에서 synchronous_standby_names가 설정되어 있었던 경우, 스탠바이 생성 과정에서 이 설정은 유실됩니다.
이 기능은 5.0 버전에서 초기 구현된 것이며, 추후 릴리스에서 synchronous_standby_names를 유지하는 기능 등 추가 개선이 예정되어 있습니다.
2. Synchronous Standby 처리 개선
EFM은 primary DB의 synchronous_standby_names 설정을 감시하며, 설정된 경우 클러스터 변경(standby 추가/삭제 등)에 따라 해당 값을 변경할 수 있습니다.
이를 제어하는 EFM 속성은 다음과 같습니다:
reconfigure.num.sync,reconfigure.num.sync.max:num_sync값 조정reconfigure.sync.primary: 필요 시 primary를 완전히 async 모드로 전환 가능 (단, 다시 sync로 되돌리는 기능은 아직 없음)- (신규)
check.num.sync.period: 일정 주기로 동기 standby 상태를 확인
기존 버전까지의 문제점
EFM 5.0 이전에는 primary 노드가 특정 이벤트(standby 노드 이탈, primary 승격 등) 발생 시에만 num_sync 변경이 필요한지 확인했기 때문에,
타이밍 이슈나 wal_sender_timeout 값의 조정이 필요했습니다. 만약 그 시점에 변경이 필요하지 않다면, EFM은 다시 확인하지 않았습니다.
5.0 개선 사항
EFM 5.0부터는 이벤트 기반이 아닌 지속적 주기적 확인 방식으로 변경되었습니다.
즉, cluster에 변화가 없어도 주기적으로 확인하며 필요 시 primary DB의 설정을 재조정합니다.
예시로, 기존에는 standby 노드가 실패한 것을 감지하고 조치하는 데 **최대 50초(node.timeout 기본값)**가 걸렸다면,
이제는 최대 30초(check.num.sync.period 기본값) 내로 primary가 stuck 상태인지 파악하고 처리할 수 있습니다.
이러한 변경으로 인해 primary가 쓰기를 받지 못한 상태로 오랫동안 방치되는 현상이 줄어듭니다.
또한, standby 노드가 EFM 클러스터에 소속되어 있지 않더라도, primary 에이전트는 설정된 주기마다 이 확인을 계속 수행합니다.
이는 primary의 동기화 요구사항 모니터링을 클러스터 이벤트와 분리함으로써 시스템의 반응성과 안정성을 높입니다.
권한 관련 사항
현재 pg_basebackup, DB 서비스 실행, 에이전트 재시작 등을 위해 efm create-standby 명령은 root 권한으로 실행되어야 합니다.
이는 향후 개선되어 efm 그룹의 구성원 또는 efm 사용자로도 실행할 수 있도록 변경될 예정입니다.
sudo 미사용 환경에서는 db.service.owner 사용자로 명령 실행이 가능하며, 이 경우 sudo 권한이 필요하지 않습니다.
자세한 구성 방법은 문서를 참조하시기 바랍니다. (예: efm 그룹에 DB OS 사용자 추가, DB를 서비스가 아닌 방식으로 실행 등)
