[PostgreSQL 이중화] #3. Ubuntu 22.04 LTS에서 PostgreSQL 14.5 이중화 구성(HA)

■ PostgreSQL 이중화 구성(Active+Standby)

▶ 이번 포스팅에서는 PostgreSQL을 Active+Standby 형태로 이중화 구성하려고 합니다.
- 참고사이트 https://www.postgresql.org/docs/10/different-replication-solutions.html#HIGH-AVAILABILITY-MATRIX
▶ PostgreSQL은 Active/Hot-Standby(Read-Only Active)가 권장되고 있습니다.
▶ 본 포스팅은 Ubuntu 22.04 LTS에서 apt로 설치된 PostgreSQL 14.5 버전 환경입니다.

1. PostgreSQL HA 구성에 사용되는 솔루션은 여러 가지가 있습니다.

1) PostgreSQL + pgpool + WatchDog
2) PostgreSQL + Repmgr
3) PostgreSQL + pg_auto_failover
4) Patroni, Stolon, PGlogical, PGcluster .......
5) 기타 상용 소프트웨어

2. HA 구성 솔루션 선택

- PostgreSQL + Repmgr 방식은 애플리케이션의 변경(또는 pgpool 등의 미들웨어 추가 설치)이 있을 수 있어 제외했습니다.(안정적이라고는 합니다.)
- PostgreSQL + pg_auto_failover 방식은 클라우드에서 많이 선택하는 방식이나 3대 이상의 서버가 필요하여 제외 했습니다.
- PostgreSQL + pgpool-II 방식은 온프레미스(On-premise)에서 가장 많이 사용하는 방식으로 오랜 기간 사용되어 왔으며 많은 자료를 보유하고 있습니다.
: 최근 업데이트 : Pgpool-II 4.3.3, 4.2.10, 4.1.13, 4.0.20 and 3.7.25 officially released (2022/08/18)
※ 다음에 기회가 된다면 pg_auto_failover 구성을 포스팅해 보도록 하겠습니다.

3. PGPOOL-II를 이용한 HA 구성(다음 포스팅에서 설명합니다.)

- Pgpool-II는 PostgreSQL 서버와 PostgreSQL 데이터베이스 클라이언트 사이에 위치하는 미들웨어(프록시 소프트웨어)입니다
- Pgpool-II 주요 기능
1) Connection Poolingv : PostgreSQL은 연결 오버헤드가 있을 수 있는데 이런 pooling을 통해 연결을 재사용해 오버헤드를 줄일 수 있습니다.
2) Load Balancing : 복제 서버에도 SELECT 쿼리를 보내 전체적인 성능 향상을 꾀할 수 있습니다.
3) Automated fail over : DB 서버 장애시 데이터베이스 서버를 분리하고 나머지 데이터베이스 서버를 사용하여 서비스를 합니다.
4) Replication : Pgpool-II 자체 복제 기능(Native replication) 또는 PostgreSQL의 streaming replication을 사용할 수 있습니다.
5) Limiting Exceeding Connections : 동시 접속의 최대 세션에 제한이 있어 최대 세션에 이르면 신규 접속을 거부 할 수 있도록 설정합니다.
- Replication 방식은 WAL 레코드를 사용하는 Streaming 방식을 사용했습니다.
1) WAL 레코드
: 데이터베이스에 적용된 트랜잭션의 레코드입니다. WAL 레코드는 데이터 파일의 변경사항을 설명하는 일련의 레코드로 형식이 지정되고 저장됩니다.

4. 구성 시나리오

1) A서버(Master:192.168.48.129) + B서버(Slave:192.168.48.130) 구성으로 FailOver 테스트
- Archive 설정 및 Streaming 방식을 이용한 Master DB를 Slave DB로 복제
- 실시간 복제 여부 확인
- Master 서버 장애 발생 및 수동 Failover
- Slave 서버 서비스 확인

2) A서버(Master) + B서버(Slave : Read-Only Active) 구성으로 Auto FailOver 테스트
- Pgpool-II + Watchdog 으로 구성
- A서버 읽기+쓰기와 B서버 읽기 서비스 확인
- A서버 장애 발생 및 자동 Failover
- Slave 서버 읽기+쓰기 확인

5. 복제 시스템 구성(Streaming Replicaton 설정)

※ PosgreSQL 설치는 앞선 포스팅( https://berasix.tistory.com/entry/PostgreSQL-Ubuntu-2204-PostgreSQL-%EC%84%A4%EC%B9%98 ) 을 참조하시기 바랍니다.
1) Backup (Archive) 기능
- PostgreSQL은 자체 다중화 기능이 있습니다.
- 기본적으로 PostgreSQL은 Master-Slave-Slave로 3 노드 이상을 권장합니다(Failback 하는 동안 다른 Slave에서 데이터 손실을 방지)
- WAL을 통해 Archive 기능을 제공하고 우리가 이용하게 될 Streaming 방식은 Master에 walsender 프로세스가, Slave에 walreceiver 프로세스가 운영됩니다.

