PostgreSQL HA 클러스터에서 일반적인 장애 조치 및 연결 오류 문제 해결

PostgreSQL 고가용성(HA) 클러스터는 두 가지 방식으로 실패합니다. 때로는 데이터베이스 장애 조치 자체가 중단됩니다. 복제본이 승격되지 않거나, 두 노드가 기본 노드에 대해 동의하지 않거나, 새 기본 노드가 쓰기를 수락할 수 없는 경우입니다. 다른 경우에는 데이터베이스는 정상이지만 풀러, DNS 레코드, 가상 IP, 방화벽 규칙 또는 클라이언트 재시도 루프가 승격을 따르지 않았기 때문에 애플리케이션이 여전히 연결할 수 없습니다.

인시던트가 발생하면 해당 계층을 신속하게 분리하세요. 먼저 질문하세요. 쓰기 가능한 기본 노드가 정확히 하나 있습니까? 그런 다음 질문하세요. 풀러가 기본 노드에 도달할 수 있습니까? 그런 다음 질문하세요. 애플리케이션이 풀러 또는 서비스 엔드포인트에 도달할 수 있습니까? 이 순서는 클러스터 관리자가 리더 선출에 여전히 멈춰 있는 동안 애플리케이션 로그를 보는 데 많은 시간을 낭비하는 것을 방지합니다.

PostgreSQL HA 기본 사항 이해

문제 해결에 들어가기 전에 PostgreSQL HA 클러스터의 핵심 구성 요소를 간략하게 요약하는 것이 중요합니다.

기본/복제본 아키텍처: 기본 데이터베이스는 모든 쓰기 작업을 처리하는 반면, 하나 이상의 복제본은 스트리밍 복제를 통해 비동기식 또는 동기식으로 변경 사항을 수신합니다. 복제본은 읽기 전용이지만 장애 조치 중에 승격 후보 역할을 합니다.
장애 조치 관리자: Patroni, pg_auto_failover 또는 Corosync/Pacemaker와 같은 도구는 기본 노드의 상태를 모니터링하고, 오류를 감지하고, 사용 가능한 복제본에서 새 기본 노드를 선출하고, 승격 프로세스를 관리합니다. 또한 다른 복제본이 새 기본 노드를 따르도록 재구성하는 작업을 처리합니다.
연결 풀링: 애플리케이션은 종종 데이터베이스에 직접 연결하지 않고 PostgreSQL 연결 풀러(예: PgBouncer, Odyssey)에 연결합니다. 그런 다음 풀러는 현재 기본 노드로 쿼리를 라우팅하여 연결 멀티플렉싱, 로드 밸런싱을 제공하고 잠재적으로 애플리케이션에서 기본 노드의 실제 네트워크 주소를 추상화합니다. 이 추상화는 장애 조치 중에 중요합니다.

일반적인 장애 조치 및 연결 문제와 해결 방법

1. 장애 조치 중 연결 풀링 결함

장애 조치 후 가장 빈번한 문제 중 하나는 데이터베이스 자체가 작동 중임에도 불구하고 애플리케이션이 새로 승격된 기본 노드에 다시 연결하지 못하는 것입니다. 이는 종종 연결 풀러 또는 클라이언트 측 캐싱 문제를 나타냅니다.

문제 증상:

애플리케이션이 데이터베이스 연결 오류를 보고합니다(FATAL: database "mydb" does not exist, connection refused, server closed the connection unexpectedly).
풀러를 통한 기존 연결이 중단되거나 이전 기본 노드의 IP에 연결하려고 시도하는 것으로 보입니다.
장애 조치가 완료된 후에도 새 연결이 실패합니다.

근본 원인:

풀러의 오래된 연결: 연결 풀러가 이전 기본 노드에 대한 열린 연결을 유지하고 이를 재사용하려고 시도하여 이전 기본 노드가 다운되었거나 이제 복제본인 경우 오류가 발생할 수 있습니다.
부적절한 풀러 구성: 풀러가 새 기본 노드를 올바르게 감지하고 전환하도록 구성되지 않았거나 server_reset_query가 누락되었거나 잘못되었을 수 있습니다.
DNS 캐싱: 애플리케이션이나 풀러가 DNS 항목을 사용하여 기본 노드의 주소를 확인하는 경우, 오래된 DNS 캐시 항목(로컬 또는 DNS 확인자 수준)으로 인해 이전 IP에 계속 연결을 시도할 수 있습니다.
클라이언트 측 재시도 로직 부족: 애플리케이션이 장애 조치 중에 일시적인 연결 문제를 처리하기 위한 강력한 재시도 메커니즘으로 구축되지 않았을 수 있습니다.

