장애 조치 클러스터 PostgreSQL + Patroni. 구현 경험

이 기사에서는 PostgreSQL 내결함성 문제에 어떻게 접근했는지, 이것이 우리에게 왜 중요해졌는지, 그리고 결국 무슨 일이 일어났는지 알려드리겠습니다.

전 세계적으로 2,5만 명의 사용자, 매일 50명 이상의 활성 사용자가 있습니다. 서버는 아일랜드의 한 지역에 있는 Amazone에 있습니다. 100개 이상의 서로 다른 서버가 지속적으로 작동하고 있으며 그 중 거의 50개가 데이터베이스와 함께 있습니다.

전체 백엔드는 클라이언트와 지속적인 웹 소켓 연결을 유지하는 대규모 모놀리식 상태 저장 Java 애플리케이션입니다. 여러 사용자가 동시에 동일한 보드에서 작업할 때 각 변경 사항을 데이터베이스에 기록하기 때문에 모든 사용자가 실시간으로 변경 사항을 볼 수 있습니다. 데이터베이스에 초당 약 10K 요청이 있습니다. Redis의 최대 로드 시 초당 80-100K 요청을 작성합니다.

Redis에서 PostgreSQL로 전환한 이유

처음에 우리 서비스는 서버의 RAM에 모든 데이터를 저장하는 키-값 저장소인 Redis와 함께 작동했습니다.

레디스의 장점:

1. 응답속도가 높기 때문에 모든 것이 메모리에 저장됩니다.
2. 간편한 백업 및 복제.

Redis의 단점:

1. 실제 거래가 없습니다. 우리는 애플리케이션 수준에서 시뮬레이션을 시도했습니다. 불행히도 이것은 항상 제대로 작동하지 않았고 매우 복잡한 코드를 작성해야 했습니다.
2. 데이터 양은 메모리 양에 의해 제한됩니다. 데이터 양이 늘어날수록 메모리도 늘어나게 되고, 결국 선택한 인스턴스의 특성에 부딪히게 되는데, AWS에서는 인스턴스 유형을 변경하기 위해 서비스를 중단해야 합니다.
3. 지속적으로 낮은 대기 시간 수준을 유지해야 하기 때문입니다. 매우 많은 수의 요청이 있습니다. 최적의 지연 수준은 17-20ms입니다. 30-40ms 수준에서 애플리케이션의 요청에 대한 긴 응답과 서비스 저하를 얻습니다. 안타깝게도 2018년 2월 Redis가 있는 인스턴스 중 하나가 어떤 이유로 평소보다 XNUMX배 더 많은 대기 시간을 수신했을 때 이런 일이 발생했습니다. 이 문제를 해결하기 위해 예정되지 않은 유지 관리를 위해 정오에 서비스를 중단하고 문제가 있는 Redis 인스턴스를 교체했습니다.
4. 코드에 사소한 오류가 있어도 데이터 불일치가 발생하기 쉽고 이 데이터를 수정하기 위해 코드를 작성하는 데 많은 시간을 소비합니다.

우리는 단점을 고려했고 정상적인 거래가 가능하고 대기 시간에 덜 의존하는 더 편리한 것으로 전환해야 한다는 것을 깨달았습니다. 연구를 수행하고 많은 옵션을 분석한 후 PostgreSQL을 선택했습니다.

이미 1,5년 전부터 새로운 데이터베이스로 옮겨왔고 데이터의 일부만 옮겼기 때문에 지금은 Redis와 PostgreSQL을 동시에 작업하고 있습니다. 데이터베이스 간 데이터 이동 및 전환 단계에 대한 자세한 내용은 다음 문서에 기록되어 있습니다. 내 동료의 기사.

우리가 처음 이동을 시작했을 때 우리 애플리케이션은 데이터베이스와 직접 작업하고 마스터 Redis 및 PostgreSQL에 액세스했습니다. PostgreSQL 클러스터는 마스터와 비동기식 복제가 있는 복제본으로 구성되었습니다. 데이터베이스 구성표는 다음과 같습니다.