2) Archive 구성하기
- A서버(Master)와 B서버(Slave)의 데이터베이스 관리자 계정(postgres) 및 OS postgreSQL 관리계정(postgres)의 비밀번호를 생성합니다.
2)-1. DB계정

postgres@berasix:~$ psql 
psql (14.5 (Ubuntu 14.5-0ubuntu0.22.04.1))
Type "help" for help.

postgres=# \password postgres 
Enter new password for user "postgres": 
Enter it again:

2)-2. OS계정

root@berasix:~# passwd postgres 
New password: 
Retype new password: 
passwd: password updated successfully
root@berasix:~#

3) Archive 디렉토리 생성(A서버(Master) & B서버(Slave))

root@berasix:~# mkdir -p /data/postgres14-data/archive
root@berasix:~# chown postgres.postgres /data/postgres14-data/archive

4) 복제 계정 생성 (A서버(Master))
: Master DB를 Slave에 복사해 주는 DB계정

postgres=# create user repluser with replication login encrypted password 'replica' connection limit -1;

5) A서버(Master)와 B서버(Slave) DB중지

root@berasix:~# systemctl stop postgresql.service 
root@berasix-2:~# systemctl stop postgresql.service

6) Archive 설정(A서버(Master) : postresql.conf, pg_hba.conf)

※ postgresql.conf와 pg_hba.conf 설정은 앞선 포스팅을 참조하시기 바랍니다. : postgresql.conf 설정 - https://berasix.tistory.com/entry/PostgreSQL-%EC%84%A4%EC%B9%98%EC%99%80-%EC%9A%B4%EC%98%81-2-postgresqlconf-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0 : pg_hba.conf 설정 - https://berasix.tistory.com/entry/PostgreSQL-%EC%84%A4%EC%B9%98%EC%99%80-%EC%9A%B4%EC%98%81-3-pghbaconf-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

6)-1 postgresql.conf 설정

listen_addresses='*'
wal_level=replica
wal_log_hints=on
archive_mode=on
archive_command='test ! -f /data/postgres14-data/archive/%f && cp %p /data/postgres14-data/archive/%f'
max_wal_senders=3
wal_keep_size=16
hot_standby=on
logging_collector=on

 

※ 옵션정보 - wal_level : WAL (Write Ahead Log)에 기록되는 정보(양)를 결정 > minimal: 기본값은 충돌 또는 즉시 셧다운으로부터 복구하기 위해 필요한 정보만 기록 > archive: Wal 아카이브에 필요한 로깅만 추가 (9.6 버전부터는 hot_standby와 archive 모두 replica로 대체) > replica: 9.4버전까지는 hot_standby. 9.6 버전부터는 replica라는 값으로 대체되었고, Slave 노드에서 읽기 전용 쿼리에 필요한 정보를 추가하게 됨. > logical: 논리적 디코딩을 지원하는데 필요한 정보를 추가 - max_wal_sanders : 스트리밍 기반의 백업 클라이언트로부터의 동시 연결 최대 수를 지정. > WAL Sender 프로세서는 max_connections 보다 큰 값을 설정 할 수 없음. 일반적으로 slave의 수+1 로 많이 설정함. - wal_keep_size : Slave 서버가 streaming replication을 위해 과거 로그 파일을 가져와야 하는 경우 pg_wal(10버전 미만 pg_xlog) 디렉터리에 저장되는 과거 로그 조각 파일의 최소 크기 지정. > 즉 Slave 서버를 위해 남겨 놓을 WAL 양을 지정 > 기본값은 0. 0은 비활성화를 의미함 > PostgreSQL 버전 13 이후 wal_keep_segments 파라미터 이름이 wal_keep_size로 변경되었습니다(메가바이트단위) > Maximum 수가 지정 되어 있지 않기 때문에서 서버의 디스크 공간, 그리고 DB 트랜잭션에 따른 wal의 갱신 속도를 고려해서 설정값을 찾아야 함 > wal_keep_size = wal_keep_segments * wal_segment_size (통상 16MB)

6)-2 pg_hba.conf 설정(Slave 서버 접속 권한을 부여)

host    replication     repluser        192.168.48.130/32       scram-sha-256

6)-3 환경설정이 완료되면 Master DB를 기동 합니다.

root@berasix:~# systemctl restart postgresql.service

7) master의 복제 백업(B서버(Slave))
- pg_basebackup 툴을 사용하여 Slave 서버에서 진행합니다.
- Master 서버의 postgresql/data 디렉터리를 통째로 Slave 서버의 postgresql/data 디렉터리로 복제/복원하는 명령으로 Slave 서버 postgresql/data 디렉터리가 비어 있어야 합니다.
- Slave 서버의 기존 data 디렉토리는 mv 시킨 후 진행합니다.

mv /data/postgres14-data/main /data/postgres14-data/main.org
mkdir /data/postgres14-data/main
chown postgres:postgres /data/postgres14-data/main
chmod 0700 /data/postgres14-data/main

- pg_basebackup 명령을 수행 합니다.
: 패스워드는 repluser 생성시 넣은 패스워드입니다.

su - postgres
export LANG=C
pg_basebackup -h 192.168.48.129 -D /data/postgres14-data/main -U repluser -v -P -R -X stream

