Patroni 실패 사례 또는 PostgreSQL 클러스터 충돌 방법. 알렉세이 레소프스키

Patroni의 주요 목표는 PostgreSQL에 고가용성을 제공하는 것입니다. 그러나 Patroni는 기성 도구가 아닌 템플릿 일뿐입니다 (일반적으로 문서에 나와 있음). 테스트 랩에서 Patroni를 설정하면 언뜻 보기에 Patroni가 얼마나 훌륭한 도구인지, 클러스터를 중단하려는 우리의 시도를 얼마나 쉽게 처리하는지 알 수 있습니다. 그러나 실제로 프로덕션 환경에서는 테스트 랩에서처럼 모든 것이 항상 아름답고 우아하게 발생하지는 않습니다.

나 자신에 대해 조금 말해 줄게. 저는 시스템 관리자로 시작했습니다. 웹 개발에서 일했습니다. 저는 2014년부터 Data Egret에서 일하고 있습니다. 이 회사는 Postgres 분야의 컨설팅에 종사하고 있습니다. 그리고 우리는 정확히 Postgres를 제공하고 매일 Postgres와 협력하므로 운영과 관련된 전문 지식이 다릅니다.

그리고 2018년 말부터 천천히 Patroni를 사용하기 시작했습니다. 그리고 약간의 경험이 축적되었습니다. 우리는 어떻게든 그것을 진단하고, 조정하고, 모범 사례에 도달했습니다. 그리고 이 보고서에서 나는 그들에 대해 이야기할 것입니다.

Postgres 외에도 저는 Linux를 좋아합니다. 나는 그것을 찌르고 탐험하는 것을 좋아하고 코어를 수집하는 것을 좋아합니다. 저는 가상화, 컨테이너, 도커, 쿠버네티스를 좋아합니다. 오래된 관리 습관이 영향을 미치고 있기 때문에 이 모든 것이 저에게 흥미로웠습니다. 나는 모니터링을 다루는 것을 좋아합니다. 그리고 저는 복제, 백업과 같은 관리와 관련된 Postgres를 좋아합니다. 그리고 여가 시간에는 Go로 글을 씁니다. 저는 소프트웨어 엔지니어가 아닙니다. 저는 Go로 제 자신을 위해 글을 씁니다. 그리고 그것은 나에게 즐거움을줍니다.

• 많은 분들이 Postgres에 기본적으로 HA(고가용성)가 없다는 것을 알고 계실 것입니다. HA를 얻으려면 무언가를 설치하고 구성하고 노력하고 얻어야 합니다.
• 여러 가지 도구가 있으며 Patroni는 HA를 꽤 멋지고 잘 해결하는 도구 중 하나입니다. 그러나 모든 것을 테스트 랩에 넣고 실행하면 모든 것이 작동하는지 확인할 수 있고 일부 문제를 재현할 수 있으며 Patroni가 어떻게 서비스를 제공하는지 확인할 수 있습니다. 그리고 우리는 그것이 모두 훌륭하게 작동한다는 것을 알게 될 것입니다.
• 그러나 실제로 우리는 다른 문제에 직면했습니다. 그리고 이러한 문제에 대해 이야기하겠습니다.
• 우리가 어떻게 진단했는지, 무엇을 조정했는지, 도움이 되었는지 여부를 알려드리겠습니다.

• Patroni 설치 방법은 설명하지 않겠습니다. 인터넷에서 Google을 검색할 수 있고 구성 파일을 보고 모든 것이 어떻게 시작되고 구성되는지 이해할 수 있기 때문입니다. 체계, 아키텍처를 이해하고 인터넷에서 이에 대한 정보를 찾을 수 있습니다.
• 나는 다른 사람의 경험에 대해 이야기하지 않을 것입니다. 우리가 직면한 문제에 대해서만 이야기하겠습니다.
• 그리고 Patroni 및 PostgreSQL 이외의 문제에 대해서는 이야기하지 않겠습니다. 예를 들어 균형과 관련된 문제가 있는 경우 클러스터가 무너졌을 때 이에 대해 이야기하지 않겠습니다.

보고서를 시작하기 전에 약간의 면책 조항이 있습니다.

우리가 직면한 이 모든 문제는 운영 첫 6-7-8개월 동안 발생했습니다. 시간이 지남에 따라 우리는 내부 모범 사례에 도달했습니다. 그리고 우리의 문제는 사라졌습니다. 그래서 XNUMX개월쯤 전에 보고가 나왔는데, 그 때 모든 것이 머리에 생생했고 모든 것을 완벽하게 기억했습니다.

보고서를 준비하는 과정에서 나는 이미 오래된 사후 분석을 제기하고 로그를 보았습니다. 그리고 일부 세부 사항을 잊어버리거나 문제 분석 중에 일부 세부 사항을 완전히 조사할 수 없었기 때문에 어떤 시점에서는 문제가 충분히 고려되지 않았거나 정보가 부족한 것처럼 보일 수 있습니다. 그래서 지금은 실례합니다.

패트로니가 무엇인가요?

• HA 구축을 위한 템플릿입니다. 설명서에 그렇게 나와 있습니다. 제 관점에서 이것은 매우 정확한 설명입니다. Patroni는 모든 문제를 해결할 수 있는 묘책이 아닙니다. 즉, 문제를 해결하고 혜택을 가져오기 위해 노력해야 합니다.
• 이것은 모든 데이터베이스 서비스에 설치되는 에이전트 서비스이며 Postgres를 위한 일종의 초기화 시스템입니다. Postgres를 시작하고 클러스터의 토폴로지를 중지, 다시 시작, 재구성 및 변경합니다.
• 따라서 클러스터의 상태를 저장하기 위해서는 현재 표시되는 것처럼 일종의 스토리지가 필요합니다. 그리고 이러한 관점에서 Patroni는 외부 시스템에 상태를 저장하는 경로를 택했습니다. 분산 구성 스토리지 시스템입니다. Etcd, Consul, ZooKeeper 또는 kubernetes Etcd, 즉 이러한 옵션 중 하나일 수 있습니다.
• 그리고 Patroni의 기능 중 하나는 자동 파일러를 설정만 하면 상자에서 꺼낼 수 있다는 것입니다. 비교를 위해 Repmgr을 사용하면 파일러가 포함됩니다. Repmgr을 사용하면 전환이 가능하지만 자동 파일을 원하면 추가로 구성해야 합니다. Patroni에는 이미 자동 파일러가 있습니다.
• 그리고 다른 많은 것들이 있습니다. 예를 들어 구성 유지 관리, 새 복제본 쏟아 붓기, 백업 등이 있습니다. 그러나 이것은 보고서의 범위를 벗어나므로 이야기하지 않겠습니다.

그리고 작은 결과는 Patroni의 주요 작업은 클러스터가 계속 작동하고 응용 프로그램이 클러스터 토폴로지의 변경 사항을 인식하지 못하도록 자동 파일을 잘 안정적으로 수행하는 것입니다.