PgBouncer 구현

이동하는 동안 제품도 개발 중이었습니다. PostgreSQL과 함께 작동하는 사용자 수와 서버 수가 증가했고 연결이 부족하기 시작했습니다. PostgreSQL은 각 연결에 대해 별도의 프로세스를 생성하고 리소스를 소비합니다. 특정 지점까지 연결 수를 늘릴 수 있습니다. 그렇지 않으면 최적이 아닌 데이터베이스 성능을 얻을 수 있습니다. 이러한 상황에서 이상적인 옵션은 기지 앞에 서게 될 연결 관리자를 선택하는 것입니다.

연결 관리자에는 Pgpool과 PgBouncer라는 두 가지 옵션이 있습니다. 그러나 첫 번째는 데이터베이스 작업의 트랜잭션 모드를 지원하지 않으므로 PgBouncer를 선택했습니다.

우리는 다음과 같은 작업 체계를 설정했습니다. 애플리케이션은 하나의 PgBouncer에 액세스하고 그 뒤에는 PostgreSQL 마스터가 있고 각 마스터 뒤에는 비동기 복제가 있는 하나의 복제본이 있습니다.


동시에 PostgreSQL에 전체 데이터를 저장할 수 없었고 데이터베이스 작업 속도가 중요했기 때문에 애플리케이션 수준에서 PostgreSQL 샤딩을 시작했습니다. 위에서 설명한 체계는 이를 위해 상대적으로 편리합니다. 새 PostgreSQL 샤드를 추가할 때 PgBouncer 구성을 업데이트하는 것으로 충분하며 애플리케이션은 새 샤드와 즉시 작업할 수 있습니다.

PgBouncer 장애 조치

이 방식은 유일한 PgBouncer 인스턴스가 종료되는 순간까지 작동했습니다. 우리는 모든 인스턴스가 주기적으로 죽는 하드웨어에서 실행되는 AWS에 있습니다. 이러한 경우 인스턴스는 단순히 새 하드웨어로 이동하고 다시 작동합니다. 이것은 PgBouncer에서 발생했지만 사용할 수 없게 되었습니다. 이번 가을의 결과는 25분 동안 서비스를 사용할 수 없었습니다. AWS는 이러한 상황에 대해 당시 우리나라에서 구현되지 않은 사용자 측 중복성을 사용할 것을 권장합니다.

그 후 PgBouncer 및 PostgreSQL 클러스터의 내결함성에 대해 진지하게 생각했습니다. AWS 계정의 모든 인스턴스에서 유사한 상황이 발생할 수 있기 때문입니다.

우리는 다음과 같이 PgBouncer 내결함성 체계를 구축했습니다. 모든 애플리케이션 서버는 Network Load Balancer에 액세스하고 그 뒤에 두 개의 PgBouncer가 있습니다. 각 PgBouncer는 각 샤드의 동일한 PostgreSQL 마스터를 확인합니다. AWS 인스턴스 충돌이 다시 발생하면 모든 트래픽이 다른 PgBouncer를 통해 리디렉션됩니다. Network Load Balancer 장애 조치는 AWS에서 제공합니다.

이 체계를 사용하면 새 PgBouncer 서버를 쉽게 추가할 수 있습니다.

PostgreSQL 장애 조치 클러스터 생성

이 문제를 해결할 때 자체 작성 장애 조치, repmgr, AWS RDS, Patroni와 같은 다양한 옵션을 고려했습니다.

자체 작성 스크립트

마스터의 작업을 모니터링하고 실패할 경우 복제본을 마스터로 승격하고 PgBouncer 구성을 업데이트할 수 있습니다.

이 접근 방식의 장점은 스크립트를 직접 작성하고 작동 방식을 정확히 이해하기 때문에 최대의 단순성입니다.

단점 :

