MongoDB 복제 세트 멤버
MongoDB 복제 세트 멤버 (Replica Set Members)
MongoDB의 복제 세트(replica set)는 여러 mongod 프로세스가 한 팀을 이뤄 데이터 중복성과 고가용성을 제공하는 구조예요. 이 팀을 이루는 멤버는 프라이머리(primary)와 세컨더리(secondary), 그리고 상황에 따라 아비터(arbiter)가 있어요. 각 멤버가 정확히 어떤 역할을 맡는지 이해하면 복제 세트를 설계하고 운영할 때 헷갈리지 않을 수 있어요.
멤버 구성 개요
복제 세트의 멤버는 다음과 같이 나뉘어요.
- 프라이머리(Primary): 모든 쓰기 연산을 받는 유일한 멤버예요.
- 세컨더리(Secondary): 프라이머리로부터 연산을 복제해 동일한 데이터셋을 유지해요. 세컨더리에는 특별한 용도에 맞춘 추가 설정을 할 수도 있어요. 예를 들어 투표에 참여하지 않는(non-voting) 세컨더리나 우선순위가 0인(priority 0) 세컨더리로 구성할 수 있죠.
- 아비터(Arbiter): 선거(election)에는 참여하지만 데이터를 보관하지 않는 멤버예요. 즉 데이터 중복성을 제공하지 않아요.
권장되는 최소 구성은 데이터를 담는 세 멤버로 이루어진 복제 세트예요. 프라이머리 하나와 세컨더리 두 개입니다. 프라이머리와 세컨더리는 있는데 비용 때문에 세컨더리를 하나 더 두기 어려운 상황이라면, 아비터를 추가하는 선택을 할 수 있어요.
복제 세트는 최대 50개 멤버까지 가질 수 있지만, 투표권을 가진 멤버는 7개로 제한돼요.
프라이머리 (Primary)
프라이머리는 복제 세트에서 쓰기 연산을 받는 유일한 멤버예요. MongoDB는 프라이머리에서 쓰기 연산을 적용한 뒤 이를 프라이머리의 oplog에 기록해요. 세컨더리 멤버들은 이 oplog를 복제해 자신의 데이터셋에 연산을 적용하죠.
프라이머리는 3개 멤버 복제 세트에서는 모든 쓰기를 받고, 세컨더리가 oplog를 복제해 자신의 데이터셋에 적용하는 구조예요. 복제 세트의 모든 멤버는 읽기 연산을 받을 수 있지만, 기본적으로 애플리케이션의 읽기는 프라이머리로 향해요.
복제 세트에는 프라이머리가 최대 하나만 있을 수 있어요. 현재 프라이머리를 사용할 수 없게 되면 선거(election)가 치러져 새 프라이머리가 정해집니다.
세컨더리 (Secondary)
클라이언트는 세컨더리에 데이터를 쓸 수 없지만, 세컨더리에서 읽는 것은 가능해요. 읽기 요청을 복제 세트의 어느 멤버로 보낼지는 읽기 선호도(read preference)로 조절합니다.
세컨더리를 특별한 용도로 구성할 수도 있어요.
- 선거에서 프라이머리가 되지 못하게 하기: 이렇게 하면 세컨더리를 보조 데이터센터에 두거나 콜드 스탠바이(cold standby)로 쓸 수 있어요 (Priority 0 멤버).
- 애플리케이션의 읽기를 차단하기: 일반 트래픽과 분리해야 하는 애플리케이션을 실행할 수 있어요 (Hidden 멤버).
아비터 (Arbiter)
아비터는 프라이머리 선거에 참여하기는 하지만, 데이터셋의 복사본을 갖지 않고 프라이머리가 될 수도 없는 멤버예요. 아비터는 정확히 1개의 선거 투표권을 갖고, 기본적으로 우선순위(priority)가 0이에요.
아비터는 프라이머리나 세컨더리 멤버가 있는 시스템과 같은 시스템에서 실행하지 않는 것이 중요해요. 또 샤딩된 클러스터의 샤드에서 프라이머리-세컨더리-아비터(PSA) 구조를 쓰면, 데이터를 담는 세컨더리가 사용 불가능해졌을 때 가용성을 잃을 수 있으니 주의해야 해요. 샤드에서 w: majority 쓰기 관심사(write concern) 연산은 남은 멤버 중에 아비터가 있으면 완료되지 못할 수 있기 때문이죠.