하지만 Patroni를 사용하기 시작하면 시스템이 조금 더 복잡해집니다. 이전에 Postgres가 있었다면 Patroni를 사용할 때 Patroni 자체를 얻고 상태가 저장된 DCS를 얻습니다. 그리고 어떻게든 작동해야 합니다. 그래서 무엇이 잘못될 수 있습니까?

파손될 수 있음:

• Postgres가 중단될 수 있습니다. 마스터 또는 복제본일 수 있으며 둘 중 하나가 실패할 수 있습니다.
• Patroni 자체가 깨질 수 있습니다.
• 상태가 저장된 DCS가 중단될 수 있습니다.
• 그리고 네트워크가 끊어질 수 있습니다.

이 모든 사항을 보고서에서 고려할 것입니다.

케이스가 많은 구성 요소를 포함한다는 관점이 아니라, 케이스가 더 복잡해질 때 고려할 것입니다. 그리고 주관적인 느낌으로 보면 이 케이스가 저에게는 어렵다, 분해하기가 어려웠습니다... 그 반대도 어떤 케이스는 가벼워서 분해하기 쉬웠습니다.

첫 번째 경우가 가장 쉽습니다. 데이터베이스 클러스터를 가져와 동일한 클러스터에 DCS 스토리지를 배포한 경우입니다. 이것은 가장 흔한 실수입니다. 이는 아키텍처를 구축할 때, 즉 서로 다른 구성 요소를 한 곳에 결합하는 실수입니다.

그래서 파일러가 있었는데 무슨 일이 있었는지 처리하러 가자.

여기서 파일러가 발생한 시점에 관심이 있습니다. 즉, 클러스터 상태가 변경된 이 순간에 관심이 있습니다.

그러나 파일러는 항상 즉각적인 것은 아닙니다. 즉, 시간 단위가 걸리지 않으며 지연될 수 있습니다. 오래 지속될 수 있습니다.

따라서 시작 시간과 종료 시간이 있습니다. 즉, 연속 이벤트입니다. 그리고 모든 이벤트를 세 가지 간격으로 나눕니다. 파일러 이전, 파일러 동안 및 파일러 이후에 시간이 있습니다. 즉, 이 타임라인의 모든 이벤트를 고려합니다.

그리고 가장 먼저, 파일러가 발생했을 때 발생한 원인, 파일러로 이어진 원인이 무엇인지 찾습니다.

로그를 보면 전형적인 Patroni 로그일 것입니다. 그는 서버가 마스터가 되었고 마스터의 역할이 이 노드로 넘어갔다고 말합니다. 여기에서 강조 표시됩니다.

다음으로 파일러가 발생한 이유, 즉 마스터 역할이 한 노드에서 다른 노드로 이동하게 만든 이벤트가 무엇인지 이해해야 합니다. 이 경우 모든 것이 간단합니다. 스토리지 시스템과 상호 작용하는 동안 오류가 발생했습니다. 주인은 DCS와 함께 일할 수 없다는 것, 즉 상호 작용에 어떤 종류의 문제가 있음을 깨달았습니다. 그리고 그는 더 이상 주인이 될 수 없다고 말하고 사임합니다. 이 "강등된 자기" 줄은 정확히 그것을 말합니다.

파일러 이전의 이벤트를 보면 마법사가 계속되는 데 문제가 된 바로 그 이유를 알 수 있습니다.

Patroni 로그를 보면 많은 오류와 시간 초과가 있음을 알 수 있습니다. 즉, Patroni 에이전트가 DCS와 작동할 수 없습니다. 이 경우 포트 8500에서 통신하는 Consul 에이전트입니다.

여기서 문제는 Patroni와 데이터베이스가 동일한 호스트에서 실행되고 있다는 것입니다. 그리고 Consul 서버는 동일한 노드에서 시작되었습니다. 서버에 로드를 생성함으로써 Consul 서버에도 문제가 발생했습니다. 그들은 제대로 의사 소통을 할 수 없었습니다.

얼마 후 부하가 가라앉았을 때 Patroni는 에이전트와 다시 통신할 수 있었습니다. 정상적인 작업이 재개되었습니다. 그리고 같은 Pgdb-2 서버가 다시 마스터가 되었습니다. 즉, 노드가 마스터의 권한을 사임하고 다시 인수하여 모든 것이 그대로 반환되는 작은 반전이 있었습니다.

그리고 이것은 잘못된 경보로 간주되거나 Patroni가 모든 것을 올바르게 수행했다고 간주될 수 있습니다. 즉, 그는 클러스터의 상태를 유지할 수 없음을 깨닫고 권한을 제거했습니다.

그리고 Consul 서버가 기지와 동일한 하드웨어에 있다는 사실 때문에 문제가 발생했습니다. 따라서 모든 부하: 디스크 또는 프로세서의 부하 여부에 관계없이 Consul 클러스터와의 상호 작용에도 영향을 미칩니다.

그리고 함께 살면 안 된다고 결정하고 Consul을 위해 별도의 클러스터를 할당했습니다. 그리고 Patroni는 이미 별도의 Consul과 함께 작업하고 있었습니다. 즉, 별도의 Consul 클러스터인 별도의 Postgres 클러스터가 있었습니다. 이 모든 것을 동거하지 않도록 휴대하고 보관하는 방법에 대한 기본 지침입니다.

옵션으로 ttl, loop_wait, retry_timeout 매개변수를 비틀 수 있습니다. 즉, 이러한 매개변수를 늘려 이러한 단기 로드 피크에서 살아남을 수 있습니다. 그러나이로드는 시간이 오래 걸릴 수 있으므로 가장 적합한 옵션은 아닙니다. 그리고 우리는 이러한 매개 변수의 한계를 넘어설 것입니다. 그리고 그것은 실제로 도움이 되지 않을 수도 있습니다.

아시다시피 첫 번째 문제는 간단합니다. 우리는 기지와 함께 DCS를 가져 와서 넣었습니다. 문제가 생겼습니다.

두 번째 문제는 첫 번째 문제와 비슷합니다. DCS 시스템과의 상호 운용성 문제가 다시 발생한다는 점에서 유사합니다.

로그를 보면 다시 통신 오류가 있음을 알 수 있습니다. 그리고 Patroni는 DCS와 상호 작용할 수 없으므로 현재 마스터가 복제 모드로 전환된다고 말합니다.

이전 마스터는 복제본이 되며, 여기서 Patroni는 정상적으로 작동합니다. pg_rewind를 실행하여 트랜잭션 로그를 되감은 다음 새 마스터에 연결하여 새 마스터를 따라잡습니다. 여기서 Patroni는 제대로 작동합니다.

여기에서 파일러 이전의 위치, 즉 파일러를 가지게 된 오류를 찾아야 합니다. 이와 관련하여 Patroni 로그는 작업하기에 매우 편리합니다. 그는 일정한 간격으로 같은 메시지를 씁니다. 그리고 이러한 로그를 빠르게 스크롤하기 시작하면 로그에서 로그가 변경된 것을 볼 수 있으며 이는 일부 문제가 시작되었음을 의미합니다. 우리는 빨리 이곳으로 돌아가 무슨 일이 일어나는지 봅니다.