• 마스터가 죽지 않았을 수도 있고 대신 네트워크 오류가 발생했을 수도 있습니다. 이를 인식하지 못하는 페일오버는 이전 마스터가 계속 작동하는 동안 복제본을 마스터로 승격합니다. 결과적으로 우리는 마스터 역할을 하는 두 개의 서버를 갖게 되며 어느 것이 최신 데이터를 가지고 있는지 알 수 없습니다. 이 상황을 스플릿 브레인(split-brain)이라고도 합니다.
• 우리는 응답 없이 남겨졌습니다. 우리 구성에서 마스터와 하나의 복제본은 전환 후 복제본이 마스터로 이동하고 더 이상 복제본이 없으므로 새 복제본을 수동으로 추가해야 합니다.
• 12개의 PostgreSQL 샤드가 있는 동안 장애 조치 작업에 대한 추가 모니터링이 필요하므로 12개의 클러스터를 모니터링해야 합니다. 샤드 수가 증가하면 장애 조치도 업데이트해야 합니다.

자체 작성 장애 조치는 매우 복잡해 보이며 적지 않은 지원이 필요합니다. 단일 PostgreSQL 클러스터를 사용하는 경우 이것이 가장 쉬운 옵션이지만 확장되지 않으므로 우리에게 적합하지 않습니다.

Repmgr

PostgreSQL 클러스터의 작업을 관리할 수 있는 Replication Manager for PostgreSQL 클러스터. 동시에 자동 장애 조치 기능이 없으므로 작업을 위해 완성된 솔루션 위에 고유한 "래퍼"를 작성해야 합니다. 따라서 모든 것이 직접 작성한 스크립트보다 훨씬 더 복잡할 수 있으므로 Repmgr을 시도조차 하지 않았습니다.

AWS RDS

필요한 모든 것을 지원하고 백업 방법을 알고 연결 풀을 유지 관리합니다. 자동 전환 기능이 있습니다. 마스터가 죽으면 복제본이 새 마스터가 되고 AWS는 dns 레코드를 새 마스터로 변경하지만 복제본은 다른 AZ에 있을 수 있습니다.

단점은 미세 조정이 없다는 것입니다. 미세 조정의 예: 인스턴스에는 tcp 연결에 대한 제한이 있지만 불행히도 RDS에서는 수행할 수 없습니다.

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

또한 AWS RDS는 일반 인스턴스 가격보다 거의 두 배나 비싸서 이 솔루션을 포기한 주된 이유였습니다.

패트로니

이것은 훌륭한 문서화, 자동 장애 조치 및 github의 소스 코드로 PostgreSQL을 관리하기 위한 Python 템플릿입니다.

Patroni의 장점:

• 각 구성 매개변수가 설명되어 있으며 작동 방식이 명확합니다.
• 자동 장애 조치는 기본적으로 작동합니다.
• 파이썬으로 작성되었고 우리는 파이썬으로 많이 작성하기 때문에 문제를 처리하는 것이 더 쉬울 것이며 아마도 프로젝트 개발에도 도움이 될 것입니다.
• PostgreSQL을 완벽하게 관리하고 클러스터의 모든 노드에서 한 번에 구성을 변경할 수 있으며, 새 구성을 적용하기 위해 클러스터를 다시 시작해야 하는 경우 Patroni를 사용하여 다시 수행할 수 있습니다.

단점 :

• PgBouncer를 올바르게 사용하는 방법은 문서에서 명확하지 않습니다. 마이너스라고 부르기는 어렵지만 Patroni의 임무는 PostgreSQL을 관리하는 것이고 Patroni에 대한 연결이 어떻게 진행될지는 이미 우리의 문제이기 때문입니다.
• Patroni를 대량으로 구현한 예는 거의 없지만 처음부터 구현한 예는 많습니다.

그 결과 장애 조치 클러스터를 만들기 위해 Patroni를 선택했습니다.

Patroni 구현 프로세스

