소개

얼마 전 저는 장애 조치 클러스터를 개발하는 임무를 맡았습니다. PostgreSQL, 한 도시 내에서 광섬유로 연결된 여러 데이터 센터에서 운영되며, 하나의 데이터 센터의 장애(예: 정전)를 견딜 수 있습니다. 내결함성을 담당하는 소프트웨어로 선택했습니다. 맥박 조정 장치이는 장애 조치 클러스터 생성을 위한 RedHat의 공식 솔루션이기 때문입니다. RedHat이 이를 지원하고 이 솔루션이 범용(모듈식)이기 때문에 좋습니다. 이를 통해 표준 모듈을 사용하거나 특정 요구에 맞게 생성하여 PostgreSQL뿐만 아니라 다른 서비스의 내결함성을 보장할 수 있습니다.

이 결정은 합리적인 질문을 제기했습니다. 장애 조치 클러스터는 얼마나 내결함성이 있습니까? 이를 조사하기 위해 클러스터 노드의 다양한 장애를 시뮬레이션하고, 서비스가 복원되기를 기다리고, 장애가 발생한 노드를 복구하고, 루프에서 테스트를 계속하는 테스트 벤치를 개발했습니다. 이 프로젝트는 원래 hapgsql이라고 불렸는데, 시간이 지나면서 모음이 하나만 있는 이름이 지루해졌습니다. 따라서 나는 내결함성 데이터베이스(및 이를 가리키는 유동 IP)를 호출하기 시작했습니다. 크로 간 (모든 중요한 기관이 복제되는 컴퓨터 게임의 캐릭터), 노드, 클러스터 및 프로젝트 자체는 투찬카 (크로건이 사는 행성)

이제 경영진이 허용했습니다. MIT 라이센스에 따라 오픈 소스 커뮤니티에 프로젝트를 공개합니다.. README는 곧 영어로 번역될 예정이며(주요 소비자는 Pacemaker 및 PostgreSQL 개발자가 될 것으로 예상되므로) README의 옛 러시아어 버전(일부)을 이 기사의 형식으로 제시하기로 결정했습니다.

클러스터는 가상 머신에 배포됩니다. 버추얼. 총 12개의 가상 머신(총 36GiB)이 배포되어 4개의 내결함성 클러스터(다양한 옵션)를 형성합니다. 처음 두 클러스터는 서로 다른 데이터 센터에 위치한 두 개의 PostgreSQL 서버와 공통 서버로 구성됩니다. 목격자 c 쿼럼 장치 (세 번째 데이터 센터의 저렴한 가상 머신에서 호스팅), 불확실성을 해결합니다. 50 % / 50 %, 정당 중 하나에 투표합니다. XNUMX개 데이터 센터의 세 번째 클러스터: 마스터 XNUMX개, 슬레이브 XNUMX개, 쿼럼 장치. 네 번째 클러스터는 데이터 센터당 XNUMX개씩 총 XNUMX개의 PostgreSQL 서버로 구성됩니다. 하나는 마스터이고 나머지는 복제본이며 목격자 c 쿼럼 장치. 네 번째는 두 대의 서버 또는 한 개의 데이터 센터의 장애를 견딜 수 있습니다. 필요한 경우 이 솔루션을 더 많은 수의 복제본으로 확장할 수 있습니다.

정확한 시간 서비스 ntpd 또한 내결함성을 위해 재구성되었지만 메서드 자체를 사용합니다. ntpd (고아 모드). 공유서버 목격자 중앙 NTP 서버 역할을 하며 시간을 모든 클러스터에 분배하여 모든 서버를 서로 동기화합니다. 만약에 목격자 장애가 발생하거나 격리되면 클러스터 서버 중 하나(클러스터 내)가 시간을 분배하기 시작합니다. 보조 캐싱 HTTP 프록시 또한 목격자, 도움을 받아 다른 가상 머신이 Yum 저장소에 액세스할 수 있습니다. 실제로 정확한 시간, 프록시 등의 서비스는 전용 서버에서 호스팅될 가능성이 높지만, 부스에서는 호스팅됩니다. 목격자 단지 가상 머신 수와 공간을 절약하기 위해서입니다.

