이 페이지에서는 Kubernetes 배포 옵션을 사용하여 AlloyDB Omni 버전 15.7.0을 설명합니다. 다른 배포 옵션을 선택합니다.

고가용성 설정 테스트

문서 버전을 선택합니다.

고가용성 Patroni 설정의 신뢰성과 품질을 보장하는 것은 데이터베이스의 지속적인 운영을 유지하고 다운타임을 최소화하는 데 매우 중요합니다. 이 페이지에서는 Patroni 클러스터 테스트에 대한 포괄적인 가이드를 제공하며, 다양한 장애 시나리오, 복제 일관성, 장애 조치 메커니즘을 다룹니다.

Patroni 설정 테스트

Patroni 인스턴스 중 하나(alloydb-patroni1, alloydb-patroni2, alloydb-patroni3)에 연결하여 AlloyDB Omni Patroni 폴더로 이동합니다.
```
cd /alloydb/
```

Patroni 로그를 확인합니다.

docker compose logs alloydbomni-patroni

로그의 마지막 항목에는 Patroni 노드에 대한 정보가 표시됩니다. 다음과 비슷한 출력이 표시됩니다.

alloydbomni-patroni        | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock

기본 Patroni 인스턴스 alloydb-patroni1과 네트워크로 연결할 수 있는 Linux 인스턴스에 연결한 뒤 해당 인스턴스의 정보를 확인합니다. sudo apt-get install jq -y를 실행하여 jq 도구를 설치해야 할 수도 있습니다.

curl -s http://alloydb-patroni1:8008/patroni | jq .

출력은 다음과 비슷합니다.