Patroni 이전에는 비동기식 복제가 포함된 하나의 마스터와 하나의 복제본 구성에 12개의 PostgreSQL 샤드가 있었습니다. 애플리케이션 서버는 Network Load Balancer를 통해 데이터베이스에 액세스했으며 그 뒤에는 PgBouncer가 있는 두 개의 인스턴스가 있었고 그 뒤에는 모든 PostgreSQL 서버가 있었습니다.


Patroni를 구현하려면 분산 스토리지 클러스터 구성을 선택해야 했습니다. Patroni는 etcd, Zookeeper, Consul과 같은 분산 구성 스토리지 시스템과 함께 작동합니다. 우리는 Vault와 함께 작동하는 본격적인 Consul 클러스터를 시장에 보유하고 있으며 더 이상 사용하지 않습니다. 의도된 목적에 맞게 Consul을 사용하기 시작하는 좋은 이유입니다.

Patroni가 Consul과 협력하는 방식

세 개의 노드로 구성된 Consul 클러스터와 리더와 복제본으로 구성된 Patroni 클러스터가 있습니다(Patroni에서는 마스터를 클러스터 리더라고 하고 슬레이브를 복제본이라고 합니다). Patroni 클러스터의 각 인스턴스는 지속적으로 클러스터 상태에 대한 정보를 Consul에 보냅니다. 따라서 Consul에서 Patroni 클러스터의 현재 구성과 현재 리더가 누구인지 항상 확인할 수 있습니다.

Patroni를 Consul에 연결하려면 Consul과의 작업 방식 및 선택적으로 연결 체계에 따라 http 또는 https 형식으로 호스트를 지정해야 한다는 공식 문서를 연구하는 것으로 충분합니다.

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

간단해 보이지만 여기서 함정이 시작됩니다. Consul을 사용하여 https를 통한 보안 연결을 통해 작업하고 연결 구성은 다음과 같습니다.

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

그러나 그것은 작동하지 않습니다. 시작 시 Patroni는 Consul에 연결할 수 없습니다. 어쨌든 http를 통해 이동하려고 하기 때문입니다.

Patroni의 소스 코드는 문제를 해결하는 데 도움이 되었습니다. 좋은 점은 파이썬으로 작성되었습니다. 호스트 매개변수는 어떤 식으로든 구문 분석되지 않으며 프로토콜은 스키마에 지정되어야 합니다. Consul 작업을 위한 작업 구성 블록은 다음과 같습니다.

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

영사 템플릿

따라서 구성을 위한 스토리지를 선택했습니다. 이제 Patroni 클러스터에서 리더를 변경할 때 PgBouncer가 구성을 전환하는 방법을 이해해야 합니다. 설명서에는 이 질문에 대한 답변이 없습니다. 왜냐하면. 원칙적으로 PgBouncer 작업은 설명되어 있지 않습니다.

솔루션을 찾기 위해 우리는 Сonsul-template이 PgBouncer와 Patroni를 페어링하는 데 많은 도움이 되었다고 쓰여진 기사(불행히도 제목이 기억나지 않습니다)를 찾았습니다. 이로 인해 Consul-template이 어떻게 작동하는지 조사하게 되었습니다.

Consul-template은 Consul에서 PostgreSQL 클러스터의 구성을 지속적으로 모니터링하는 것으로 나타났습니다. 리더가 변경되면 PgBouncer 구성을 업데이트하고 다시 로드하라는 명령을 보냅니다.

템플릿의 큰 장점은 코드로 저장되기 때문에 새 샤드를 추가할 때 새 커밋을 만들고 템플릿을 자동으로 업데이트하는 것으로 충분하여 Infrastructure as Code 원칙을 지원합니다.

Patroni를 사용한 새로운 아키텍처

결과적으로 다음 작업 계획을 얻었습니다.


모든 애플리케이션 서버가 밸런서에 액세스 → 그 뒤에 두 개의 PgBouncer 인스턴스가 있음 → 각 인스턴스에서 각 Patroni 클러스터의 상태를 모니터링하고 현재 리더에게 요청을 보내는 PgBouncer 구성의 관련성을 모니터링하는 Consul 템플릿이 시작됩니다. 각 클러스터의.