그리고 정상적인 상황에서 로그는 다음과 같이 보입니다. 잠금 소유자를 확인합니다. 예를 들어 소유자가 변경된 경우 Patroni가 응답해야 하는 일부 이벤트가 발생할 수 있습니다. 하지만 이 경우에는 괜찮습니다. 오류가 시작된 곳을 찾고 있습니다.

오류가 나타나기 시작한 지점으로 스크롤하면 자동 파일오버가 있음을 알 수 있습니다. 그리고 우리의 오류는 DCS와의 상호 작용과 관련이 있고 우리의 경우에는 Consul을 사용했기 때문에 거기서 무슨 일이 일어났는지 Consul 로그도 살펴봅니다.

파일러의 시간과 Consul 로그의 시간을 대략 비교하면 Consul 클러스터의 이웃이 Consul 클러스터의 다른 구성원의 존재를 의심하기 시작했음을 알 수 있습니다.

그리고 다른 Consul 에이전트의 로그도 보면 그곳에서 일종의 네트워크 붕괴가 일어나고 있음을 알 수 있습니다. 그리고 Consul 클러스터의 모든 구성원은 서로의 존재를 의심합니다. 그리고 이것은 파일러의 원동력이었습니다.

이러한 오류 이전에 발생한 일을 살펴보면 모든 종류의 오류가 있음을 알 수 있습니다. .

가장 간단한 대답은 네트워크를 복구하는 것입니다. 하지만 연단에 서 있는 저에게는 이렇게 말하기가 쉽습니다. 그러나 고객이 항상 네트워크를 수리할 여력이 있는 것은 아닙니다. 그는 DC에 거주할 수 있으며 네트워크를 수리할 수 없거나 장비에 영향을 미칠 수 있습니다. 따라서 몇 가지 다른 옵션이 필요합니다.

옵션이 있습니다:

• 제 생각에는 문서에서도 가장 간단한 옵션은 Consul 검사를 비활성화하는 것입니다. 즉, 단순히 빈 배열을 전달하는 것입니다. 그리고 우리는 영사 요원에게 수표를 사용하지 말라고 지시합니다. 이러한 검사를 통해 이러한 네트워크 스톰을 무시하고 파일러를 시작하지 않을 수 있습니다.
• 또 다른 옵션은 raft_multiplier를 다시 확인하는 것입니다. 이것은 Consul 서버 자체의 매개변수입니다. 기본적으로 이 값은 5로 설정됩니다. 스테이징 환경에 대한 설명서에서 이 값을 권장합니다. 실제로 이것은 Consul 네트워크 구성원 간의 메시징 빈도에 영향을 미칩니다. 실제로 이 매개변수는 Consul 클러스터 구성원 간의 서비스 통신 속도에 영향을 미칩니다. 그리고 프로덕션의 경우 노드가 메시지를 더 자주 교환하도록 이미 줄이는 것이 좋습니다.
• 우리가 생각해낸 또 다른 옵션은 운영 체제의 프로세스 스케줄러에 대한 다른 프로세스 중에서 Consul 프로세스의 우선 순위를 높이는 것입니다. 이러한 "좋은" 매개변수가 있으며 스케줄링할 때 OS 스케줄러가 고려하는 프로세스의 우선순위를 결정합니다. 우리는 또한 Consul 에이전트에 대한 nice 값을 줄였습니다. 운영 체제가 Consul 프로세스에 작업하고 코드를 실행할 수 있는 더 많은 시간을 제공하도록 우선 순위를 높였습니다. 우리의 경우 이것은 우리의 문제를 해결했습니다.
• 또 다른 옵션은 Consul을 사용하지 않는 것입니다. Etcd의 열렬한 지지자인 친구가 있습니다. 그리고 우리는 Etcd 또는 Consul 중 어느 것이 더 나은지 그와 정기적으로 논쟁합니다. 그러나 어느 것이 더 낫다는 측면에서 우리는 일반적으로 Consul이 데이터베이스가 있는 각 노드에서 실행되어야 하는 에이전트를 가지고 있다는 데 동의합니다. 즉, Patroni와 Consul 클러스터의 상호 작용은 이 에이전트를 거칩니다. 그리고 이 에이전트는 병목 현상이 됩니다. 에이전트에 문제가 발생하면 Patroni는 더 이상 Consul 클러스터와 작업할 수 없습니다. 그리고 이것이 문제입니다. Etcd 계획에 에이전트가 없습니다. Patroni는 Etcd 서버 목록과 직접 작업할 수 있으며 이미 서버와 통신할 수 있습니다. 이와 관련하여 회사에서 Etcd를 사용하는 경우 Consul보다 Etcd가 더 나은 선택이 될 것입니다. 그러나 우리 고객은 고객이 선택하고 사용하는 것에 항상 제한을 받습니다. 그리고 우리는 모든 고객을 위해 대부분 Consul을 보유하고 있습니다.
• 그리고 마지막 포인트는 매개변수 값을 수정하는 것입니다. 단기 네트워크 문제가 짧고 이러한 매개변수의 범위를 벗어나지 않기를 바라면서 이러한 매개변수를 높일 수 있습니다. 이렇게 하면 일부 네트워크 문제가 발생할 경우 Patroni의 자동 파일 공격성을 줄일 수 있습니다.

Patroni를 사용하는 많은 사람들이 이 명령에 익숙하다고 생각합니다.

이 명령은 클러스터의 현재 상태를 보여줍니다. 그리고 언뜻 보기에 이 그림은 정상으로 보일 수 있습니다. 마스터가 있고 복제본이 있으며 복제 지연이 없습니다. 그러나 이 그림은 이 클러스터에 XNUMX개가 아닌 XNUMX개의 노드가 있어야 한다는 것을 알기 전까지는 정상입니다.

따라서 자동 파일이 있습니다. 이 자동 파일 이후 복제본이 사라졌습니다. 우리는 그녀가 왜 사라졌는지 알아내고 그녀를 다시 데려와 복원해야 합니다. 그리고 다시 로그로 이동하여 자동 파일오버가 있는 이유를 확인합니다.

이 경우 두 번째 복제본이 마스터가 되었습니다. 여기 괜찮습니다.

그리고 떨어졌고 클러스터에 없는 복제본을 살펴봐야 합니다. Patroni 로그를 열어보니 pg_rewind 단계에서 클러스터에 연결하는 과정에서 문제가 발생한 것을 확인할 수 있습니다. 클러스터에 연결하려면 트랜잭션 로그를 되감고 마스터에서 필요한 트랜잭션 로그를 요청하고 이를 사용하여 마스터를 따라잡아야 합니다.

이 경우 트랜잭션 로그가 없으며 복제본을 시작할 수 없습니다. 따라서 오류와 함께 Postgres를 중지합니다. 따라서 클러스터에 없습니다.

