Hot/Warm Standby Using PITR
WAL 를 사용하여 HA 를 구현합니다.
Hot Standby 의 경우 Read-only queries 만 받을 수 있습니다.
이 방식은 MySQL ( MariaDB ) 의 MASTER - SLAVE (STANDBY) 의 방법과 동일한 HA 구현 방식입니다.
WAL 은 비동기로 로그를 적재합니다.
예를 들면 WAL 레코드는 트랜잭션이 커밋 된 이후 적재 됩니다.
일반적으로 Major 버전이 상이한 PostgreSQL 간에는 Log shipping 이 불가합니다.
Primary 구성 시 유의사항
- Replication 에 pg_hba.conf 구성
Primary 가 접근할 수 있는 권한이 있는지 - max_wal_senders 값
WAL 전송에 문제가 없는지 - Streaming replication 을 사용하는 경우 primary_conninfo 를
hostname ( or IP address) 와 접속을 위한 부가 정보와 함께 libpq connection string 으로 채워야 합니다. - archive_cleanup_command
Standby 에 의해 더 이상 필요 없어진 Primary 의 WAL 로그 파일을 삭제합니다.
pg_archivecleanup 유틸리티를 사용할 수도 있습니다.
Streaming Replication
file-based log shipping 보다 up-to-date 합니다.
이는 WAL file 이 채워지길 기다리지 않고 WAL record 가 생성되면 전송 됩니다.
Streaming replication 은 기본적으로 비동기로 동작합니다.
하지만 file-base log shipping 보다 delay 가 훨씬 작으며, file-based 에서 delay 를 줄이기 위한
archive_timeout 도 필요하지 않습니다.
만약 file-based continuouse archiving 없이 streaming replication 을 사용하는 경우,
반드시 wal_keep_segments 를 master 에 WAL segments 가 너무 빨리 손실되지 않도록 충분한 값을 셋팅해야 합니다.
file-based log shipping standby server 를 streaming replication 으로 전환하기 위해서는
primary 를 바라보는 standby 의 recovery.conf 파일의 primary_conninfo 셋팅을 변경합니다.
REPLICATION 구성 시 필요권한
- LOGIN
- REPLICATION
recovery.conf
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
MONITORING
Gap 은 다음의 정보로 판단합니다.
Primary : pg_current_xlog_location
Standby : pg_last_xlog_receive_location
Dictionary : pg_stat_replication
Synchronous Replication
https://www.postgresql.org/docs/9.1/static/warm-standby.html
Primary 에서 commit 된 변경에 대해 유실이 없는 방식입니다.
Primary 의 commit 은 Standby 에 대한 commit 까지 유보 됩니다.
셋팅을 하기 위해서는 다음과 같은 절차가 필요합니다.
- synchronous_standby_names = non-empty value
- synchronous_commit = on
Primary 에 commit record 가 디스크에 쓰여진 이후, WAL record 는 standby 로 보내집니다.
Standby 는 WAL 데이타가 디스크에 쓰여질 때마다 확인 메시지를 보냅니다.
( wal_receiver_status_interval = 0 으로 셋팅하지 않는 이상 )
standby 에서 백업을 실시하는 경우 synchronous_commit = off 하지 않으면 transaction lock 상태가 발생합니다.
Failover
pg_ctl promote
Hot Standby
서버에 접속하고 read-only 쿼리를 서버가 archive recovery or standby mode 상에서 수행할 수 있습니다.
hot_standby = true 인 경우 서버에 대한 read-only 접속을 받습니다.
Master 의 변경이 Slave 에 전파 될 때 Slave 에서 일어나고 있는 오퍼레이션에 따라 conflict 가 발생합니다.
Conflict 에 대한 증상은 Standby 에 적용 될 오퍼레이션의 대기로 나타납니다.
이를 해소하기 위한 방안은 Standby 에 수행한 오퍼레이션의 cancel 인데 이를 조율하는 파라미터는 아래와 같습니다.
max_standby_archive_delay
max_standby_streaming_delay
위 값에 임계치를 셋팅하고, 그 임계치를 넘는 세션은 종료 됩니다.
위 셋팅과 더불어 statement_timeout 의 셋팅도 비슷한 값으로 셋팅할 수 있을것입니다.
hot_standby_feedback 옵션을 사용해 VACUUM 수행으로 인한 conflict 를 제거할 수 있습니다.
다른 옵션으로 Primary 에 vacuum_defer_cleanup_age 값의 증가가 있습니다.
이를 통해 Standby 에서 쿼리가 수행 될 시간을 좀 더 벌 수 있습니다.
cancel 된 쿼리에 대한 정보는 Standby 의 pg_stat_database 를 통해 볼 수 있습니다.
다음의 파라미터는 Standby 의 값이 Primary 보다 반드시 같거나 더 커야 합니다.
- max_connections
- max_prepared_transactions
- max_locks_per_transactions
Administrator's Overview
다음의 명령어는 recovery mode 중에는 받을 수 없습니다.
- DDL - CREATE INDEX
- PRIVILEGE - GRANT, REVOKE, REASSIGN
- ANALYZE, VACUUM, CLUSTER, REINDEX
결과적으로 Standby 에만 존재하는 인덱스라던가, 통계를 만들 수 없습니다.
만약 이러한 오퍼레이션이 필요한 경우 Primary 에 수행해 전파시켜야 합니다.
Hot Standby Parameter Reference
Primary 에서는 wal_level, vacuum_defer_cleanup_age 를 사용할 수 있습니다.
max_standby_archive_delay, max_standby_streaming_delay 는 Primary 에는 아무 효과 없습니다.
Standby 에서는 hot_standby, max_standby_archive_delay 그리고 max_standby_streaming_delay 를 사용할 수 있습니다.
반면 vacuum_defer_cleanup_age 는 효과가 없습니다.
주의사항
해시 인덱스는 WAL LOGGED 되지 않기에, 현재는 Replication 구성에 사용하기에 적합하지 않습니다.
대형 트랜잭션의 경우 이를 구성하는 서브 트랜잭션이 완료되더라도, 가장 오래 된 트랜잭션의 완료까지
읽기 전용 standby 의 갭을 유발하게 됩니다.
참고사항
Primary 에서 다음이 구성 된 상태에서 Standby 구성이 가능합니다.
- WAL LEVEL 에 대한 셋팅
- Standby 에서 접속할 수 있는 유저 및 권한 ( pg_hba.conf )
Standby 에서는 다음을 고려합니다.
standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
primary_slot_name = 'node_a_slot'
Standby 구성은 온라인 백업을 가지고 구성할 수 있습니다.
위 구성에서 가장 중요한 부분은 primary_conninfo 부분입니다.
환경구성에서는 pg_hba.conf entry 에 대한 에러로 진행이 불가했습니다. ( psql 명령어로는 접근이 가능했음 )