수동 테스트

소규모 테스트 환경에서 시작하기 전에 이 구성표를 실행하고 자동 전환 작동을 확인했습니다. 그들은 보드를 열고 스티커를 옮겼고 그 순간 클러스터의 리더를 "죽였습니다". AWS에서는 콘솔을 통해 인스턴스를 종료하는 것만큼 간단합니다.

스티커는 10-20초 이내에 다시 돌아오더니 다시 정상적으로 움직이기 시작했습니다. 이는 Patroni 클러스터가 올바르게 작동했음을 의미합니다. 리더를 변경하고 정보를 Сonsul로 보냈으며 Сonsul-template은 즉시 이 정보를 선택하고 PgBouncer 구성을 교체하고 다시 로드하라는 명령을 보냈습니다.

높은 부하에서 생존하고 가동 중지 시간을 최소화하는 방법은 무엇입니까?

모든 것이 완벽하게 작동합니다! 그러나 새로운 질문이 있습니다. 높은 부하에서 어떻게 작동할까요? 프로덕션에서 모든 것을 빠르고 안전하게 롤아웃하는 방법은 무엇입니까?

부하 테스트를 수행하는 테스트 환경은 첫 번째 질문에 답하는 데 도움이 됩니다. 아키텍처 측면에서 프로덕션과 완전히 동일하며 프로덕션과 거의 동일한 볼륨의 테스트 데이터를 생성했습니다. 테스트 중에 PostgreSQL 마스터 중 하나를 "죽이기"로 결정하고 어떤 일이 발생하는지 확인합니다. 그러나 그 전에 자동 롤링을 확인하는 것이 중요합니다. 이 환경에는 여러 PostgreSQL 샤드가 있으므로 프로덕션 전에 구성 스크립트에 대한 우수한 테스트를 얻을 수 있기 때문입니다.

두 작업 모두 야심차게 보이지만 PostgreSQL 9.6이 있습니다. 11.2로 즉시 업그레이드할 수 있습니까?

2단계로 진행하기로 결정했습니다. 먼저 11.2로 업그레이드한 다음 Patroni를 실행합니다.

PostgreSQL 업데이트

PostgreSQL 버전을 빠르게 업데이트하려면 옵션을 사용하십시오. -k, 하드 링크가 디스크에 생성되고 데이터를 복사할 필요가 없습니다. 300~400GB 기준으로 업데이트하는 데 1초가 걸립니다.

샤드가 많기 때문에 업데이트를 자동으로 수행해야 합니다. 이를 위해 전체 업데이트 프로세스를 처리하는 Ansible 플레이북을 작성했습니다.

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

여기서 업그레이드를 시작하기 전에 다음 매개변수를 사용하여 업그레이드를 수행해야 한다는 점에 유의하는 것이 중요합니다. --확인하다업그레이드할 수 있는지 확인합니다. 또한 스크립트는 업그레이드 기간 동안 구성을 대체합니다. 우리의 스크립트는 30초 만에 완료되었으며 이는 훌륭한 결과입니다.

Patroni 실행

두 번째 문제를 해결하려면 Patroni 구성을 살펴보십시오. 공식 리포지토리에는 Patroni를 처음 시작할 때 새 데이터베이스를 초기화하는 역할을 하는 initdb를 사용한 예제 구성이 있습니다. 그러나 기성품 데이터베이스가 이미 있으므로 구성에서 이 섹션을 간단히 제거했습니다.

이미 존재하는 PostgreSQL 클러스터에 Patroni를 설치하고 실행하기 시작했을 때 새로운 문제에 직면했습니다. 두 서버 모두 리더로 시작되었습니다. Patroni는 클러스터의 초기 상태에 대해 아무것도 모르고 두 서버를 동일한 이름을 가진 두 개의 개별 클러스터로 시작하려고 시도합니다. 이 문제를 해결하려면 슬레이브에서 데이터가 있는 디렉토리를 삭제해야 합니다.