디버깅 단계:

풀러 상태 확인: 풀러의 콘솔에 액세스하고(예: psql -p 6432 pgbouncer -U pgbouncer) SHOW SERVERS, SHOW CLIENTS, SHOW DATABASES 출력을 확인하여 새 기본 노드를 인식하고 있는지, 올바른 주소에 대한 활성 연결이 있는지 확인합니다.
네트워크 연결 확인: 풀러 호스트에서 새 기본 노드의 PostgreSQL 포트로 ping 및 telnet을 수행합니다(telnet new_primary_ip 5432).
풀러 로그 검사: 데이터베이스 연결 또는 호스트 이름 확인 시도와 관련된 오류 메시지에 대해 풀러의 로그를 검토합니다.
DNS 확인 확인: 풀러 호스트에서 dig 또는 nslookup을 사용하여 기본 서비스 엔드포인트(예: primary.mydomain.com)에 대한 DNS 레코드가 새 기본 노드의 IP 주소로 확인되는지 확인합니다.

해결 방법:

server_reset_query 구성: 풀러에 server_reset_query(예: DISCARD ALL;)가 있는지 확인하여 연결이 풀에 반환되고 다른 클라이언트가 재사용하기 전에 세션 상태를 정리합니다. 이는 임시 개체 또는 세션별 설정을 사용하는 환경에서 중요합니다.
max_db_connections 및 max_user_connections: 풀러가 새 기본 노드에 대한 모든 연결을 독점하여 다른 서비스를 굶주리게 하는 것을 방지하기 위해 적절한 제한을 설정합니다.
풀러 다시 로드/다시 시작: 경우에 따라 연결 풀러를 정상적으로 다시 로드하거나 다시 시작하여 새 구성을 선택하거나 DNS를 다시 확인하도록 강제해야 할 수 있습니다. 이는 최후의 수단이어야 하며 가급적 장애 조치 관리자에 의해 자동화되어야 합니다.
짧은 DNS TTL: DNS 기반 서비스 검색을 사용하는 경우 기본 노드의 DNS 레코드에 대해 매우 짧은 TTL(예: 30-60초)을 구성하여 DNS 캐싱의 영향을 최소화합니다.
클라이언트 측 재시도: 애플리케이션 코드에 지수 백오프 및 재시도 로직을 구현합니다. 이렇게 하면 장애 조치 중에 일시적인 연결 문제에 대한 애플리케이션 복원력이 향상됩니다.
가상 IP(VIP): HA 솔루션에서 관리하는 가상 IP 사용을 고려하십시오. VIP는 기본 노드와 함께 이동하므로 애플리케이션은 정적 IP에 연결하고 기본 데이터베이스 서버는 투명하게 변경됩니다.

# 예제 PgBouncer 구성 스니펫
[databases]
mydb = host=primary_cluster_service_ip port=5432 dbname=mydb
# 또는 장애 조치 관리자에 의해 업데이트되는 호스트 이름 사용
# mydb = host=primary.mydomain.com port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = session
server_reset_query = DISCARD ALL;
server_fast_close = 1 # 서버가 응답하지 않으면 연결을 빠르게 닫음
server_check_delay = 10 # 10초마다 서버 상태 확인

2. 장애 조치를 방해하는 과도한 복제 지연

복제 지연은 대기 데이터베이스가 기본 노드보다 뒤쳐져 기본 노드가 보낸 모든 WAL(Write-Ahead Log) 레코드를 재생하지 못했을 때 발생합니다. 장애 조치 중에 지연이 큰 복제본을 승격하면 데이터 손실이 발생하거나 HA 관리자가 복제본이 따라잡을 때까지 기다리면 장애 조치 프로세스가 상당히 지연될 수 있습니다.

문제 증상:

모니터링 알림이 높은 복제 지연(예: 바이트 또는 시간)을 나타냅니다.
장애 조치 관리자가 구성된 지연 임계값을 초과하여 복제본 승격을 거부합니다.
장애 조치 후 애플리케이션이 이전 기본 노드에 있었던 누락된 데이터를 관찰합니다.

근본 원인:

높은 기본 쓰기 부하: 기본 노드에 대한 지속적인 높은 쓰기 작업 볼륨은 특히 복제본의 하드웨어(I/O, CPU)가 열등한 경우 복제본이 따라잡는 능력을 압도할 수 있습니다.
네트워크 지연/대역폭: 기본 노드와 복제본 간의 느리거나 혼잡한 네트워크 링크는 WAL 전송을 지연시킬 수 있습니다.
느린 복제본 I/O: 복제본의 디스크 하위 시스템이 WAL 레코드를 효율적으로 쓰고 재생할 만큼 빠르지 않을 수 있습니다.
wal_level 설정: wal_level이 replica 이상으로 설정되지 않은 경우 스트리밍 복제에 필요한 정보가 생성되지 않습니다.
max_wal_senders: 기본 노드의 max_wal_senders가 충분하지 않으면 활성 복제 슬롯 또는 동시 복제 연결 수가 제한되어 처리량에 영향을 줄 수 있습니다.
archive_command / restore_command 문제: WAL 아카이빙 및 복구를 사용하는 경우 이러한 명령의 문제(예: 느린 아카이브 스토리지)로 인해 지연이 발생할 수 있습니다.

디버깅 단계:

pg_stat_replication 모니터링: 이 뷰는 write_lag, flush_lag 및 replay_lag를 포함한 복제 상태에 대한 실시간 정보를 제공합니다.
LSN 비교: 기본 노드의 현재 WAL LSN을 복제본에서 마지막으로 재생된 LSN과 수동으로 비교합니다.
시스템 리소스 확인: 기본 노드와 복제본 모두에서 iostat, vmstat, top을 사용하여 I/O 병목 현상, CPU 포화 또는 메모리 압력을 식별합니다.
네트워크 진단: iperf를 사용하여 기본 노드와 복제본 간의 네트워크 성능을 테스트합니다.

해결 방법:

max_wal_senders 증가: 기본 노드에서 max_wal_senders를 증가시켜(예: max_wal_senders = 10) 더 많은 동시 복제 연결을 허용합니다. 다시 시작해야 합니다.
복제본 하드웨어 개선: I/O 또는 CPU가 병목 현상인 경우 복제본의 하드웨어를 업그레이드하거나 스토리지 구성을 최적화하는 것이 좋습니다(예: 더 빠른 SSD, 별도의 WAL 디스크).
wal_compression 조정: 기본 노드에서 wal_compression = on을 설정하면 WAL 볼륨을 줄여 네트워크 제약이 있는 링크를 통한 복제 속도를 잠재적으로 향상시킬 수 있지만 기본 CPU 비용이 발생합니다.
wal_keep_size 또는 wal_keep_segments 조정: 복제본이 동기화되지 않고 전체 기본 백업이 필요하지 않도록 기본 노드에 충분한 WAL 파일을 유지합니다.
synchronous_commit: synchronous_commit = on은 더 강력한 데이터 내구성 보장을 제공하지만 기본 노드에 쓰기 지연을 발생시킵니다. 엄격한 동기 복제가 필요한 경우 특정 테이블 또는 트랜잭션에 대해 remote_write 또는 remote_apply를 사용하지만 성능 영향을 신중하게 평가하십시오.
모니터링 및 알림: pg_stat_replication에 대한 강력한 모니터링을 구현하고 지연이 허용 가능한 임계값을 초과할 때 알림을 설정합니다.

-- 기본 노드: 현재 WAL LSN 확인
SELECT pg_current_wal_lsn();

-- 기본 노드: 연결된 대기 노드 및 지연 확인
SELECT
    usename, application_name, client_addr, state, sync_state,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes,
    write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

대기 노드에서 다음을 사용합니다.

SELECT
    pg_is_in_recovery() AS is_standby,
    pg_last_wal_receive_lsn(),
    pg_last_wal_replay_lsn(),
    now() - pg_last_xact_replay_timestamp() AS time_since_last_replay;

타임스탬프 쿼리는 유휴 시스템에서 최근 트랜잭션이 재생되지 않았을 수 있으므로 오해의 소지가 있습니다. LSN 비교 및 워크로드 컨텍스트와 함께 사용하십시오.

3. 실패하거나 중단된 기본 전환

자동화된 장애 조치는 복제본을 빠르고 안정적으로 승격해야 합니다. 이 프로세스가 중단되거나 완전히 실패하면 가동 중지 시간이 연장되고 수동 개입이 필요할 수 있습니다.

문제 증상:

이전 기본 노드가 다운된 후 새 기본 노드가 선출되거나 승격되지 않습니다.
두 노드가 자신이 기본 노드라고 믿는 스플릿 브레인 상태가 발생합니다.
장애 조치 관리자 로그에 쿼럼, 리더 선출 또는 데이터베이스 승격과 관련된 오류가 표시됩니다.
기본 노드를 사용할 수 없기 때문에 애플리케이션이 계속 다운됩니다.

근본 원인:

스플릿 브레인: 네트워크 파티션이 노드를 격리하여 여러 기본 노드 또는 모호한 기본 선출로 이어질 때 발생합니다. 이것은 데이터 발산의 위험이 있는 가장 위험한 시나리오입니다.
쿼럼 문제: 장애 조치 관리자가 노드 간에 쿼럼(과반수 투표)을 달성하지 못하여 승격에 대한 결정을 내리지 못할 수 있습니다. 이는 노드 수가 짝수이거나 노드 수가 너무 적은 클러스터에서 일반적입니다.
네트워크 격리: 장애 조치 관리자 노드가 서로 또는 PostgreSQL 인스턴스와 통신할 수 없어 상태 확인 또는 명령 실행을 방해합니다.
권한 부족: 장애 조치 관리자의 사용자에게 필요한 PostgreSQL 권한(예: pg_promote()) 또는 시스템 수준 권한(예: VIP 관리)이 없을 수 있습니다.
구성 오류: 장애 조치 관리자 구성 내에서 restore_command, primary_conninfo 또는 기타 설정이 잘못되었습니다.

디버깅 단계:

장애 조치 관리자 로그 확인: 이것이 주요 정보 소스입니다. Patroni의 경우 특정 로그(종종 journalctl -u patroni 또는 patroni.yml에 구성된 로그 파일)를 확인합니다. pg_auto_failover의 경우 journalctl -u pgautofailover_monitor 및 에이전트 로그를 확인합니다.
쿼럼 상태 확인: Patroni의 경우 patronictl list를 사용하여 모든 클러스터 구성원의 상태를 확인하고 선출된 리더를 확인합니다. pg_auto_failover의 경우 pg_autoctl show state를 확인합니다.
네트워크 연결: 모든 HA 노드와 분산 합의 저장소(예: Patroni의 경우 Etcd, Consul, ZooKeeper) 간에 ping, traceroute 및 telnet 검사를 수행합니다.
시스템 로그: 모든 노드에서 journalctl -xe 또는 /var/log/syslog를 확인하여 장애 조치 관리자를 방해할 수 있는 시스템 수준 오류(예: 디스크 가득 참, 메모리 문제)가 있는지 확인합니다.
PostgreSQL 로그: 승격 후보 복제본의 PostgreSQL 로그를 검사하여 승격 시도 중에 문제를 보고하는지 확인합니다.

해결 방법:

펜싱/STONITH 구현: 펜싱은 새 기본 노드가 승격되기 전에 실패한 기본 노드가 쓰기를 계속 수락하지 못하도록 하여 스플릿 브레인을 방지하는 데 중요합니다. 이는 일반적으로 장애 조치 관리자 또는 인프라 계층에서 처리합니다.
쿼럼을 위한 홀수 노드: 장애 조치 관리자의 분산 합의 저장소(Etcd, Consul, ZooKeeper)에 대해 항상 홀수 개의 투표 노드(예: 3, 5)를 배포하여 하나 또는 두 개의 노드가 실패하더라도 항상 쿼럼을 달성할 수 있도록 합니다.
강력한 네트워크 구성: 중복 네트워크 경로, 필요한 포트(PostgreSQL, 합의 저장소, Patroni API)에서 통신을 허용하는 적절한 방화벽 규칙 및 일관된 호스트 이름 확인을 보장합니다.
권한 확인: 장애 조치 관리자를 실행하는 사용자 계정에 승격 및 재구성 작업을 수행하는 데 필요한 모든 PostgreSQL 권한과 시스템 권한이 있는지 확인합니다.
장애 조치 관리자 구성 검토: patroni.yml 또는 pg_auto_failover 설정에서 오타, 잘못된 경로 또는 잘못 구성된 restore_command가 있는지 다시 확인합니다.
수동 개입(주의해서): 심각하게 중단된 장애 조치의 경우 수동 승격 또는 노드 재결합이 필요할 수 있습니다. 매우 주의하여 진행하고, 데이터 발산을 방지하기 위해 새 노드를 승격하기 전에 이전 기본 노드가 완전히 종료되었는지 확인하십시오.

