복제본 세트 배포 아키텍처
이 페이지의 내용
복제본 세트의 아키텍처는 세트의 용량과 기능에 영향을 미칩니다. 이 문서에서는 복제본 세트 배포 전략과 일반적인 아키텍처에 대해 설명합니다.
프로덕션 시스템의 표준 복제본 세트 배포는 3명의 멤버로 구성된 복제본 세트입니다. 이러한 세트는 중복성 및 내결함성을 제공합니다. 가능하면 복잡성을 피하되 애플리케이션 요구 사항에 따라 아키텍처가 결정되도록 합니다.
Strategies
노드(member) 수 결정
이러한 전략에 따라 복제본 세트에 멤버를 추가합니다.
최대 투표 노드 수
복제본 세트에는 최대 50개의 멤버가 있을 수 있지만 투표권이 있는 멤버는 7개뿐 입니다. 복제본 세트에 투표권을 가진 멤버가 7개 있는 경우 추가 멤버는 투표권이 없는 멤버여야합니다.
홀수 멤버 배포
복제본 세트에는 투표 노드가 홀수가 되도록 설정하는 것이 좋습니다. 복제본 세트는 최대 7개의 투표 노드를 가질 수 있습니다. 투표 노드가 짝수인 경우 다른 데이터를 보유하는 투표 노드를 추가하거나, 제약 사항으로 인해 불가능한 경우 중재자를 배치합니다.
중재자는 데이터의 사본을 저장하지 않으므로 더 적은 리소스를 필요로 합니다. 결과적으로 애플리케이션 서버나 기타 공유 리소스에서 중재자를 실행할 수 있습니다. 데이터 복제본이 없으면 복제본 세트의 다른 멤버를 배치하지 않는 환경에 중재자를 배치할 수 있습니다. 보안 정책을 참조하세요.
경고
복제본 세트에 두 개 이상의 중재자를 배치하지 마세요. 복수 중재자 관련 우려 사항을 참조하세요.
기존 레플리카 세트에 중재자를 추가하려면 다음과 같이 하세요:
일반적으로 복제본 세트에 데이터를 보유하는 멤버가 두 개 이하인 경우 먼저 복제본 세트에 대한 클러스터 전체 쓰기 우려를 설정해야 할 수 있습니다.
클러스터 전체 쓰기 우려를 설정해야 하는 이유에 대한 자세한 내용은 클러스터 전체 쓰기 우려를 참조하세요.
중재자로 새로운 복제 세트를 시작하기 전에 클러스터 전체의 쓰기 고려 설정을 변경할 필요는 없습니다.
내결함성 고려
복제본 세트의 내결함성은 사용 불가능해진 노드 수에도 불구하고 여전히 프라이머리를 선출할 수 있는 노드 수를 의미합니다. 다시 말해, 세트의 노드 수와 프라이머리 선출을 위해 필요한 투표 노드 수 majority 의 차이입니다. 프라이머리가 없으면 복제본 세트는 쓰기 작업을 허용할 수 없습니다. 내결함성은 복제본 세트 크기에 영향을 받지만 관계는 직접적이지 않습니다. 다음 표를 참조하세요:
멤버 수 | 새로운 프라이머리 선출에 필요한 과반수 | 내결함성 |
|---|---|---|
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
복제본 집합에 멤버를 추가한다고 해서 내결함성이 항상 증가하는 것은 아닙니다. 그러나 이러한 경우 추가 멤버가 백업이나 보고와 같은 전용 기능을 지원할 수 있습니다.
rs.status()는 복제본 세트에 대해 majorityVoteCount를 반환합니다.
전용 기능에 숨겨진 노드 및 지연된 노드 사용
읽기가 많은 애플리케이션
복제본 세트는 고가용성 및 이중화를 위해 설계되었습니다. 대부분의 경우 세컨더리 멤버는 프라이머리 멤버와 비슷한 부하에서 작동합니다. 세컨더리에게 읽기를 지시해서는 안 됩니다.
읽기가 많은 애플리케이션의 경우 Cluster-to-Cluster Sync를 사용하여 데이터를 다른 클러스터로 복제하여 읽는 것이 좋습니다.
세컨더리 읽기 모드에 대한 자세한 내용은 secondary 및 secondaryPreferred를 참조하세요.
수요에 앞서 용량 추가
복제본 세트의 기존 멤버에는 새 멤버 추가를 지원할 수 있는 여유 용량이 있어야 합니다. 현재 수요로 인해 세트의 용량이 포화 상태가 되기 전에 항상 새 멤버를 추가하세요.
지리적으로 멤버 배포
데이터 센터 장애 발생 시 데이터를 보호하려면 대체 데이터 센터에 최소한 한 명의 멤버를 유지합니다. 가능하면 홀수 개의 데이터 센터를 사용하고, 데이터 센터가 손실되더라도 나머지 복제본 세트 멤버가 과반수를 구성하거나 최소한 데이터 사본을 제공할 수 있는 가능성을 극대화하는 멤버 분포를 선택합니다.
참고
두 개의 데이터 센터에 복제본 세트 구성원을 분산하면 단일 데이터 센터에 비해 이점이 있습니다. 두 개의 데이터 센터로 분산된 경우,
데이터 센터 중 하나가 다운되더라도 단일 데이터 센터 배포판과 달리 데이터를 읽을 수 있습니다.
소수의 구성원이 있는 데이터 센터가 다운되더라도 복제본 세트는 읽기 작업뿐만 아니라 쓰기 작업도 계속 수행할 수 있습니다.
그러나 대다수의 구성원이 있는 데이터 센터가 다운되면 복제본 세트는 읽기 전용이 됩니다.
가능하다면 최소 3개 이상의 데이터 센터에 구성원을 배포하세요. 구성 서버 복제본 세트(CSRS)의 경우 가장 좋은 방법은 3개(또는 구성원 수에 따라 그 이상) 센터에 배포하는 것입니다. 세 번째 데이터 센터의 비용이 부담스러운 경우, 회사 정책이 허용하는 경우 데이터 보유 멤버를 두 데이터 센터에 균등하게 분산하고 나머지 멤버는 클라우드에 저장하는 것도 한 가지 방법입니다.
기본 데이터 센터의 멤버가 대체 데이터 센터의 멤버보다 먼저 프라이머리로 선출되도록 하려면 대체 데이터 센터 멤버의 members[n].priority를 프라이머리 데이터 센터의 멤버보다 낮게 설정합니다.
자세한 내용은 둘 이상의 데이터 센터에 분산된 복제본 세트를 참조하세요.
태그 세트를 사용한 대상 작업
복제본 세트 태그 세트를 사용하여 특정 노드로 읽기 작업을 지정하거나 특정 노드로부터 승인을 요청하는 쓰기 고려를 사용자 지정할 수 있습니다.
저널링을 사용하여 정전으로부터 보호
MongoDB는 기본적으로 저널링을 활성화합니다. 저널링은 전력 실패나 예상치 못한 재부팅과 같은 서비스 중단 시 데이터 손실을 방지합니다.
호스트 이름
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
복제본 세트 이름 지정
애플리케이션이 2개 이상의 복제본 세트에 연결된 경우 각 세트의 이름이 달라야 합니다. 일부 드라이버는 복제본 세트 이름으로 복제본 세트 연결을 그룹화합니다.
배포 패턴
다음 문서에서는 일반적인 복제본 세트 배포 패턴을 설명합니다. 애플리케이션 요구 사항에 따라 다른 패턴도 가능하며 효과적일 수 있습니다. 필요한 경우 자체 배포에서 각 아키텍처의 기능을 결합합니다.
- 3개의 노드로 구성된 복제본 세트
- 세 멤버로 구성된 복제본 세트는 복제본 세트에 대한 최소 권장 아키텍처를 제공합니다.
- 둘 이상의 데이터 센터에 분산된 복제본 세트
- 지리적으로 분산된 세트는 정전과 같은 시설별 장애로부터 보호하기 위해 다양한 위치의 노드를 포함합니다.