rm -rf /var/lib/postgresql/

이것은 슬레이브에서만 수행해야 합니다!

클린 레플리카가 연결되면 패트로니는 베이스백업 리더를 만들어 레플리카에 복원한 후 wallog에 따라 현재 상태를 따라잡는다.

우리가 직면한 또 다른 어려움은 모든 PostgreSQL 클러스터의 이름이 기본적으로 기본으로 지정된다는 것입니다. 각 클러스터가 서로에 대해 아무것도 모르는 경우 이는 정상입니다. 그러나 Patroni를 사용하려면 모든 클러스터에 고유한 이름이 있어야 합니다. 해결책은 PostgreSQL 구성에서 클러스터 이름을 변경하는 것입니다.

부하 테스트

보드에서 사용자 경험을 시뮬레이션하는 테스트를 시작했습니다. 부하가 일일 평균 값에 도달했을 때 정확히 동일한 테스트를 반복하고 PostgreSQL 리더가 있는 인스턴스 하나를 끕니다. 자동 장애 조치는 예상대로 작동했습니다. Patroni는 리더를 변경했고 Consul-template은 PgBouncer 구성을 업데이트했으며 다시 로드하라는 명령을 보냈습니다. Grafana의 그래프에 따르면 데이터베이스 연결과 관련된 서버에서 20-30초의 지연과 약간의 오류가 있음이 분명했습니다. 이것은 정상적인 상황이며 이러한 값은 장애 조치에 허용되며 서비스 중단 시간보다 확실히 낫습니다.

Patroni를 프로덕션으로 가져오기

그 결과 다음과 같은 계획을 세웠습니다.

• Consul-template을 PgBouncer 서버에 배포하고 시작합니다.
• 버전 11.2로 PostgreSQL 업데이트;
• 클러스터의 이름을 변경하십시오.
• Patroni 클러스터 시작.

동시에 우리의 체계를 통해 거의 언제든지 첫 번째 요점을 만들 수 있으며 작업에서 각 PgBouncer를 차례로 제거하고 consul-template을 배포하고 실행할 수 있습니다. 그래서 우리는 했다.

빠른 배포를 위해 테스트 환경에서 모든 플레이북을 이미 테스트했으며 전체 스크립트의 실행 시간이 각 샤드에 대해 1,5~2분이었기 때문에 Ansible을 사용했습니다. 서비스를 중단하지 않고 각 샤드에 차례로 모든 것을 롤아웃할 수 있지만 각 PostgreSQL을 몇 분 동안 꺼야 합니다. 이 경우 이 샤드에 데이터가 있는 사용자는 현재 완전히 작동할 수 없으며 이는 허용되지 않습니다.

이 상황에서 벗어날 수 있는 방법은 3개월마다 진행되는 계획된 유지 보수였습니다. 서비스를 완전히 종료하고 데이터베이스 인스턴스를 업그레이드하는 예정된 작업 창입니다. 다음 창구까지 XNUMX주일 남았고, 더 기다리며 준비하기로 했습니다. 대기 시간 동안 우리는 추가로 우리 자신을 확보했습니다. 각 PostgreSQL 샤드에 대해 최신 데이터를 유지하지 못하는 경우를 대비하여 여분의 복제본을 생성하고 각 샤드에 대한 새 인스턴스를 추가하여 Patroni 클러스터의 새 복제본이 되어야 합니다. 데이터 삭제 명령을 실행하지 않도록 합니다. 이 모든 것이 오류 위험을 최소화하는 데 도움이 되었습니다.


우리는 서비스를 다시 시작했고 모든 것이 제대로 작동했고 사용자는 계속 작동했지만 그래프에서 Consul 서버에 비정상적으로 높은 부하가 있음을 발견했습니다.