클러스터에 없는 이유와 로그가 없는 이유를 이해해야 합니다. 우리는 새 마스터에게 가서 그가 로그에 무엇을 가지고 있는지 살펴봅니다. pg_rewind가 완료되었을 때 체크포인트가 발생한 것으로 나타났습니다. 그리고 이전 트랜잭션 로그 중 일부는 단순히 이름이 변경되었습니다. 이전 마스터가 새 마스터에 연결하고 이러한 로그를 쿼리하려고 시도했을 때 이미 이름이 변경되어 존재하지 않았습니다.

이러한 이벤트가 발생했을 때의 타임스탬프를 비교했습니다. 그리고 그 차이는 문자 그대로 150밀리초입니다. 즉, 체크포인트가 369밀리초에 완료되고 WAL 세그먼트의 이름이 변경되었습니다. 그리고 문자 그대로 517에서 150밀리초 후에 이전 복제본에서 되감기가 시작되었습니다. 즉, 문자 그대로 150밀리초면 충분하여 복제본이 연결되어 수익을 얻을 수 없습니다.

옵션은 무엇입니까?

처음에는 복제 슬롯을 사용했습니다. 우리는 그것이 좋다고 생각했습니다. 작동 첫 단계에서 우리는 슬롯을 껐습니다. 슬롯에 많은 WAL 세그먼트가 누적되면 마스터를 삭제할 수 있는 것처럼 보였습니다. 그는 떨어질 것이다. 우리는 슬롯없이 한동안 고생했습니다. 그리고 우리는 슬롯이 필요하다는 것을 깨달았고 슬롯을 반환했습니다.

그러나 여기에는 문제가 있습니다. 마스터가 복제본으로 이동하면 슬롯을 삭제하고 슬롯과 함께 WAL 세그먼트를 삭제합니다. 그리고 이 문제를 없애기 위해 wal_keep_segments 매개변수를 높이기로 했습니다. 기본값은 8 세그먼트입니다. 우리는 그것을 1으로 올리고 얼마나 많은 여유 공간이 있는지 확인했습니다. 그리고 wal_keep_segments를 위해 000GB를 기부했습니다. 즉, 전환할 때 모든 노드에서 항상 16GB의 트랜잭션 로그를 예약합니다.

또한 장기 유지 관리 작업과 여전히 관련이 있습니다. 복제본 중 하나를 업데이트해야 한다고 가정해 보겠습니다. 그리고 우리는 그것을 끄고 싶습니다. 소프트웨어, 아마도 운영 체제 등을 업데이트해야 합니다. 복제본을 끄면 해당 복제본의 슬롯도 제거됩니다. 작은 wal_keep_segments를 사용하면 복제본이 오랫동안 없으면 트랜잭션 로그가 손실됩니다. 우리는 복제본을 생성하고 중지된 트랜잭션 로그를 요청하지만 마스터에는 없을 수 있습니다. 복제본도 연결할 수 없습니다. 따라서 우리는 많은 양의 잡지를 보유하고 있습니다.

우리는 생산 기지를 가지고 있습니다. 이미 진행 중인 프로젝트가 있습니다.

파일러가 있었습니다. 우리는 들어가서 살펴 보았습니다. 모든 것이 정상이고 복제본이 제자리에 있으며 복제 지연이 없습니다. 로그에도 오류가 없으며 모든 것이 정상입니다.

제품 팀은 일부 데이터가 있어야 한다고 말하지만 하나의 소스에서 볼 수 있지만 데이터베이스에서는 볼 수 없습니다. 그리고 우리는 그들에게 무슨 일이 일어났는지 이해해야 합니다.

pg_rewind가 그것들을 놓친 것이 분명합니다. 우리는 이것을 즉시 이해했지만 무슨 일이 일어나고 있는지 보러갔습니다.

로그에서 언제 파일러가 발생했는지, 누가 마스터가 되었는지, 누가 이전 마스터인지, 언제 복제본이 되기를 원했는지 확인할 수 있습니다. 길을 잃었다.

이전 마스터가 재부팅되었습니다. 그리고 Patroni는 자동 실행에 등록되었습니다. 패트로니를 런칭했습니다. 그런 다음 그는 Postgres를 시작했습니다. 보다 정확하게는 Postgres를 시작하기 전에 복제본으로 만들기 전에 Patroni는 pg_rewind 프로세스를 시작했습니다. 이에 따라 그는 트랜잭션 로그의 일부를 지우고 새 로그를 다운로드하여 연결했습니다. 여기서 Patroni는 예상대로 현명하게 작업했습니다. 클러스터가 복원되었습니다. 우리는 파일러 3개 노드 다음에 3개 노드를 가졌습니다. 모든 것이 멋집니다.

일부 데이터가 손실되었습니다. 그리고 우리는 우리가 얼마나 많은 것을 잃었는지 이해해야 합니다. 되감기 한 순간을 찾고 있습니다. 그러한 일지 항목에서 찾을 수 있습니다. 되감기가 시작되어 거기에서 무언가를 하고 끝났습니다.

트랜잭션 로그에서 이전 마스터가 중단된 위치를 찾아야 합니다. 이 경우 이것이 마크입니다. 그리고 우리는 두 번째 표시, 즉 이전 마스터와 새 마스터가 다른 거리가 필요합니다.

일반적인 pg_wal_lsn_diff를 사용하여 이 두 표시를 비교합니다. 이 경우 17MB를 얻습니다. 많든 적든 모두가 스스로 결정합니다. 누군가에게는 17MB가 많지 않기 때문에 누군가에게는 많고 용납할 수 없는 것입니다. 여기에서 각 개인은 비즈니스의 필요에 따라 스스로 결정합니다.

그러나 우리 스스로 무엇을 알아냈습니까?

먼저, 스스로 결정해야 합니다. 시스템 재부팅 후 자동 시작하려면 항상 Patroni가 필요합니까? 종종 우리는 옛 스승에게 가서 그가 얼마나 멀리 갔는지 확인해야 합니다. 아마도 트랜잭션 로그의 세그먼트를 검사하고 거기에 무엇이 있는지 확인하십시오. 그리고 이 데이터를 잃어버릴 수 있는지 또는 이 데이터를 꺼내기 위해 이전 마스터를 독립 실행형 모드로 실행해야 하는지 이해합니다.

그런 다음 이 데이터를 폐기할 수 있는지 또는 복원할 수 있는지 결정하고 이 노드를 복제본으로 클러스터에 연결해야 합니다.

또한 "maximum_lag_on_failover" 매개변수가 있습니다. 기본적으로 메모리가 필요한 경우 이 매개변수의 값은 1MB입니다.

그는 어떻게 일합니까? 복제 지연으로 인해 복제본이 1MB의 데이터 뒤에 있는 경우 이 복제본은 선거에 참여하지 않습니다. 그리고 갑자기 파일오버가 발생하면 Patroni는 어떤 복제본이 뒤쳐져 있는지 살펴봅니다. 많은 수의 트랜잭션 로그에 뒤처지면 마스터가 될 수 없습니다. 이것은 많은 데이터 손실을 방지하는 매우 우수한 보안 기능입니다.