{
  "state": "running",
  "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00",
  "role": "master",
  "server_version": 150005,
  "xlog": {
    "location": 83886408
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "alloydbreplica",
      "application_name": "patroni2",
      "client_addr": "10.172.0.40",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "alloydbreplica",
      "application_name": "patroni3",
      "client_addr": "10.172.0.41",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "dcs_last_seen": 1715870011,
  "database_system_identifier": "7369600155531440151",
  "patroni": {
    "version": "3.3.0",
    "scope": "my-patroni-cluster",
    "name": "patroni1"
  }
}

Patroni 노드에서 Patroni HTTP API 엔드포인트를 호출하면 해당 Patroni가 관리하는 PostgreSQL 인스턴스의 상태 및 구성에 대한 다양한 세부정보를 확인할 수 있습니다. 여기에는 클러스터 상태 정보, 타임라인, WAL 정보, 그리고 노드 및 클러스터가 정상적으로 실행되고 있는지를 나타내는 상태 점검 결과가 포함됩니다.

HAProxy 설정 테스트

브라우저와 HAProxy 노드에 대한 네트워크 연결이 가능한 머신에서 http://haproxy:7000 주소로 이동합니다. 또는 호스트 이름 대신 HAProxy 인스턴스의 외부 IP 주소를 사용할 수도 있습니다.

다음 스크린샷과 비슷한 화면이 표시됩니다.

그림 1. Patroni 노드의 상태와 지연 시간을 보여주는 HAProxy 상태 페이지

HAProxy 대시보드에서 기본 Patroni 노드(patroni1)와 두 개의 복제본 노드(patroni2, patroni3)의 상태와 지연 시간을 확인할 수 있습니다.
클러스터의 복제 통계를 확인하기 위해 쿼리를 실행할 수도 있습니다. 예를 들어 pgAdmin 같은 클라이언트에서 HAProxy를 통해 기본 데이터베이스 서버에 연결한 뒤, 다음 쿼리를 실행합니다.
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
다음 다이어그램과 비슷한 결과가 표시되며, patroni2와 patroni3가 patroni1로부터 스트리밍하고 있음을 보여줍니다.

그림 2. Patroni 노드의 복제 상태를 보여주는 pg_stat_replication 출력

자동 장애 조치 테스트

이 섹션에서는 3노드 클러스터에서 기본 노드에 장애가 발생한 상황을 시뮬레이션합니다. 이를 위해 연결되어 실행 중인 Patroni 컨테이너를 중지합니다. 장애를 시뮬레이션하려면 기본 노드에서 Patroni 서비스를 중지하거나, 방화벽 규칙을 적용해 해당 노드와의 통신을 차단할 수도 있습니다.

기본 Patroni 인스턴스에서 AlloyDB Omni Patroni 폴더로 이동합니다.
```
cd /alloydb/
```
컨테이너를 중지합니다.
```
docker compose down
```
출력은 다음과 비슷합니다. 이를 통해 컨테이너와 네트워크가 중지되었음을 확인할 수 있습니다.
```
[+] Running 2/2
✔ Container alloydb-patroni            Removed
✔ Network alloydbomni-patroni_default  Removed
```
HAProxy 대시보드를 새로고침하여 장애 조치가 어떻게 발생하는지 확인합니다.

그림 3. 기본 노드에서 대기 노드로의 장애 조치를 보여주는 HAProxy 대시보드

patroni3 인스턴스가 새로운 기본이 되었으며, patroni2는 유일한 복제본으로 남았습니다. 이전 기본 노드인 patroni1은 다운되어 상태 점검에 실패합니다.

Patroni는 모니터링, 합의, 자동 조정의 조합을 통해 장애 조치를 수행하고 관리합니다. 지정된 제한 시간 내에 기본 노드가 리스를 갱신하지 못하거나 장애를 보고하면 클러스터 내 다른 노드들이 합의 시스템을 통해 이를 인식합니다. 나머지 노드들은 가장 적합한 복제본을 새로운 기본으로 승격하기 위해 협력합니다. 후보 복제본이 선택되면 Patroni는 PostgreSQL 구성을 업데이트하고 미처 적용되지 않은 WAL 레코드를 재생하는 등 필요한 변경을 적용하여 해당 노드를 기본으로 승격합니다. 이후 새 기본 노드는 합의 시스템에 자신의 상태를 업데이트하며, 다른 복제본들은 복제 소스를 새 기본으로 전환하고, 필요 시 새로운 트랜잭션을 따라잡도록 다시 구성됩니다. HAProxy는 새 기본을 감지하고 클라이언트 연결을 적절히 리디렉션하여 중단을 최소화합니다.
pgAdmin 같은 클라이언트를 사용해 HAProxy를 통해 데이터베이스 서버에 연결한 뒤, 장애 조치 이후 클러스터의 복제 통계를 확인합니다.
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
다음 다이어그램과 비슷한 출력이 표시되며, 이제 patroni2만 스트리밍 중임을 보여줍니다.

그림 4. 장애 조치 이후 Patroni 노드의 복제 상태를 보여주는 pg_stat_replication 출력
3노드 클러스터는 추가 장애에도 한 번 더 유지될 수 있습니다. 현재 기본 노드인 patroni3를 중지하면 또 다른 장애 조치가 발생합니다.

그림 5. 기본 노드 patroni3에서 대기 노드 patroni2로의 장애 조치를 보여주는 HAProxy 대시보드

대체 고려사항

대체는 장애 조치가 발생한 후 이전 소스 노드를 복구하는 프로세스입니다. 고가용성 데이터베이스 클러스터에서는 불완전한 복구, 스플릿 브레인 시나리오 위험, 복제 지연 등 여러 중요한 문제 때문에 자동 대체는 일반적으로 권장되지 않습니다.

Patroni 클러스터에서 서비스 중단을 시뮬레이션했던 두 노드를 다시 실행하면, 이들이 클러스터에 대기 복제본으로 다시 합류합니다.

`patroni1` 및 `patroni3`가 대기 노드로 복원된 것을 보여주는 HAProxy 대시보드

그림 6. patroni1 및 patroni3가 대기 노드로 복원된 것을 보여주는 HAProxy 대시보드

이제 patroni1과 patroni3는 현재 기본인 patroni2로부터 복제를 수행합니다.

대체 이후 Patroni 노드의 복제 상태를 보여주는 pg_stat_replication 출력

그림 7. 대체 이후 Patroni 노드의 복제 상태를 보여주는 pg_stat_replication 출력

초기 기본 노드로 수동 대체를 원한다면 patronictl 명령줄 인터페이스를 사용해 수행할 수 있습니다. 수동 대체를 선택하면 더 신뢰할 수 있고, 일관적이며, 철저하게 검증된 복구 프로세스를 보장하여 데이터베이스 시스템의 무결성과 가용성을 유지할 수 있습니다.