테스트 환경에서 이것을 보지 못한 이유는 무엇입니까? 이 문제는 Infrastructure as Code 원칙을 따르고 테스트 환경에서 프로덕션에 이르기까지 전체 인프라를 개선해야 한다는 것을 잘 보여줍니다. 그렇지 않으면 우리가 가진 문제를 얻는 것이 매우 쉽습니다. 무슨 일이에요? Consul은 프로덕션에 처음 등장한 다음 테스트 환경에 나타 났으며 결과적으로 테스트 환경에서 Consul 버전이 프로덕션보다 높았습니다. 릴리스 중 하나에서 consul-template으로 작업할 때 CPU 누수가 해결되었습니다. 따라서 간단히 Consul을 업데이트하여 문제를 해결했습니다.

Patroni 클러스터 다시 시작

그러나 의심조차 하지 않았던 새로운 문제가 생겼습니다. Consul을 업데이트할 때 consul leave 명령을 사용하여 클러스터에서 Consul 노드를 제거하기만 하면 됩니다. → Patroni가 다른 Consul 서버에 연결 → 모든 것이 작동합니다. 그러나 Consul 클러스터의 마지막 인스턴스에 도달하여 consul leave 명령을 보냈을 때 모든 Patroni 클러스터가 다시 시작되었고 로그에 다음 오류가 표시되었습니다.

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Patroni 클러스터가 해당 클러스터에 대한 정보를 검색할 수 없어 다시 시작되었습니다.

해결책을 찾기 위해 github의 문제를 통해 Patroni 작성자에게 연락했습니다. 구성 파일에 대한 개선 사항을 제안했습니다.

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

우리는 테스트 환경에서 문제를 재현할 수 있었고 그곳에서 이러한 옵션을 테스트했지만 안타깝게도 작동하지 않았습니다.

문제는 여전히 미해결 상태로 남아 있습니다. 다음 솔루션을 시도할 계획입니다.

• 각 Patroni 클러스터 인스턴스에서 Consul-agent를 사용하십시오.
• 코드에서 문제를 수정하십시오.

오류가 발생한 위치를 이해합니다. 문제는 아마도 구성 파일을 통해 재정의되지 않은 기본 시간 초과 사용 때문일 것입니다. 마지막 Consul 서버가 클러스터에서 제거되면 전체 Consul 클러스터가 XNUMX초 이상 중단됩니다. 이로 인해 Patroni는 클러스터의 상태를 가져올 수 없으며 전체 클러스터를 완전히 다시 시작합니다.

다행히 더 이상 오류가 발생하지 않았습니다.

Patroni 사용 결과

Patroni를 성공적으로 출시한 후 각 클러스터에 추가 복제본을 추가했습니다. 이제 각 클러스터에는 전환 시 스플릿 브레인의 경우 안전망을 위한 하나의 리더와 두 개의 복제본과 같은 쿼럼과 유사합니다.


Patroni는 XNUMX개월 이상 프로덕션 작업을 진행했습니다. 이 기간 동안 그는 이미 우리를 도와주었습니다. 최근 클러스터 중 하나의 리더가 AWS에서 사망했고 자동 장애 조치가 작동했으며 사용자는 계속 작동했습니다. Patroni는 주요 작업을 수행했습니다.

Patroni 사용에 대한 간략한 요약:

• 구성 변경이 용이합니다. 하나의 인스턴스에서 구성을 변경하는 것으로 충분하며 전체 클러스터로 풀업됩니다. 새 구성을 적용하기 위해 재부팅이 필요한 경우 Patroni에서 알려드립니다. Patroni는 단일 명령으로 전체 클러스터를 다시 시작할 수 있어 매우 편리합니다.
• 자동 장애 조치가 작동하고 이미 우리를 도와주었습니다.
• 애플리케이션 다운타임 없는 PostgreSQL 업데이트. 먼저 복제본을 새 버전으로 업데이트한 다음 Patroni 클러스터의 리더를 변경하고 이전 리더를 업데이트해야 합니다. 이 경우 필요한 자동 장애 조치 테스트가 발생합니다.

출처 : habr.com