하지만 여기에 Patroni 클러스터와 DCS의 복제 지연이 일정 간격으로 업데이트된다는 문제가 있습니다. 30초가 기본 ttl 값이라고 생각합니다.

따라서 DCS에서 복제본에 대해 하나의 복제 지연이 있는 상황이 있을 수 있지만 실제로는 완전히 다른 지연이 있거나 지연이 전혀 없을 수 있습니다. 즉, 이것은 실시간이 아닙니다. 그리고 항상 실제 그림을 반영하는 것은 아닙니다. 그리고 그것에 멋진 논리를 할 가치가 없습니다.

그리고 손실의 위험은 항상 남아 있습니다. 그리고 최악의 경우에는 하나의 공식이 있고, 평균적인 경우에는 또 다른 공식이 있습니다. 즉, Patroni 구현을 계획하고 손실될 수 있는 데이터의 양을 평가할 때 이러한 공식에 의존하고 손실될 수 있는 데이터의 양을 대략적으로 상상해야 합니다.

그리고 좋은 소식이 있습니다. 이전 마스터가 작업을 진행하면 일부 백그라운드 프로세스로 인해 작업을 진행할 수 있습니다. 즉, 일종의 autovacuum이 있었고 데이터를 작성하고 트랜잭션 로그에 저장했습니다. 그리고 우리는 이 데이터를 쉽게 무시하고 잃을 수 있습니다. 이것에는 문제가 없습니다.

이것이 maximum_lag_on_failover가 설정되고 파일러가 발생한 경우 로그가 표시되는 방식이며 새 마스터를 선택해야 합니다. 레플리카는 자신이 선거에 참여할 능력이 없다고 평가한다. 그리고 그녀는 리더 경주에 참가하기를 거부합니다. 그리고 새로운 마스터가 선택될 때까지 기다렸다가 연결할 수 있습니다. 이는 데이터 손실에 대한 추가 조치입니다.

여기 제품에 Postgres에 문제가 있다고 작성한 제품 팀이 있습니다. 동시에 SSH를 통해 사용할 수 없기 때문에 마스터 자체에 액세스할 수 없습니다. 그리고 자동 파일도 발생하지 않습니다.

이 호스트는 강제로 재부팅되었습니다. 재부팅으로 인해 자동 파일이 발생했지만 지금은 이해하는 것처럼 수동 자동 파일을 수행할 수 있었습니다. 그리고 재부팅 후 현재 마스터에 대해 가지고 있는 것을 이미 볼 것입니다.

동시에 우리는 디스크에 문제가 있다는 것을 미리 알고 있었습니다. 즉, 어디를 파고 무엇을 찾아야 하는지 모니터링을 통해 이미 알고 있었습니다.

우리는 postgres 로그에 들어가서 거기에서 무슨 일이 일어나고 있는지 보기 시작했습니다. 우리는 커밋이 XNUMX, XNUMX, XNUMX초 동안 지속되는 것을 보았습니다. 이는 전혀 정상적이지 않습니다. 우리는 autovacuum이 매우 느리고 이상하게 시작되는 것을 보았습니다. 그리고 우리는 디스크에서 임시 파일을 보았습니다. 즉, 이들은 모두 디스크 문제의 지표입니다.

시스템 dmesg(커널 로그)를 조사했습니다. 그리고 디스크 중 하나에 문제가 있음을 확인했습니다. 디스크 하위 시스템은 소프트웨어 Raid였습니다. 우리는 /proc/mdstat를 살펴보고 하나의 드라이브가 누락되었음을 확인했습니다. 즉, 8개의 디스크로 구성된 Raid가 있는데 하나가 없습니다. 슬라이드를 자세히 보면 출력에서 ​​sde가 없다는 것을 알 수 있습니다. 조건부로 말하면 디스크가 떨어졌습니다. 이로 인해 디스크 문제가 발생했고 Postgres 클러스터로 작업할 때 응용 프로그램에서도 문제가 발생했습니다.

그리고이 경우 Patroni는 서버 상태, 디스크 상태를 모니터링하는 작업이 없기 때문에 Patroni는 어떤 식 으로든 우리를 돕지 않을 것입니다. 그리고 우리는 이러한 상황을 외부 모니터링을 통해 모니터링해야 합니다. 외부 모니터링에 디스크 모니터링을 신속하게 추가했습니다.

펜싱이나 워치독 소프트웨어가 우리를 도울 수 있을까? 우리는 문제가 발생하는 동안 Patroni가 DCS 클러스터와 계속 상호 작용하고 문제를 보지 않았기 때문에 그가 우리를 거의 도와주지 않았을 것이라고 생각했습니다. 즉, DCS와 Patroni의 관점에서 볼 때 실제로 디스크에 문제가 있었지만 데이터베이스 가용성에 문제가 있었지만 클러스터에는 모든 것이 잘되었습니다.

내 생각에 이것은 내가 아주 오랫동안 조사한 가장 이상한 문제 중 하나이며 많은 로그를 읽고 다시 선택하여 클러스터 시뮬레이터라고 불렀습니다.

문제는 이전 마스터가 일반 복제본이 될 수 없다는 것입니다. 즉, Patroni가 시작했고 Patroni는 이 노드가 복제본으로 존재하지만 동시에 일반 복제본이 아님을 보여주었습니다. 이제 그 이유를 알게 될 것입니다. 이것이 내가 그 문제의 분석에서 간직한 것입니다.

어떻게 시작되었습니까? 이전 문제와 마찬가지로 디스크 브레이크로 시작되었습니다. 우리는 XNUMX, XNUMX초 동안 커밋을 했습니다.

연결이 끊겼습니다. 즉, 클라이언트가 끊어졌습니다.

다양한 정도의 막힘이 있었습니다.

따라서 디스크 하위 시스템의 반응이 좋지 않습니다.

그리고 저에게 가장 신비한 것은 도착한 즉각적인 종료 요청입니다. Postgres에는 세 가지 종료 모드가 있습니다.

• 모든 클라이언트가 스스로 연결을 끊을 때까지 기다리는 것은 우아합니다.
• 우리가 종료하려고 하기 때문에 클라이언트 연결을 강제로 끊을 때 빠릅니다.
• 그리고 즉시. 이 경우 Immediate는 클라이언트에게 종료하라고 지시하지도 않고 경고 없이 종료됩니다. 그리고 모든 클라이언트에게 운영 체제는 이미 RST 메시지(연결이 중단되었고 클라이언트가 더 이상 잡을 것이 없다는 TCP 메시지)를 보냅니다.

누가 이 신호를 보냈습니까? Postgres 백그라운드 프로세스는 이러한 신호를 서로에게 보내지 않습니다. 즉, 이것은 kill-9입니다. 그들은 그런 것들을 서로에게 보내지 않고 그런 것들에만 반응합니다. 즉, 이것은 Postgres의 긴급 재시작입니다. 누가 보냈는지 모르겠습니다.