# 예: Patroni 클러스터 상태 확인
patronictl -c /etc/patroni/patroni.yml list

# 예상 출력 (예):
# + Cluster: my_ha_cluster (6979219803154942080) ------+----+-----------+----+-----------+
# | Member  | Host         | Role    | State    | TL | Lag |
# +---------+--------------+---------+----------+----+-----+
# | node1   | 192.168.1.10 | Leader  | running  | 2  |     |
# | node2   | 192.168.1.11 | Replica | running  | 2  | 0   |
# | node3   | 192.168.1.12 | Replica | running  | 2  | 0   |
# +---------+--------------+---------+----------+----+-----+

4. 네트워크 연결 및 DNS 확인 문제

많은 HA 문제의 근본에는 노드 간 통신을 방해하거나 애플리케이션이 올바른 데이터베이스 엔드포인트를 찾지 못하게 하는 근본적인 네트워크 문제가 있습니다.

문제 증상:

애플리케이션 또는 클러스터 노드 간의 connection refused 또는 no route to host 오류.
장애 조치 관리자가 노드에 연결할 수 없다고 보고합니다.
DNS에 의존하는 서비스가 기본 노드의 호스트 이름을 올바르게 확인할 수 없습니다.

근본 원인:

방화벽 규칙: PostgreSQL 포트(5432), 장애 조치 관리자 포트 또는 합의 저장소 포트를 차단하는 잘못 구성된 방화벽 규칙(예: iptables, 보안 그룹).
네트워크 파티션: 노드 하위 집합 간의 통신을 방해하는 물리적 또는 논리적 네트워크 분할.
잘못된 라우팅: 하나 이상의 노드에서 잘못 구성된 네트워크 경로.
DNS 캐싱/잘못된 구성: 섹션 1에서 논의한 대로 오래된 DNS 레코드 또는 잘못된 DNS 서버 구성으로 인해 트래픽이 잘못된 방향으로 전달될 수 있습니다.
가상 IP(VIP) 마이그레이션 실패: VIP를 사용하는 경우 새 기본 노드로 마이그레이션하지 못하여 서비스에 연결할 수 없게 될 수 있습니다.

디버깅 단계:

기본 연결: 모든 노드 간에 ping <target_ip>을 사용합니다.
포트 연결: telnet <target_ip> <port>(예: telnet 192.168.1.10 5432)를 사용하여 PostgreSQL 포트가 열려 있고 수신 중인지 확인합니다.
방화벽 확인: 각 노드에서 활성 방화벽 규칙(sudo iptables -L, sudo ufw status 또는 클라우드 공급자 보안 그룹 구성)을 확인합니다.
네트워크 인터페이스 상태: ip addr show 또는 ifconfig를 사용하여 네트워크 인터페이스가 작동 중이고 올바르게 구성되었는지 확인합니다.
DNS 확인: 관련 노드(애플리케이션 서버, 풀러, HA 노드)에서 dig <hostname> 또는 nslookup <hostname>을 사용하여 호스트 이름 확인을 확인합니다.

해결 방법:

방화벽 규칙 검토: PostgreSQL(5432), 장애 조치 관리자의 제어 플레인(예: Patroni API의 경우 8008, pg_auto_failover의 경우 8000/8001) 및 분산 합의 저장소(예: Etcd: 2379/2380, Consul: 8300/8301/8302)에 필요한 포트가 열려 있는지 확인합니다.
일관된 네트워킹: 모든 노드가 동일한 서브넷에 있거나 여러 서브넷에 걸쳐 있는 경우 올바른 라우팅이 구성되었는지 확인합니다.
DNS 업데이트: 장애 조치 프로세스의 일부로 DNS 업데이트를 자동화하거나 더 짧은 TTL을 사용합니다. 이러한 이유로 VIP가 종종 선호됩니다.
VIP 관리: VIP를 사용하는 경우 VIP 관리 도구(예: Keepalived, 클라우드 공급자의 IP 관리)가 올바르게 구성되고 작동하는지 확인합니다. VIP 마이그레이션을 명시적으로 테스트합니다.
호스트 기반 액세스: 소규모 클러스터의 경우 단순화를 위해 pg_hba.conf가 잠재적인 모든 기본/복제본 IP 주소와 연결 풀러의 IP에서의 연결을 허용하는지 확인합니다.

