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