나는 "마지막" 명령을 보았고 우리와 함께 이 서버에 로그인한 한 사람을 보았지만 너무 부끄러워서 질문을 할 수 없었습니다. 아마도 kill -9 였을 것입니다. 로그에 kill -9가 표시됩니다. Postgres는 kill -9가 필요하다고 말했지만 로그에서 보지 못했습니다.

자세히 살펴보면 Patroni가 꽤 오랜 시간(54초) 동안 로그에 쓰지 않는 것을 볼 수 있습니다. 그리고 두 타임스탬프를 비교하면 약 54초 동안 메시지가 없었습니다.

그리고 이 시간 동안 자동 파일이 있었습니다. Patroni는 여기서 다시 훌륭한 일을 했습니다. 우리의 옛 스승님을 만날 수 없었습니다. 그에게 무슨 일이 일어났습니다. 그리고 새로운 주인의 선출이 시작되었습니다. 여기서는 모든 것이 잘 풀렸습니다. 우리의 pgsql01은 새로운 리더가 되었습니다.

마스터가 된 복제본이 있습니다. 그리고 두 번째 답변이 있습니다. 그리고 두 번째 복제본에 문제가 있었습니다. 그녀는 재구성을 시도했습니다. 내가 알기로 그녀는 recovery.conf를 변경하고 Postgres를 다시 시작하고 새 마스터에 연결하려고 했습니다. 그녀는 시도하고 있는 메시지를 10초마다 작성하지만 성공하지 못합니다.

그리고 이러한 시도 중에 즉시 종료 신호가 이전 마스터에 도착합니다. 마스터가 다시 시작됩니다. 또한 이전 마스터가 재부팅되기 때문에 복구가 중지됩니다. 즉, 복제본이 종료 모드에 있기 때문에 복제본에 연결할 수 없습니다.

어느 시점에서 작동했지만 복제가 시작되지 않았습니다.

유일한 추측은 recovery.conf에 이전 마스터 주소가 있다는 것입니다. 그리고 새 마스터가 나타나면 두 번째 복제본은 여전히 ​​이전 마스터에 연결을 시도했습니다.

Patroni가 두 번째 복제본에서 시작했을 때 노드가 시작되었지만 복제할 수 없었습니다. 그리고 다음과 같은 복제 지연이 형성되었습니다. 즉, 세 개의 노드가 모두 제자리에 있었지만 두 번째 노드가 뒤처졌습니다.

동시에 기록된 로그를 보면 트랜잭션 로그가 다르기 때문에 복제가 시작되지 않는 것을 볼 수 있습니다. 마스터가 제공하는 트랜잭션 로그(recovery.conf에 지정됨)는 단순히 현재 노드에 맞지 않습니다.

그리고 여기서 나는 실수를 저질렀다. 우리가 잘못된 마스터에 연결하고 있다는 내 가설을 테스트하기 위해 와서 recovery.conf에 무엇이 있는지 확인해야 했습니다. 그러나 나는 이것을 처리하고 있었고 나에게 발생하지 않았거나 복제본이 뒤쳐져 다시 채워야한다는 것을 알았습니다. 즉, 어떻게 든 부주의하게 작업했습니다. 이것은 내 관절이었습니다.

30분 후 관리자가 이미 왔습니다. 즉, 복제본에서 Patroni를 다시 시작했습니다. 나는 이미 그것을 끝내고 다시 채워야한다고 생각했습니다. 그리고 저는 Patroni를 다시 시작하겠습니다. 아마도 좋은 결과가 나올 것입니다. 복구가 시작되었습니다. 그리고 기지가 열리면 연결을 수락할 준비가 되었습니다.

복제가 시작되었습니다. 그러나 XNUMX분 후 그녀는 트랜잭션 로그가 그녀에게 적합하지 않다는 오류와 함께 떨어졌습니다.

다시 시작해야겠다고 생각했습니다. Patroni를 다시 시작했고 Postgres를 다시 시작하지 않고 Patroni를 다시 시작했습니다. 마술처럼 데이터베이스를 시작할 수 있기를 바랍니다.

복제가 다시 시작되었지만 트랜잭션 로그의 표시가 달라 이전 시작 시도와 동일하지 않았습니다. 복제가 다시 중지되었습니다. 그리고 메시지는 이미 약간 달랐습니다. 그리고 그것은 나에게 그다지 유익하지 않았습니다.

그런 다음 나에게 발생합니다. Postgres를 다시 시작하면 현재 마스터에 체크 포인트를 만들어 트랜잭션 로그의 포인트를 조금 앞으로 이동하여 복구가 다른 순간부터 시작되도록합니까? 또한 우리는 여전히 WAL의 주식을 가지고 있었습니다.

Patroni를 다시 시작하고 마스터에서 몇 개의 체크포인트를 수행했으며 복제본이 열렸을 때 몇 개의 다시 시작점을 수행했습니다. 그리고 도움이 되었습니다. 나는 그것이 왜 도움이 되었고 어떻게 작동하는지 오랫동안 생각했습니다. 그리고 복제가 시작되었습니다. 그리고 복제가 더 이상 찢어지지 않았습니다.

나에게 그러한 문제는 더 불가사의한 문제 중 하나이며, 그곳에서 실제로 무슨 일이 일어났는지 여전히 의아해합니다.

여기에 어떤 의미가 있습니까? Patroni는 오류 없이 의도한 대로 작동할 수 있습니다. 그러나 동시에 이것이 우리에게 모든 것이 괜찮다는 100% 보장은 아닙니다. 복제본이 시작될 수 있지만 반쯤 작동하는 상태일 수 있으며 애플리케이션은 오래된 데이터가 있기 때문에 이러한 복제본과 함께 작동할 수 없습니다.

그리고 파일러 이후에는 클러스터에 모든 것이 정상인지, 즉 필요한 복제본 수가 있고 복제 지연이 없는지 항상 확인해야 합니다.

이러한 문제를 해결하면서 권장 사항을 제시하겠습니다. 나는 그것들을 두 개의 슬라이드로 결합하려고 노력했습니다. 아마도 모든 이야기는 두 개의 슬라이드로 결합되어 말할 수 있습니다.

Patroni를 사용하려면 모니터링이 있어야 합니다. autofileover가 있다는 것을 모르면 클러스터를 제어할 수 없기 때문에 autofileover가 언제 발생했는지 항상 알아야 합니다. 그리고 그것은 나쁘다.

각 파일러 이후에는 항상 클러스터를 수동으로 확인해야 합니다. 우리는 항상 최신 복제본 수를 유지하고, 복제 지연이 없고, Patroni와 DCS 시스템을 통해 스트리밍 복제와 관련된 로그에 오류가 없는지 확인해야 합니다.

