5.3 토폴로지 패턴
세 가지 복제 설정을 조합하면 같은 pg_auto_failover에서도 성격이 전혀 다른 구성을 만들 수 있습니다. v2.2 문서는 대표 구성 네 가지를 예로 듭니다. 이 장에서는 각 구성의 설정값과 목표를 정리합니다. show settings 출력은 v2.2 문서(architecture-multi-standby.rst)의 예시를 옮겼습니다. 2노드와 3노드 기본 구성은 실습 출력으로 대신했습니다. 모든 구성에는 monitor 한 대가 별도로 있습니다.
2노드: primary + standby
formation | default | number_sync_standbys | 0
primary | node1 | synchronous_standby_names | 'ANY 1 (pgautofailover_standby_2)'
문서에서 "Business Continuity"라고 부르는 구성입니다. 평소에는 동기 복제로 데이터 두 벌을 유지합니다. standby를 잃으면 monitor가 primary를 wait_primary로 바꿉니다. 동기 복제를 해제한 뒤 쓰기를 이어 갑니다. 실습에서는 standby를 kill한 순간 실행한 INSERT 한 건이 19.9초 동안 기다린 뒤 성공했습니다(7.2). 이후 primary까지 잃으면 자동 승격은 이루어지지 않습니다.
3노드 기본: primary + standby 2대
formation | default | number_sync_standbys | 1
primary | node2 | synchronous_standby_names | 'ANY 1 (pgautofailover_standby_1, pgautofailover_standby_3)'
세 번째 노드를 기본 설정으로 추가하면 number_sync_standbys가 자동으로 1이 됩니다. commit은 standby 둘 중 먼저 응답한 쪽을 기다립니다. 따라서 데이터는 항상 두 벌 이상 유지됩니다. standby 한 대를 잃어도 쓰기는 멈추지 않습니다. 두 대를 모두 잃으면 primary의 쓰기가 대기합니다. 서비스는 사실상 읽기 전용 상태가 됩니다. 이 노트의 장애 실측은 대부분 이 구성을 기준으로 합니다.
standby 3대: ANY 2
Context | Name | Setting | Value
----------+---------+---------------------------+---------------------------------------------------------------------------------------
formation | default | number_sync_standbys | 2
primary | node_A | synchronous_standby_names | 'ANY 2 (pgautofailover_standby_2, pgautofailover_standby_4, pgautofailover_standby_3)'
네 번째 노드를 추가해도 값이 자동으로 2가 되지는 않습니다. pg_autoctl set formation number-sync-standbys 2로 직접 올려야 합니다. 그러면 모든 commit이 세 벌에 기록됩니다. 문서는 standby 두 대가 동시에 빠지면 데이터가 두 벌 남아 있어도 서비스가 읽기 전용 상태가 된다고 경고합니다. 데이터 보존을 가장 우선하는 구성입니다. commit은 standby 세 대 중 두 번째로 응답한 노드까지 기다립니다.
standby 3대, 그중 1대는 비동기 DR
formation | default | number_sync_standbys | 1
primary | node_A | synchronous_standby_names | 'ANY 1 (pgautofailover_standby_2, pgautofailover_standby_3)'
node | node_D | replication quorum | false
node | node_D | candidate priority | 0
A, B, C는 한 데이터센터에서 운영 트래픽과 HA를 담당합니다. D는 replication-quorum false이므로 synchronous_standby_names에 없습니다. 또한 candidate-priority 0이므로 자동 승격 대상도 아닙니다. 문서는 D의 용도로 첫 데이터센터 전체를 잃었을 때의 Business Continuity를 제시합니다. 다른 애플리케이션 영역의 리포팅에도 사용할 수 있습니다.
D는 monitor와 같은 formation에 속하므로 monitor가 있는 곳에서 관리됩니다. 첫 데이터센터와 monitor를 함께 잃으면 D의 승격 여부도 자동으로 결정되지 않습니다. priority 0 노드도 수동 승격은 허용됩니다(v1.5.2 이후). 그러나 monitor가 없으면 해당 명령도 실행할 수 없습니다. 데이터센터 단위 장애에 대비하려면 monitor 위치와 재구축 절차(6.6)를 함께 설계해야 합니다.
구성 비교
| 구성 | 노드 수 | number_sync_standbys | 평상시 데이터 벌 수 | standby 1대 손실 시 쓰기 |
|---|---|---|---|---|
| 2노드 | 2 | 0 | 2 | 계속 (wait_primary, 1벌) |
| 3노드 기본 | 3 | 1 | 2 이상 | 계속 (2벌 유지) |
| standby 3대 ANY 2 | 4 | 2 | 3 이상 | 계속 (3벌 유지) |
| 비동기 DR 포함 | 4 | 1 | 2 이상 (+ D 비동기) | 계속 (B, C 중 하나로 2벌 유지) |
표는 standby 한 대만 잃은 경우를 나타냅니다. 여러 노드를 함께 잃는 조합은 5.4에서 다룹니다.
토폴로지를 바꿀 때는 노드를 추가한 뒤 설정을 조정합니다. N+1 규칙 때문에 standby가 모자란 상태에서는 number_sync_standbys를 먼저 올릴 수 없습니다. 반대로 노드를 줄이면 monitor가 값을 자동으로 내립니다. 변경된 값은 show settings로 다시 확인합니다.
정리
2노드는 가용성을 가장 우선합니다. standby 3대에 ANY 2를 적용한 구성은 데이터 보존을 가장 우선합니다. 3노드 기본 구성은 그 중간에 해당합니다. standby 한 대에 장애가 발생해도 쓰기를 중단하지 않습니다. 비동기 DR 노드는 quorum과 priority에서 모두 제외합니다. 따라서 운영 경로에 영향을 주지 않습니다. 다만 monitor 위치에 따라 DR 전환이 자동으로 이루어지지 않는 경우가 생깁니다.