두 데이터 센터를 이용한 Mongodb 아키텍처 및 페일 오버

Question

대부분의 mongodb 노드가 기본 데이터 센터에있는 mongo 복제본을 완벽하게 장애 조치하는 방법이 있는지 알아 내려고합니다. 현재의 한계는 2 데이터 센터이고 세 번째 데이터 센터는 문제가되지 않습니다. 내가 가진 문제는 데이터 센터 1이 다운되면 데이터 센터 2의 보조 노드가 수동 개입없이 기본 서버로 승격되지 않는다는 것입니다.

데이터 센터 (1) (주) : 몽고 노드 (주) 몽고 노드 (중재자)

데이터 센터 2 (보조) : 몽고 노드 (차)는

나는 MongoDB를 검토 한 dc1이 손실되면 dc2 primary에서 mongodb 인스턴스를 작성하기 위해 수동 개입이 필요합니다.

제 질문은 데이터 센터 1을 잃어 버리고 수동 개입/재구성없이 쓰기가 가능한 데이터 센터 2 인계 기능을 사용할 수있는 아키텍처 또는 구성이 있는지 여부입니다. 3 데이터 센터 아키텍처 경로를 사용하지 않아도 가능합니다. 각 사이트에서 두 개의 3 멤버 복제 세트를 동기화하고 연결 응용 프로그램의 네트워크 수준에서 장애 조치를 잠재적으로 수행 할 수 있습니까?

감사합니다.

Answer 1

나에게 가장 쉬운 해결책은 데이터 센터 2 개를 사용하는 경우 1 차에서 실패 만 처리하는 것입니다. 좋은 소식은 노예가 죽었다는 것입니다 - 당신은 기다릴 필요가 있습니다.

주에 대한 액세스가 실패하면 슬레이브를 기본으로 강제 전환하는 콜백 절차가 필요합니다. 이 스위치는 쿼리를 버퍼링하고 스위치에서 콜백을 대기하는 게이트웨이를 만드는 데 더 많은 시간을 소비하지 않으면 응용 프로그램에서 작동 중지 시간을 유발합니다. 그렇게하면 시간 제한을 늘리면 속도가 느려집니다.

Primary가 다시 라이브로 연결되면 다시 연결해야합니다 (슬레이브 노드가 안정적이지 않기 때문에). 다시 가동 중지 시간이 발생합니다. Primary (데이터 센터 2)가 살아 있는지 확인하고 if 그것은 트리거 이벤트이며 콜백으로 진행합니다.

슬레이브를 기본으로 강제 적용하기위한 수동 개입은 스크립트에 래핑 될 수 있습니다.

나에게 가장 좋은 해결책은 중재자가 머무를 제 3의 데이터 센터로가는 것입니다. 이를 건너 뛰고 애플리케이션 로직을 배치하려는 노력은 가치가 없습니다. Mongo의 자동 페일 오버는 매우 잘 작동하며 신뢰할 수 있습니다. 애플리케이션 로직을 사용하여 데이터 센터 2 개를 구현하면 많은 문제가 발생할 수 있습니다 ... 나는 오히려 권장 사항을 따르기 마련입니다.

Answer 2

처음에는 두 노드로 자동 장애 조치를 수행 할 수 없습니다. 둘째, 돈은 "제 3의"데이터 센터라고 생각할 때 실질적인 문제가 아닙니다. 왜 또는 어떻게 그렇게 물을 수 있습니까? 아시다시피 중재자가 필요합니다. 중재자는 실제로 자원을 필요로하지 않습니다. 어떤 작은 리눅스 기계도 잘 할 것입니다. 소형 VPS 기계는 그만큼 비용이 들지 않습니다. Here you can find machine 1 x 2.40 GHz, 512 MB, 20 GB은 월간 1,24 유로입니다. From here you get beefier machine with 1.99€/month.

실제로 두 곳 모두 "작은"기계로 상당히 큰 몽고를 돌릴 수 있습니다.