자동화는 성공적으로 작동할 수 있으며 Patroni는 매우 좋은 도구입니다. 작동할 수 있지만 클러스터를 원하는 상태로 가져오지는 않습니다. 그리고 우리가 그것에 대해 알지 못한다면, 우리는 곤경에 처할 것입니다.

그리고 Patroni는 만병통치약이 아닙니다. 우리는 여전히 Postgres가 작동하는 방식, 복제가 작동하는 방식, Patroni가 Postgres와 작동하는 방식, 노드 간 통신이 제공되는 방식을 이해해야 합니다. 이것은 손의 문제를 해결하기 위해 필요합니다.

진단 문제에 어떻게 접근합니까? 다른 클라이언트와 작업하고 아무도 ELK 스택을 가지고 있지 않고 6개의 콘솔과 2개의 탭을 열어 로그를 정렬해야 했습니다. 한 탭에는 각 노드에 대한 Patroni 로그가 있고 다른 탭에는 Consul 로그 또는 필요한 경우 Postgres가 있습니다. 이것을 진단하는 것은 매우 어렵습니다.

나는 어떤 접근 방식을 취했습니까? 첫째, 파일러가 언제 도착했는지 항상 확인합니다. 그리고 저에게 이것은 분수령입니다. 파일러 이전, 파일러 동안, 파일러 이후에 무슨 일이 일어났는지 살펴봅니다. fileover에는 두 가지 표시가 있습니다. 시작 시간과 종료 시간입니다.

다음으로 파일러 이전의 이벤트에 대한 로그를 살펴봅니다. 즉, 파일러가 발생한 이유를 찾습니다.

그리고 이것은 그러한 상황이 발생하지 않도록 무슨 일이 일어났고 앞으로 무엇을 할 수 있는지 이해하는 그림을 제공합니다(결과적으로 파일러가 없습니다).

그리고 우리는 보통 어디를 봅니까? 나는 본다:

• 먼저 Patroni 로그로 이동합니다.
• 다음으로 Patroni 로그에서 찾은 내용에 따라 Postgres 로그 또는 DCS 로그를 확인합니다.
• 또한 시스템 로그를 통해 파일러의 원인을 파악할 수도 있습니다.

Patroni에 대해 어떻게 생각합니까? 저는 Patroni와 매우 좋은 관계를 유지하고 있습니다. 제 생각에는 이것이 오늘날 최고입니다. 나는 다른 많은 제품을 알고 있습니다. 이들은 Stolon, Repmgr, Pg_auto_failover, PAF입니다. 4 도구. 나는 그들 모두를 시도했다. 제가 가장 좋아하는 패트로니입니다.

그들이 저에게 "Patroni를 추천합니까?"라고 묻는다면. 나는 Patroni를 좋아하기 때문에 예라고 말할 것입니다. 그리고 나는 그것을 요리하는 법을 배웠다고 생각합니다.

제가 언급한 문제 외에 Patroni에 어떤 다른 문제가 있는지 알고 싶으시면 언제든지 페이지를 확인하세요. 문제 GitHub에서. 다양한 이야기가 있으며 많은 흥미로운 문제가 논의됩니다. 결과적으로 일부 버그가 도입되고 해결되었습니다. 즉, 이것은 흥미로운 읽기입니다.

발에 총을 쏘는 사람들에 대한 흥미로운 이야기가 있습니다. 매우 유익합니다. 귀하는 그렇게 할 필요가 없다는 것을 읽고 이해합니다. 나는 나 자신을 똑딱 거렸다.

그리고 이 프로젝트를 개발한 Zalando, 즉 Alexander Kukushkin과 Alexey Klyukin에게 큰 감사를 전하고 싶습니다. Aleksey Klyukin은 공동 저자 중 한 명이며 더 이상 Zalando에서 일하지 않지만 이 제품으로 작업을 시작한 두 사람입니다.

그리고 저는 Patroni가 매우 멋진 것이라고 생각합니다. 나는 그녀가 존재한다는 것이 기쁘고 그녀에게 흥미 롭습니다. 그리고 Patroni에 패치를 작성하는 모든 기여자에게 큰 감사를 드립니다. 패트로니가 나이가 들수록 더 성숙해지고, 멋있고, 능률적이 되길 바랍니다. 이미 기능적이지만 더 나아지기를 바랍니다. 따라서 Patroni를 사용할 계획이라면 두려워하지 마십시오. 이것은 좋은 솔루션이며 구현하고 사용할 수 있습니다.

그게 다야. 질문이 있으면 물어보십시오.

질문

신고해 주셔서 감사합니다! 파일러 이후에도 매우 주의 깊게 살펴봐야 하는 경우 자동 파일러가 필요한 이유는 무엇입니까?

새 물건이기 때문입니다. 우리는 그녀와 함께한 지 XNUMX년밖에 되지 않았습니다. 안전한 것이 좋습니다. 우리는 들어와서 모든 것이 제대로 된 것인지 확인하고 싶습니다. 이것은 성인 불신의 수준입니다. 다시 확인하고 확인하는 것이 좋습니다.

예를 들어 아침에 가서 봤는데 맞죠?

아침이 아니라 보통 거의 즉시 자동 파일에 대해 배웁니다. 알림을 받고 자동 파일이 발생한 것을 확인합니다. 우리는 거의 즉시 가서 봅니다. 그러나 이러한 모든 검사는 모니터링 수준으로 가져와야 합니다. REST API를 통해 Patroni에 접속하면 히스토리가 있습니다. 기록을 통해 파일러가 발생한 타임스탬프를 볼 수 있습니다. 이를 바탕으로 모니터링이 가능합니다. 얼마나 많은 이벤트가 있었는지 역사를 볼 수 있습니다. 이벤트가 더 있으면 자동 파일이 발생한 것입니다. 가서 볼 수 있습니다. 또는 모니터링 자동화를 통해 모든 복제본이 제자리에 있고 지연이 없으며 모든 것이 정상인지 확인했습니다.

감사합니다!

훌륭한 이야기에 감사드립니다! Postgres 클러스터에서 멀리 떨어진 곳으로 DCS 클러스터를 이동한 경우 이 클러스터도 주기적으로 서비스해야 합니까? DCS 클러스터의 일부를 꺼야 하는 모범 사례는 무엇이며 이와 관련이 있습니까? 이 전체 구조는 어떻게 살아남습니까? 그리고 이러한 작업을 어떻게 수행합니까?

한 회사의 경우 구성 요소 중 하나 또는 여러 구성 요소가 실패하면 어떻게 되는지 문제의 매트릭스를 만드는 것이 필요했습니다. 이 매트릭스에 따라 모든 구성 요소를 순차적으로 검토하고 이러한 구성 요소에 오류가 발생할 경우 시나리오를 구축합니다. 따라서 각 장애 시나리오에 대해 복구를 위한 실행 계획을 세울 수 있습니다. 그리고 DCS의 경우 표준 인프라의 일부로 제공됩니다. 그리고 관리자가 그것을 관리하고 우리는 이미 그것을 관리하는 관리자와 사고 발생시 그것을 고칠 수 있는 능력에 의존하고 있습니다. DCS가 전혀 없으면 배포하지만 인프라에 대한 책임이 없기 때문에 특별히 모니터링하지는 않지만 모니터링 방법과 대상에 대한 권장 사항을 제공합니다.

