두 서버 사이의 연결이 견고하고 (그리고 세 번째 컴퓨터가 없기 때문에) 스플릿 브레인에 대해 걱정하지 않습니다.
자동 장애 조치 기능을 갖춘 MariaDB 복제를 원하므로 데이터베이스 하나가 죽어도 계속 작동합니다. MaxScale을 본 적이 있지만 컴퓨터가 두 대뿐이므로 서버 중 하나와 동일한 컴퓨터에서 실행해야 하며 해당 서버가 종료되면 아무 것도 작동하지 않습니다. AFAIK, MariaDB Galera 클러스터는 두 개에서만 실행하고 자동 장애 조치를 수행하는 것을 거부합니다(쿼럼 필요). 그러나 다른 컴퓨터에서 중재자를 실행하거나 다른 컴퓨터에서 다른 데이터베이스를 실행할 수도 있지만 속도가 느립니다.
또한 백엔드는 PHP입니다. mysqli 설정 등을 변경할 의향이 있지만 거기에서 무엇을 변경해야 할지 모르겠습니다.
편집: 자동 장애 조치(failover)를 기꺼이 포기하고 싶지만 그때 원하는 동작은 다음과 같습니다.
서버 A에 연결하면 데이터베이스 A(마스터)에 연결되어 정상적으로 읽기/쓰기가 됩니다.
Serer B에 연결하면 데이터베이스 B(읽기 전용 슬레이브)에 연결되어 잘 읽힙니다. 써야 하는 경우에는 쓸 수 있지만 데이터베이스 A로 푸시됩니다.
두 서버 또는 이와 유사한 것에서 MaxScale을 사용하면 이것이 가능합니까?
답변1
두 개의 노드가 있습니다. 어떤 종류의 마스터-마스터도 사용하지 마십시오. 두 노드에서 브레인이 분할될 가능성이 매우 높습니다(결국 발생하는 것은 거의 보장됩니다).
이러한 종류의 상태 저장 애플리케이션은 자체적으로 2노드 클러스터 배포를 잘 처리할 것으로 기대할 수 없습니다. 오류가 발생할 경우 클러스터를 전혀 강력하게 만들기 위해 운영자 개입이나 CRM이 필요합니다. 우선적으로 모여있습니다.
2개의 노드 클러스터가 있습니다. 분할 브레인에 대해 반드시 걱정해야 합니다. 왜냐하면 해당 아키텍처는 분할 브레인 조건에 매우 취약하기 때문입니다. 오늘날 노드 간 네트워크 링크가 견고하다고 해서 항상 그럴 것이라는 의미는 아니며 이는 2노드 클러스터에서 가장 큰 위험 요소 중 하나입니다. 링크가 끊어지면 즉시 클러스터가 분할됩니다.펜싱또는정족수노드 사이에 설정됩니다. 이는 2노드 클러스터에서 가장 큰 고려 사항 중 하나입니다. 펜싱을 사용하면 분할 브레인 상태가 발생할 가능성이 높음에서 거의 0으로 줄어들기 때문입니다.
Pacemaker/Corosync를 사용하여 이 문제를 처리하는 것이 좋습니다. 복잡한 스택이지만 두 노드에서 프로덕션 등급 클러스터를 생성하는 데 필요한 메커니즘을 제공합니다. 또한 그러한 클러스터 관리자를 적용하는 경우에도 다중 마스터보다는 한 번에 단일 마스터 인스턴스만 사용하는 것이 좋습니다.
출발점이 될 수 있는 HA MariaDB에 대한 좋은 가이드가 있습니다. 펜싱 사용은 다루지 않습니다. 펜싱을 수행할 수 없는 경우 Corosync에는 투표 데몬을 실행하는 작은 중재자 노드를 사용하여 애플리케이션 오버헤드 비용 없이 전체 구현에 쿼럼을 제공할 수 있는 기능도 있습니다(Corosync qdevice에 대한 정보 참조).
구독 벽 뒤에 있지만활성-수동 MySQL 클러스터 구성, 한 번에 하나의 노드에서 실행 및 노드 간 블록 스토리지 복제에 대한 엔드투엔드 가이드
Pacemaker 고급 리소스 유형은 리소스를 선형 종속성 체인으로 그룹화하는 기능과 노드 전체에서 둘 이상의 애플리케이션 인스턴스를 실행하기 위한 다중 상태 리더 선택 의미 체계를 표현하는 기능을 통해 장애 조치를 적절하게 조정하는 방법에 관한 대부분의 질문을 다룹니다.여기에서 찾을 수 있습니다.
번들은 Docker 및 RKT와 같은 컨테이너 런타임을 통해 Pacemaker에서 애플리케이션 격리를 수행하는 방법입니다. 이러한 번들은 클러스터에 Pacemaker 노드 자체로 표시되므로 다른 애플리케이션과 독립적으로 클러스터에 의해 "펜싱"될 수 있으므로 펜싱의 또 다른 길이 열립니다.여기에서 찾을 수 있습니다.
답변2
"문제는 상관없어, 노드는 2개만 돌릴 수 있다"는 같은 철학으로 다양한 DB(Mongo, Elasticsearch, SQL Server 등)를 운영했습니다.
그것은 상처의 세계였습니다.
마스터-슬레이브를 실행한다면 괜찮습니다. 그러나 두통이 있을 것이다.
수년간 이 문제를 둘러싸고 춤을 추고 두 개의 노드만 고집함으로써 발생하는 다양한 데브옵스 문제를 처리한 후(우리 데이터베이스가 정말 크고 세 번째 노드의 비용이 상당했기 때문에 고집했습니다) 마침내 세 개의 노드를 실행하기 시작했습니다. 노드.
그리고 모든 것이 좋아졌습니다.
제가 수년간 춤을 추면서 얻은 교훈은 다음과 같습니다. 두 가지 옵션이 있습니다.
- 웜 스페어(예: 마스터-슬레이브)가 있는 단일 노드
- 노드 3개
내 경험에 따르면, 나는 두 개의 노드를 다시는 활성-활성으로 실행하지 않을 것입니다(내가 본 것처럼 분할 뇌를 완전히 방지하는 마법의 장치가 없는 한).
다양한 스택에서 여러 개의 0.5~1.5TB 데이터베이스를 5년 동안 실행한 결과입니다.
답변3
한 가지 옵션은 부동 IP를 장애 조치하기 위해 연결 유지를 통해 비동기 마스터-마스터 복제를 실행하는 것입니다. 훌륭하지는 않지만 완전한 서버 오류 시나리오를 다룰 것입니다.
ILO 또는 한 시스템의 전원을 강제로 다른 시스템의 전원을 끄는 다른 방법(STONITH)이 있습니까? 이는 부분적인 오류를 방지하는 데 실제로 필요합니다. 예를 들어 시스템이 충돌했지만 완전히는 아니어서 하트비트 패킷에 응답할 수 있을 만큼 여전히 살아있지만 그렇지 않으면 작동하지 않습니다. 이로 인해 장애 조치(failover)가 발생해야 할 때 발생하지 않을 수 있습니다.