-R 옵션 : 복제 진행
-X stream : WAL 파일 백업 방법

※ 복제 시 오류 상황 조치 1.ufw 문제 root@berasix:/var/log# ufw allow from 192.168.48.130 to any port 5432 proto tcp 2. pg_hba.conf 설정 문제 (잘못 설정하거 없는 경우 - 필자는 user를 잘못 넣었음)

8) B서버(Slave)의 posgresql data 경로 standby.signal, postgresql.auto.conf 확인
- PostgreSQL 8에서 11까지 복제 구성할때 recovery.conf 파일을 사용하였으나 12.1부터 사라졌으며 파일이 존재하면 오히려 에러가 발생합니다.
- standby.signal은 빈파일로 복제 시 자동 생성됩니다.
: 서버가 targeted recovery mode에서 시작되었음을 의미합니다.
- postgresql.auto.conf은 Master 서버 접속 정보가 들어가 있습니다.

- 향후 Failback을 위하여 postgresql.conf 파일에 trigger_file정보를 넣습니다.(상세 내역은 아래에서 설명)
promote_trigger_file = '/data/postgres14-data/promte_trigger_file.txt'

9) DB 재기동( B서버(Slave) )

root@berasix-2:~# systemctl restart postgresql.service

- Slave DB가 기동되면 Master 서버에는 walsender 프로세스가 Slave 서버에는 walreceiver 데몬이 떠있는 것을 확인할 수 있습니다.

Master 서버의 walsender process

Slave 서버의 walreceiver process

10) db 역할 확인(Primary, Standby)
- DB의 역할이 Primary인 경우 Write+Read, Standby인 경우 Read Only 상태입니다.
- 아래 명령으로 상태를 확인 할 수 있습니다. Primary는 f, Standby는 t로 결과가 나옵니다.
- Master

postgres@berasix:~$ psql 
psql (14.5 (Ubuntu 14.5-0ubuntu0.22.04.1))
Type "help" for help.

postgres=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 f
(1 row)

- Slave

postgres@berasix-2:~$ psql
psql (14.5 (Ubuntu 14.5-0ubuntu0.22.04.1))
Type "help" for help.

postgres=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t
(1 row)

- Master에서 Insert한 데이터는 정상적으로 처리됨을 확인할 수 있습니다.

\c berasix_test;

INSERT INTO beratest VALUES('testdata-2','berasix',202222);

- Master에서 Insert한 데이터는 동기화되어 들어가 있으나 Slave서버에 신규 데이터를 Insert 하면 에러가 발생합니다.

\c berasix_test;

INSERT INTO beratest VALUES('testdata-3','berasix',202233);

 

6. Failover 하기(수동)

- Master 서버의 장애 상태를 가정하고 Slave 서버에 Primary 권한이 부여되고 운영되는지 확인합니다.
1) A서버(Master)에 장애를 일으킵니다.

root@berasix:~# systemctl stop postgresql.service

- Slave의 postgresql.conf 의 promote_trigger_file 파라미터값이 기존에 있어야 합니다.

promote_trigger_file = '/data/postgres14-data/promte_trigger_file.txt'

2) B서버 Master로 승격
- promote_trigger_file 경로에 파일이 존재하면 slave 알아서 master로 승격됩니다.
- promote_trigger_file은 수동으로 생성(pgpool이 구성되면 auto failover)

touch /data/postgres14-data/promte_trigger_file.txt

: 해당파일은 Master로 승격된 후 바로 사라집니다.

3) B서버 Master 서버 승격 확인
- B서버에 쓰기가 되는지 확인 합니다.

INSERT INTO beratest VALUES('testdata-s4','berasix',202244);

 

7. master 복구 및 원복(좋은 방법좀 찾아봅시다)

- Slave 서버를 승격시키고 난 후에는, 기존 마스터 서버의 장애가 복구되고 Failback 되기 전까지 마스터 서버 하나로 운영해야 하는 상황이 발생합니다.
- 기존 Master서버의 복구와 Failback시간이 길어질 것을 대비해 애초에 2개의 복제 서버를 만들어 놓는 것도 방법이 될 수 있습니다.
- Failback을 위해서 특별한 기능이 제공되지 않습니다. Failback(원복)을 위해서는 번거로운 단계를 거쳐야 합니다.
- 작업 중에는 서비스가 중단 될 수 있으므로 꼭 공지 후 작업하는 것을 권장합니다.
1) A서버의 장애를 해결합니다.
2) A서버를 Slave로 구성합니다.( 상단 5-7)~9) 작업 진행 )
3) B서버를 다운 시킵니다.
4) A서버를 Master로 승격시킵니다.(상단 6번 작업)
5) B서버를 Slave로 다시 구성합니다.

※ 참고 및 출처
https://pgpool.net/mediawiki/index.php/Main_Page
https://www.postgresql.kr/docs/13/runtime-config-replication.html
https://www.postgresql.kr/docs/9.5/creating-cluster.html
https://www.postgresql.kr/docs/13/different-replication-solutions.html
https://www.postgresql.org/docs/current/sql-cluster.html
https://www.postgresql.org/docs/current/creating-cluster.html