문제 해결을 위한 필수 도구

psql: pg_stat_replication, pg_current_wal_lsn(), SHOW * 명령과 같은 SQL 쿼리를 실행합니다.
장애 조치 관리자 CLI: patronictl, pg_autoctl은 클러스터 상태, 로그를 쿼리하고 작업을 시작합니다.
시스템 모니터링: 리소스 사용률, 복제 지연 및 서비스 상태에 대한 실시간 통찰력을 위한 Prometheus + Grafana, Zabbix, Nagios 또는 클라우드 공급자 모니터링과 같은 도구.
journalctl / tail -f: 시스템 및 애플리케이션 로그를 봅니다.
네트워크 유틸리티: ping, traceroute, telnet, iperf, netstat, dig, nslookup은 연결 문제를 진단합니다.
dmesg: 특히 디스크 I/O 또는 OOM(Out Of Memory) 킬러와 관련된 커널 수준 오류.

빠른 인시던트 체크리스트

HA 장애 조치 알림이 발생하면 변경하기 전에 짧은 체크리스트를 사용하십시오.

클러스터 보기 확인:

patronictl -c /etc/patroni/patroni.yml list

연결 가능한 각 노드에서 PostgreSQL 자체 역할 확인:

SELECT pg_is_in_recovery();

false는 노드가 쓰기 가능한 기본 노드임을 의미합니다. true는 대기 노드임을 의미합니다. 둘 이상의 노드가 false를 보고하면 중지하고 인시던트를 가능한 스플릿 브레인으로 처리합니다.

애플리케이션 엔드포인트 확인:

dig primary-db.internal.example.com
nc -vz primary-db.internal.example.com 5432

PgBouncer를 사용하는 경우 풀러 대상을 확인합니다.

SHOW SERVERS;
SHOW POOLS;

오류가 오래된 것인지 현재 것인지 확인합니다. 애플리케이션 로그는 종종 장애 조치 첫 몇 초 동안의 재시도 메시지를 유지합니다. 오류가 여전히 발생하고 있다고 가정하기 전에 타임스탬프를 비교하십시오.

이 체크리스트는 의도적으로 간단합니다. 실제 장애 조치 중에 가장 좋은 명령은 팀의 모든 사람이 이해하고 추측 없이 실행할 수 있는 명령입니다.

장애 조치 문제 방지를 위한 모범 사례

정기적인 장애 조치 테스트: 정기적으로 기본 노드 오류를 시뮬레이션하고 장애 조치 프로세스를 관찰합니다. 이는 자신감을 키우고 잘못된 구성을 노출합니다.
강력한 모니터링 및 알림: 복제 지연, 기본 노드 상태, 연결 풀러 상태 및 시스템 리소스와 같은 주요 메트릭을 모니터링합니다. 편차에 대한 알림을 설정합니다.
적절한 연결 풀러 구성: server_reset_query가 구성되었는지, pool_mode가 애플리케이션에 적합한지, 상태 확인이 활성화되었는지 확인합니다.
복제 매개변수 조정: 성능 및 내구성 요구 사항에 따라 wal_level, max_wal_senders, wal_keep_size 및 synchronous_commit을 신중하게 구성합니다.
HA 설정 문서화: HA 아키텍처, 장애 조치 관리자 구성, 네트워크 설정 및 복구 절차를 명확하게 문서화합니다.
전용 장애 조치 관리자 사용: 중요한 HA 로직에 대해 사용자 정의 스크립트보다는 Patroni 또는 pg_auto_failover와 같은 검증된 솔루션에 의존합니다.
전용 합의 저장소: Patroni와 같은 관리자를 사용하는 경우 단일 장애 지점을 피하기 위해 분산 합의 저장소(Etcd, Consul)에 대해 별도의 고가용성 클러스터를 배포합니다.

가장 유용한 HA 테스트는 기본 노드가 정중하게 중지되는 깔끔한 데모가 아닙니다. 추한 경우도 테스트하십시오. 이전 기본 노드가 네트워크를 잃었지만 계속 실행되는 경우, DNS가 느리게 업데이트되는 경우, PgBouncer가 오래된 서버 연결을 유지하는 경우, 복제본이 30초 뒤쳐진 경우 또는 합의 저장소가 구성원을 잃는 경우입니다. 이러한 테스트는 실행 설명서가 실제로 운영하는 시스템과 일치하는지 보여줍니다.