※ PostgreSQL Redundancy Failure Handling Methods(Replication Failover, Failback).
※ Version: Linux 8.10 (Rocky), PostgreSQL 16.4.
장애가 발생하지 않는 것이 최선이지만, "장애가 발생하지 않은 것은 장애 발생 직전의 상태일 뿐"이라는 말처럼, 우리는 장애가 발생할 수밖에 없는 현실을 받아들여야 합니다.
이번 포스팅에서는 이중화된 PostgreSQL장애가 발생했을 때, 어떻게 처리하는지에 대해 다루도록 하겠습니다.
1. Standby 장애 시
Standby 서버 장애 시에는 장애 시간이 오래되지 않았다면, 단순 DBMS 기동만으로도 장애가 해결될 수 있습니다.
하지만, 일정 시간이 경과되어 단순 기동만으로 복제가 지속되기 어렵다면 아래 3번 항목부터 참고 부탁드립니다.
2. Primary 장애 시
Primary 장애 시에도 처리는 간단합니다.
▸ Standby 서버에서 아래 명령어를 수행
→ Recovery(Read-Only) 상태인 PostgreSQL을 Read/Write 상태로 승격시키는 명령어입니다.
pg_ctl promote
▸ Split Brain 방지를 위해 Old Primary 서버의 PostgreSQL 정지
pg_ctl stop
발견만 잘 하셨다면 장애처리는 그렇게 어렵지 않습니다.
이제 급한불은 껐으니, 다시 원상 복구를 해야겠죠?
3. 원상 복구( Failback ) 프로세스
원상 복구 프로세스는 아래 [그림 1]을 참고 부탁드립니다.
다음 내용부터는 프로세스를 참고하시면서 따라와주시기 바랍니다.
4. pg_rewind
pg_rewind는 PostgreSQL 클러스터의 상태를 현재 Primary 노드와 동기화하여 장애 복구 및 페일오버 후 재동기화에 사용하는 도구입니다.
※ Source(현재 Primary) 서버의 User(Role)는 function pg_read_binary_file 접근을 위해 SUPERUSER 권한 필요
※ pg_rewind는 장애가 발생했던 서버에서 수행
▸ SUPERUSER 권한 부여 예시
→ 현재 Primary에서 수행
ALTER ROLE replicator SUPERUSER;
▸ 장애가 발생한 서버에서 pg_rewind 수행
pg_rewind --source-server="host=<current_primary_IP_address> port=5432 user=replicator dbname=postgres" --target-pgdata=/data --progress
[그림 2] 또는 [그림 3]과 비슷한 로그가 출력됐다면 6번으로 넘어가시면 됩니다.
+ pg_hba.conf에서 trust가 아닌 경우 인증을 위해 .pgpass 생성이 필요합니다.
# Host:Port:Database:User:Password
echo "<current_Host>:5432:postgres:replicator:replicator_password" >> ~/.pgpass
chmod 600 ~/.pgpass
5. pg_basebackup
※ pg_rewind 실패 시 동기화를 위해 초기 데이터 복제 필요
※ pg_basebackup은 장애가 발생했던 서버에서 수행
▸ 데이터 영역 삭제 후 pg_basebackup 수행
pg_basebackup -h <current_primary_IP_address> -U replicator -D /data -Fp -Xs -P
6. 후행 작업
▸ standby.signal 파일 생성
touch $PGDATA/standby.signal
▸ conninfo 추가 또는 수정
→ postgresql.conf에 추가 또는 수정
# connection info
primary_conninfo = 'host=<current_primary_IP_address> port=5432 user=replicator password=replicator_password application_name=node01_standby'
▸ DBMS 기동
pg_ctl start
7. Switchover
6번까지 완료하셨다면 현재 상태는 [그림 4]처럼 역복제 상태로 구성이 되어있는게 정상입니다.
이제 장애 이전의 상태로 되돌리는 Switchover를 해보도록 하겠습니다.
▸ 현재 Primary 정지
pg_ctl stop
▸ 현재 Standby를 Primary로 승격
pg_ctl promote
▸ standby.signal 파일 생성
→ Old Primary에서 수행
touch $PGDATA/standby.signal
▸ conninfo 추가 또는 수정
→ Old Primary의 postgresql.conf
primary_conninfo = 'host=<current_primary_IP_address> port=5432 user=replicator password=replicator_password application_name=node02_standby'
▸ DBMS 기동
pg_ctl start
이제 여러분은 장애 처리와 원상 복구 방법에 대해 알게 되었습니다.
하지만, 방법을 안다고 해서 모든 것이 끝난 것은 아닙니다.
장애가 발생했는지 여부를 진단하고 모니터링하려면 여전히 서버에 직접 접속해 수작업으로 장애를 확인하고 복구하는 과정이 필요합니다.
이쯤 되면, 우리에게 무엇이 필요한지 감이 오실 겁니다.
바로, 장애를 자동으로 진단하고, Failover를 자동으로 수행하고 고가용성(HA)을 구현할 수 있는 무언가가 필요합니다.
여기까지 오셨다면, 잘 따라오고 계신 겁니다.
다음 포스팅에서는 PostgreSQL 고가용성(HA) 도구에 대해 알아보도록 하겠습니다.
'PostgreSQL' 카테고리의 다른 글
PostgreSQL: 쉘 스크립트로 PostgreSQL 고가용성(HA) 구현 (2) | 2024.12.11 |
---|---|
PostgreSQL: 고가용성(HA) 도구 비교 - Patroni vs repmgr (0) | 2024.12.10 |
PostgreSQL: DBMS 이중화 구성 방법 (29) | 2024.12.05 |
PostgreSQL: postgresql.conf 파라미터 설정 방법 (33) | 2024.12.02 |
PostgreSQL: RHEL 기반 Linux에 PostgreSQL 설치 방법 (32) | 2024.11.29 |