버전

v0. VirtualBox 7에서 CentOS 11 및 PostgreSQL 6.1과 함께 작동합니다.

클러스터 구조

모든 클러스터는 여러 데이터 센터에 위치하도록 설계되어 하나의 평면 네트워크로 결합되며 단일 데이터 센터의 장애 또는 네트워크 격리를 견뎌야 합니다. 그렇기 때문에 불가능한 에 대한 보호를 위해 사용 분할 뇌 표준 심장박동기 기술이라고 불리는 스토니스 (머리에 있는 다른 노드를 쏴라) 또는 펜싱. 본질: 클러스터의 노드가 일부 노드에 문제가 있다고 의심하기 시작하거나 응답하지 않거나 잘못 작동하는 경우 IPMI 또는 UPS 제어 카드와 같은 "외부" 장치를 통해 강제로 해당 노드를 끕니다. . 그러나 이는 단일 오류가 발생하더라도 IPMI 또는 UPS 서버가 계속 작동하는 경우에만 작동합니다. 여기에서는 전체 데이터 센터에 장애가 발생하는 경우(예: 정전) 훨씬 더 심각한 장애로부터 보호할 계획입니다. 그리고 그러한 거절로 인해 모든 것이 돌로 만든-장치(IPMI, UPS 등)도 작동하지 않습니다.

대신, 이 시스템은 정족수라는 개념을 기반으로 합니다. 모든 노드에는 음성이 있으며, 전체 노드의 절반 이상을 볼 수 있는 노드만이 작동할 수 있습니다. 이 "반 + 1"의 양을 호출합니다. 정족수. 쿼럼에 도달하지 못한 경우 노드는 네트워크 격리 상태에 있다고 결정하고 해당 리소스를 꺼야 합니다. 이게 바로 그거야 분할 브레인 보호. 이 동작을 담당하는 소프트웨어가 작동하지 않으면 예를 들어 IPMI 기반 감시 장치가 작동해야 합니다.

노드 수가 짝수인 경우(두 데이터 센터의 클러스터) 소위 불확실성이 발생할 수 있습니다. 50 % / 50 % (XNUMX대 XNUMX) 네트워크 격리로 인해 클러스터가 정확히 절반으로 분할되는 경우. 따라서 짝수 개의 노드에 대해 다음을 추가합니다. 쿼럼 장치 세 번째 데이터 센터의 가장 저렴한 가상 머신에서 실행할 수 있는 까다롭지 않은 데몬입니다. 그는 자신이 본 세그먼트 중 하나에 투표하여 50%/50% 불확실성을 해결합니다. 쿼럼 장치가 실행될 서버의 이름을 지정했습니다. 목격자 (repmgr의 용어가 마음에 들었습니다.)

예를 들어, 결함이 있는 서버에서 정상 서버로 또는 시스템 관리자의 명령에 따라 리소스를 한 곳에서 다른 곳으로 이동할 수 있습니다. 클라이언트가 필요한 리소스가 어디에 있는지(어디에 연결해야 하는지) 알 수 있도록 유동 IP (부동 IP). 이는 Pacemaker가 노드 주위를 이동할 수 있는 IP입니다(모든 것이 플랫 네트워크에 있음). 각각은 리소스(서비스)를 상징하며 이 서비스(이 경우 데이터베이스)에 액세스하기 위해 연결해야 하는 위치에 위치합니다.

Tuchanka1(압축 회로)

구조

우리는 로드가 적은 소규모 데이터베이스가 많기 때문에 읽기 전용 트랜잭션을 위해 상시 대기 모드에서 전용 슬레이브 서버를 유지하는 것이 수익성이 없다는 것이 아이디어였습니다(이러한 리소스 낭비가 필요하지 않음).