즉, Patroni를 비활성화하고, 파일러를 비활성화하고, 호스트를 사용하기 전에 모든 것을 비활성화해야 한다는 것을 올바르게 이해했습니까?

DCS 클러스터에 있는 노드 수에 따라 다릅니다. 노드가 많고 노드 중 하나만(복제본) 비활성화하면 클러스터는 쿼럼을 유지합니다. 그리고 Patroni는 계속 운영됩니다. 그리고 아무것도 트리거되지 않습니다. 더 많은 노드에 영향을 미치는 복잡한 작업이 있는 경우, 그 작업이 없으면 쿼럼이 망가질 수 있습니다. 예, Patroni를 일시 중지하는 것이 합리적일 수 있습니다. 그에 상응하는 명령이 있습니다 - patronictl pause, patronictl resume. 일시 중지하면 자동 파일러가 그 시간에 작동하지 않습니다. DCS 클러스터에서 유지 관리를 수행한 다음 일시 중지를 해제하고 계속 작동합니다.

대단히 감사합니다!

신고해 주셔서 대단히 감사합니다! 제품 팀은 데이터 손실에 대해 어떻게 생각합니까?

제품 팀은 신경 쓰지 않고 팀 리더는 걱정합니다.

어떤 보장이 있습니까?

보장은 매우 어렵습니다. Alexander Kukushkin은 "RPO 및 RTO를 계산하는 방법"이라는 보고서를 가지고 있습니다. 즉, 복구 시간과 손실될 수 있는 데이터의 양입니다. 이 슬라이드를 찾아서 공부해야 할 것 같아요. 내가 기억하는 한, 이러한 것들을 계산하는 방법에 대한 구체적인 단계가 있습니다. 얼마나 많은 거래를 잃을 수 있는지, 얼마나 많은 데이터를 잃을 수 있는지. 옵션으로 Patroni 수준에서 동기식 복제를 사용할 수 있지만 이것은 양날의 검입니다. 데이터 신뢰성이 있거나 속도가 떨어집니다. 동기식 복제가 있지만 데이터 손실에 대해 100% 보호를 보장하지는 않습니다.

Alexey, 훌륭한 보고서에 감사드립니다! 제로 레벨 보호를 위해 Patroni를 사용한 경험이 있습니까? 즉, 동기 대기와 함께? 이것이 첫 번째 질문입니다. 그리고 두 번째 질문입니다. 다른 솔루션을 사용했습니다. 우리는 Repmgr을 사용했지만 autofiler가 없었고 이제 autofiler를 포함할 계획입니다. 그리고 우리는 Patroni를 대안 솔루션으로 생각합니다. Repmgr과 비교할 때 장점은 무엇입니까?

첫 번째 질문은 동기식 복제본에 관한 것이었습니다. 모두가 두려워하기 때문에 여기에서 아무도 동기식 복제를 사용하지 않습니다. 발표자 메모). 그러나 우리는 동기식 복제 클러스터에 최소 XNUMX개의 노드가 있어야 한다는 자체 규칙을 개발했습니다. 왜냐하면 노드가 XNUMX개 있고 마스터 또는 복제본이 실패하면 Patroni가 이 노드를 독립형 모드로 전환하여 애플리케이션이 계속해서 일하다. 이 경우 데이터 손실의 위험이 있습니다.

두 번째 질문과 관련하여 우리는 Repmgr을 사용해 왔으며 역사적인 이유로 여전히 일부 클라이언트와 함께 사용하고 있습니다. 무엇을 말할 수 있습니까? Patroni는 기본적으로 자동 파일러와 함께 제공되며, Repmgr은 활성화해야 하는 추가 기능으로 자동 파일러와 함께 제공됩니다. 각 노드에서 Repmgr 데몬을 실행한 다음 자동 파일러를 구성할 수 있습니다.

Repmgr은 Postgres 노드가 활성 상태인지 확인합니다. Repmgr 프로세스는 서로의 존재를 확인하는데 이것은 매우 효율적인 접근 방식이 아닙니다. 대규모 Repmgr 클러스터가 여러 개의 작은 클러스터로 분리되어 계속 작동할 수 있는 복잡한 네트워크 격리 사례가 있을 수 있습니다. 나는 오랫동안 Repmgr을 따르지 않았거나 수정되었을 수도 있고 ... 아닐 수도 있습니다. 그러나 Patroni의 Stolon과 같이 DCS에서 클러스터 상태에 대한 정보를 제거하는 것이 가장 실행 가능한 옵션입니다.

Alexey, 질문이 있습니다. 첫 번째 예 중 하나에서는 로컬 시스템에서 원격 호스트로 DCS를 이동했습니다. 우리는 네트워크가 고유한 특성을 가지고 있으며 자체적으로 존재한다는 것을 이해합니다. 어떤 이유로 DCS 클러스터를 사용할 수 없게 되면 어떻게 됩니까? 이유는 말하지 않겠습니다. 네트워커의 비뚤어진 손에서 실제 문제에 이르기까지 많은 이유가있을 수 있습니다.

크게 말하지는 않았지만 DCS 클러스터도 장애 조치되어야 합니다. 즉, 쿼럼이 충족되려면 노드 수가 홀수여야 합니다. DCS 클러스터를 사용할 수 없게 되거나 쿼럼을 충족할 수 없는 경우(예: 일종의 네트워크 분할 또는 노드 오류) 어떻게 됩니까? 이 경우 Patroni 클러스터는 읽기 전용 모드로 전환됩니다. Patroni 클러스터는 클러스터의 상태와 수행할 작업을 결정할 수 없습니다. DCS에 접속할 수 없고 거기에 새 클러스터 상태를 저장할 수 없으므로 전체 클러스터가 읽기 전용으로 전환됩니다. 그리고 운영자의 수동 개입 또는 DCS가 복구될 때까지 기다립니다.

대략적으로 말하면, DCS는 우리에게 기지만큼이나 중요한 서비스가 되는 것일까요?

예 예. 많은 현대 기업에서 서비스 검색은 인프라의 필수적인 부분입니다. 인프라에 데이터베이스가 있기도 전에 이미 구현되고 있습니다. 상대적으로 인프라가 시작되고 DC에 배포되었으며 즉시 서비스 검색이 가능합니다. Consul이면 DNS를 구축할 수 있습니다. 이것이 Etcd인 경우 다른 모든 것이 배포될 Kubernetes 클러스터의 일부가 있을 수 있습니다. Service Discovery는 이미 최신 인프라의 필수적인 부분인 것 같습니다. 그리고 그들은 데이터베이스보다 훨씬 일찍 그것에 대해 생각합니다.

감사합니다!

출처 : habr.com