각 데이터 센터에는 하나의 서버가 있습니다. 각 서버에는 두 개의 PostgreSQL 인스턴스가 있습니다(PostgreSQL 용어로는 클러스터라고 부르지만 혼동을 피하기 위해 다른 데이터베이스와 유사하게 인스턴스라고 부르며 Pacemaker 클러스터 클러스터만 호출하겠습니다). 하나의 인스턴스는 마스터 모드에서 작동하며 해당 인스턴스만 서비스를 제공합니다(유동 IP만 해당 인스턴스로 연결됨). 두 번째 인스턴스는 두 번째 데이터 센터의 슬레이브로 작동하며 마스터에 장애가 발생한 경우에만 서비스를 제공합니다. 대부분의 경우 인스턴스 두 개 중 하나(마스터)만이 서비스를 제공(요청 수행)하므로 모든 서버 리소스는 마스터에 최적화되어 있지만(메모리는 shared_buffers 캐시 등에 할당됨) 두 번째 인스턴스는 또한 데이터 센터 중 하나에 장애가 발생할 경우를 대비해 충분한 리소스를 보유하고 있습니다(파일 시스템 캐시를 통한 차선책 운영에도 불구하고). 슬레이브는 클러스터가 정상적으로 작동하는 동안 서비스를 제공하지 않으므로(읽기 전용 요청을 수행하지 않음) 동일한 시스템의 마스터와 리소스 전쟁이 발생하지 않습니다.

두 노드의 경우 내결함성은 비동기 복제에서만 가능합니다. 동기 복제를 사용하면 슬레이브에 오류가 발생하면 마스터가 중지되기 때문입니다.

목격하지 못함

목격하지 못함(쿼럼 장치) 나는 Tuchanka1 클러스터에 대해서만 고려할 것이며 다른 모든 클러스터와 동일한 이야기가 될 것입니다. 감시가 실패하면 클러스터 구조에는 아무 것도 변경되지 않으며 모든 것이 이전과 동일한 방식으로 계속 작동합니다. 그러나 쿼럼은 2개 중 3개가 되므로 이후에 발생하는 모든 오류는 클러스터에 치명적입니다. 여전히 긴급하게 수정해야 할 것입니다.

투찬카1 거절

Tuchanka1의 데이터 센터 중 하나에 오류가 발생했습니다. 이 경우 목격자 두 번째 데이터 센터의 두 번째 노드에 투표합니다. 그곳에서 이전 슬레이브가 마스터로 바뀌고 결과적으로 두 마스터가 모두 동일한 서버에서 작업하고 두 부동 IP가 모두 이를 가리킵니다.

투찬카2(클래식)

구조

두 노드의 고전적인 구성. 마스터는 하나에서 작업하고 슬레이브는 두 번째에서 작업합니다. 둘 다 요청을 실행할 수 있으므로(슬레이브는 읽기 전용) 둘 다 부동 IP로 지정됩니다. krogan2는 마스터이고 krogan2s1은 슬레이브입니다. 마스터와 슬레이브 모두 내결함성을 갖습니다.

노드가 XNUMX개인 경우 비동기 복제에서만 내결함성이 가능합니다. 동기 복제에서는 슬레이브에 장애가 발생하면 마스터가 중지되기 때문입니다.

투찬카2 거절

데이터 센터 중 하나에 장애가 발생하는 경우 목격자 두 번째에 투표하세요. 작동하는 유일한 데이터 센터에서는 마스터가 생성되고 두 부동 IP 모두 마스터와 슬레이브를 가리킵니다. 물론 인스턴스는 마스터 및 슬레이브 부동 IP의 모든 연결과 요청을 동시에 수락할 수 있는 충분한 리소스(연결 제한 등)를 갖도록 구성되어야 합니다. 즉, 정상 작동 중에는 충분한 한도 공급이 있어야 합니다.

Tuchanka4 (많은 노예)

구조

이미 또 다른 극단입니다. 읽기 전용 요청을 많이 받는 데이터베이스가 있습니다(고부하 사이트의 일반적인 경우). Tuchanka4는 이러한 요청을 처리하기 위해 XNUMX명 이상의 슬레이브가 있을 수 있지만 여전히 너무 많지는 않은 상황입니다. 슬레이브 수가 매우 많으면 계층적 복제 시스템을 개발해야 합니다. 최소한의 경우(그림 참조) 두 데이터 센터에는 각각 PostgreSQL 인스턴스가 있는 두 개의 서버가 있습니다.

이 체계의 또 다른 특징은 하나의 동기 복제를 구성하는 것이 이미 가능하다는 것입니다. 마스터와 동일한 데이터 센터의 복제본이 아닌 가능하면 다른 데이터 센터로 복제하도록 구성됩니다. 마스터와 각 슬레이브는 부동 IP로 지정됩니다. 다행스럽게도 슬레이브 간에 요청의 균형을 어떻게든 유지해야 합니다. SQL 프록시, 예를 들어 클라이언트 측에서. 다양한 유형의 클라이언트에는 다양한 유형이 필요할 수 있습니다. SQL 프록시, 클라이언트 개발자만이 누가 무엇이 필요한지 알고 있습니다. 이 기능은 외부 데몬이나 클라이언트 라이브러리(연결 풀) 등을 통해 구현될 수 있습니다. 이 모든 것은 장애 조치 데이터베이스 클러스터(failover SQL 프록시 클라이언트 내결함성과 함께 독립적으로 구현될 수 있습니다.

투찬카4 거절

하나의 데이터 센터(즉, 두 개의 서버)가 실패하면 두 번째 데이터 센터에 대한 증인 투표가 이루어집니다. 결과적으로 두 번째 데이터 센터에서는 두 개의 서버가 실행되고 있습니다. 하나는 마스터를 실행하고 마스터 부동 IP는 이를 가리킵니다(읽기-쓰기 요청 수신용). 두 번째 서버에는 동기식 복제를 실행하는 슬레이브가 있고 슬레이브 부동 IP 중 하나가 이를 가리킵니다(읽기 전용 요청의 경우).

가장 먼저 주목해야 할 점은 모든 슬레이브 플로트 IP가 작업자가 되는 것은 아니고 하나만 작업자가 된다는 것입니다. 그리고 그것을 올바르게 사용하려면 다음이 필요합니다. SQL 프록시 모든 요청을 남은 유일한 부동 IP로 리디렉션했습니다. 그리고 만약에 SQL 프록시 아니요, 연결 URL에서 쉼표로 구분된 모든 유동 IP 슬레이브를 나열할 수 있습니다. 이 경우에는 라이브러리 연결은 첫 번째 작동 IP에 이루어지며 이는 자동 테스트 시스템에서 수행됩니다. 아마도 JDBC와 같은 다른 라이브러리에서는 이것이 작동하지 않으며 필요할 수도 있습니다. SQL 프록시. 이는 슬레이브에 대한 부동 IP가 한 서버에서 동시에 발생하는 것을 금지하여 여러 대가 실행 중인 경우 슬레이브 서버 간에 고르게 분산되기 때문입니다.

둘째: 데이터 센터에 장애가 발생하더라도 동기식 복제가 유지됩니다. 그리고 XNUMX차 오류가 발생하더라도, 즉 나머지 데이터 센터의 두 서버 중 하나에 오류가 발생하더라도 클러스터는 서비스 제공을 중단하더라도 커밋 확인을 제공한 모든 커밋된 트랜잭션에 대한 정보를 계속 유지합니다. (XNUMX차 고장시 손실정보는 없습니다.)

Tuchanka3(데이터 센터 3개)

구조

이는 완벽하게 작동하는 세 개의 데이터 센터가 있고 각 데이터 센터에는 완벽하게 작동하는 데이터베이스 서버가 있는 상황을 위한 클러스터입니다. 이 경우 쿼럼 장치 필요하지 않습니다. 한 데이터 센터에는 마스터가 배치되고, 나머지 두 데이터 센터에는 슬레이브가 배치됩니다. 복제는 동기식이며 ANY(slave1,slave2)를 입력합니다. 즉, 클라이언트는 슬레이브 중 하나가 커밋을 수락했다고 처음으로 응답할 때 커밋 확인을 받습니다. 리소스는 마스터용 부동 IP 4개, 슬레이브용 부동 IP XNUMX개로 표시됩니다. TuchankaXNUMX와 달리 세 개의 부동 IP는 모두 내결함성이 있습니다. 읽기 전용 SQL 쿼리의 균형을 맞추려면 다음을 사용할 수 있습니다. SQL 프록시 (별도의 내결함성 포함) 또는 하나의 슬레이브 부동 IP를 클라이언트의 절반에 할당하고 나머지 절반을 두 번째에 할당합니다.

투찬카3 거절

데이터 센터 중 하나에 장애가 발생하면 두 개가 남습니다. 하나는 마스터의 마스터 및 부동 IP가 발생하고, 두 번째는 슬레이브 및 두 슬레이브 부동 IP가 발생합니다(인스턴스는 두 슬레이브 부동 IP의 모든 연결을 수락하려면 이중 리소스 예약이 있어야 합니다). 마스터와 슬레이브 간의 동기식 복제. 또한 클러스터는 두 개의 데이터 센터가 파괴되는 경우(동시에 파괴되지 않는 경우) 커밋되고 확인된 트랜잭션에 대한 정보를 저장합니다(정보 손실 없음).

파일 구조와 배포에 대한 자세한 설명은 포함하지 않기로 결정했습니다. 놀고 싶은 사람은 누구나 README에서 모든 내용을 읽을 수 있습니다. 나는 단지 자동화된 테스트에 대한 설명을 제공할 뿐입니다.

자동 테스트 시스템

다양한 결함을 시뮬레이션하여 클러스터의 내결함성을 테스트하기 위해 자동 테스트 시스템이 생성되었습니다. 스크립트에 의해 실행됨 test/failure. 스크립트는 테스트하려는 클러스터 수를 매개변수로 사용할 수 있습니다. 예를 들어 다음 명령은 다음과 같습니다.

test/failure 2 3

두 번째와 세 번째 클러스터만 테스트합니다. 매개변수를 지정하지 않으면 모든 클러스터가 테스트됩니다. 모든 클러스터는 병렬로 테스트되며 결과는 tmux 패널에 표시됩니다. Tmux는 전용 tmux 서버를 사용하므로 기본 tmux에서 스크립트를 실행하여 중첩된 tmux를 생성할 수 있습니다. 큰 창과 작은 글꼴로 터미널을 사용하는 것이 좋습니다. 테스트가 시작되기 전에 스크립트가 완료되면 모든 가상 머신이 스냅샷으로 롤백됩니다. setup.

터미널은 테스트 중인 클러스터 수에 따라 열로 나누어지며, 기본적으로(스크린샷에서는) 2개가 있습니다. 투찬카XNUMX를 예시로 칼럼의 내용을 설명하겠습니다. 스크린샷의 패널에는 번호가 매겨져 있습니다.

1. 테스트 통계가 여기에 표시됩니다. 열:
   • 실패 — 결함을 에뮬레이트하는 테스트(스크립트의 함수) 이름입니다.
   • 반응 — 클러스터가 기능을 복구하는 동안의 산술 평균 시간(초)입니다. 오류를 에뮬레이션하는 스크립트 시작부터 클러스터가 기능을 복원하고 서비스를 계속 제공할 수 있는 순간까지 측정됩니다. 시간이 매우 짧은 경우(예: 3초(여러 슬레이브(Tuchanka4 및 TuchankaXNUMX)가 있는 클러스터에서 발생)) 이는 결함이 비동기 슬레이브에 있었고 어떤 식으로든 성능에 영향을 미치지 않았음을 의미합니다. 클러스터 상태 스위치.
   • 일탈 — 값의 확산(정확도)을 표시합니다. 반응 표준편차법을 사용한다.
   • 계산 — 이 테스트가 수행된 횟수입니다.
2. 짧은 로그를 통해 클러스터가 현재 수행 중인 작업을 평가할 수 있습니다. 반복(테스트) 번호, 타임스탬프 및 작업 이름이 표시됩니다. 너무 오래 실행(> 5분)하면 문제가 있음을 나타냅니다.
3. 심장 (하트) - 현재 시간. 성능을 시각적으로 평가하는 경우 주인 현재 시간은 float IP 마스터를 사용하여 테이블에 지속적으로 기록됩니다. 성공하면 결과가 이 패널에 표시됩니다.
4. 비트 (펄스) - 이전에 스크립트에 의해 기록된 "현재 시간" 심장 마스터하려면 지금부터 읽어보세요 노예 부동 IP를 통해. 슬레이브 및 복제 성능을 시각적으로 평가할 수 있습니다. Tuchanka1에는 부동 IP를 사용하는 슬레이브가 없지만(서비스를 제공하는 슬레이브 없음) 인스턴스(DB)가 두 개이므로 여기에 표시되지 않습니다. 비트과 심장 두 번째 사례.
5. 유틸리티를 사용하여 클러스터 상태 모니터링 pcs mon. 구조, 노드 간 리소스 분포 및 기타 유용한 정보를 표시합니다.
6. 클러스터에 있는 각 가상 머신의 시스템 모니터링이 여기에 표시됩니다. 클러스터에 있는 가상 머신 수에 따라 이러한 패널이 더 많이 있을 수 있습니다. 두 개의 그래프 CPU로드 (가상 머신에는 XNUMX개의 프로세서가 있음), 가상 머신 이름, 시스템로드 (5분, 10분, 15분에 걸쳐 평균이 계산되므로 로드 평균이라고 함), 데이터 및 메모리 할당을 처리합니다.
7. 테스트를 수행하는 스크립트의 추적입니다. 오작동이 발생하는 경우(갑자기 작동이 중단되거나 끝없는 대기 주기가 발생하는 경우) 여기에서 이러한 동작의 이유를 확인할 수 있습니다.

테스트는 두 단계로 수행됩니다. 먼저 스크립트는 모든 유형의 테스트를 거치며 이 테스트를 적용할 가상 머신을 무작위로 선택합니다. 그런 다음 끝없는 테스트 주기가 수행되고 매번 가상 머신과 오류가 무작위로 선택됩니다. 테스트 스크립트(하단 패널)가 갑자기 종료되거나 무언가를 기다리는 끝없는 루프(한 작업에 대한 실행 시간 > 5분, 이는 추적에서 볼 수 있음)는 이 클러스터의 일부 테스트가 실패했음을 나타냅니다.

각 테스트는 다음 작업으로 구성됩니다.

1. 오류를 에뮬레이트하는 기능을 시작합니다.
2. 준비가 되셨습니까? — 클러스터가 복원되기를 기다립니다(모든 서비스가 제공될 때).
3. 클러스터 복구 시간 초과를 표시합니다(반응).
4. 수정 — 클러스터가 "복구"되고 있습니다. 그 후에는 완전한 작동 상태로 돌아가서 다음 오작동에 대비해야 합니다.

다음은 수행하는 작업에 대한 설명이 포함된 테스트 목록입니다.

• 포크밤: 포크 폭탄을 사용하여 "메모리 부족"을 생성합니다.
• 공간외: 하드 드라이브가 가득 찼습니다. 그러나 테스트는 다소 상징적입니다. 테스트 중에 생성되는 로드가 미미하기 때문에 PostgreSQL은 일반적으로 하드 드라이브가 가득 차도 실패하지 않습니다.
• 포스트그레스-KILL: 다음 명령으로 PostgreSQL을 종료합니다. killall -KILL postgres.
• 포스트그레스-STOP: PostgreSQL 명령이 중단됩니다. killall -STOP postgres.
• 전원 끄기: 다음 명령을 사용하여 가상 머신의 전원을 "비활성화"합니다. VBoxManage controlvm "виртуалка" poweroff.
• 다시 쓰기: 다음 명령으로 가상 머신을 오버로드합니다. VBoxManage controlvm "виртуалка" reset.
• SBD-정지: 다음 명령을 사용하여 SBD 악마를 정지합니다. killall -STOP sbd.
• 일시 휴업: SSH를 통해 가상 머신에 명령을 보냅니다. systemctl poweroff, 시스템이 정상적으로 종료됩니다.
• 풀리다: 네트워크 격리, 명령 VBoxManage controlvm "виртуалка" setlinkstate1 off.

표준 tmux 명령 "kill-window"를 사용하여 테스트 완료 Ctrl-b &또는 "detach-client" 명령 Ctrl-b d: 이 시점에서 테스트가 종료되고 tmux가 닫히고 가상 머신이 꺼집니다.

테스트 중 확인된 문제

• 현재 감시견 악마 SBD 관찰된 데몬을 중지하는 데 작동하지만 동결하지는 않습니다. 그리고 결과적으로 동결로만 이어지는 결함 코로싱크 и 맥박 조정 장치, 하지만 매달리지는 않음 sbd. 확인용 코로싱크 이미있다 PR#83 (GitHub에서 sbd), 스레드에 승인됨 석사. 그들은 (PR#83에서) Pacemaker에도 비슷한 기능이 있을 것이라고 약속했습니다. 레드햇 xnumx 할 것입니다. 그러나 이러한 "오작동"은 추측에 불과하며 예를 들어 다음을 사용하여 쉽게 인위적으로 시뮬레이션할 수 있습니다. killall -STOP corosync, 하지만 실생활에서는 절대 만나지 마세요.

• У 맥박 조정 장치 버전에서는 7 CentOS에 잘못 설정됨 sync_timeout у 쿼럼 장치, 결과적으로 한 노드에 장애가 발생하면 두 번째 노드도 재부팅될 가능성이 높습니다., 마스터가 이동해야했던 곳입니다. 확대로 치료됨 sync_timeout у 쿼럼 장치 배포 중(스크립트에서 setup/setup1). 이 수정안은 개발자가 승인하지 않았습니다. 맥박 조정 장치대신 그들은 이 제한 시간이 자동으로 계산되는 방식으로(미래 불특정 시점) 인프라를 재설계하겠다고 약속했습니다.

• 데이터베이스 구성에서 다음을 지정하는 경우 LC_MESSAGES (문자 메시지) 유니코드를 사용할 수 있습니다. ru_RU.UTF-8, 그런 다음 시작 시 포스트 그레스 로케일이 UTF-8이 아닌 환경, 예를 들어 빈 환경(여기서는 페이스 메이커+pgsqlms(paf) 실행 포스트 그레스), 저것 로그에는 UTF-8 문자 대신 물음표가 포함됩니다.. PostgreSQL 개발자들은 이 경우 어떻게 해야 할지에 대해 합의하지 않았습니다. 비용이 많이 들고 설치해야합니다 LC_MESSAGES=en_US.UTF-8 데이터베이스 인스턴스를 구성(생성)할 때.

• wal_receiver_timeout이 설정된 경우(기본적으로 60초) tuchanka3 및 tuchanka4 클러스터의 마스터에서 PostgreSQL-STOP 테스트 중에 복제가 새 마스터에 다시 연결되지 않습니다.. 복제는 동기식이므로 슬레이브뿐만 아니라 새 마스터도 중지됩니다. PostgreSQL을 구성할 때 wal_receiver_timeout=0을 설정하여 문제를 해결하세요.

• 가끔 ForkBomb 테스트에서 PostgreSQL의 복제가 중단되는 것을 관찰했습니다(메모리 오버플로). ForkBomb 이후 때때로 슬레이브가 새 마스터에 다시 연결되지 않을 수 있습니다.. 동기 복제로 인해 마스터가 정지된 tuchanka3 및 tuchanka4 클러스터에서만 이 문제가 발생했습니다. 문제는 오랜 시간(약 XNUMX시간) 후에 저절로 사라졌습니다. 이를 바로잡기 위해서는 더 많은 연구가 필요합니다. 증상은 이전 버그와 유사하며 다른 원인으로 인해 발생하지만 결과는 동일합니다.

크로건에서 찍은 사진 취향이 독특 예술 저자의 허락을 받아:

출처 : habr.com