복제

1. 레플리카 셋 아키텍처

데이터 가용성을 보장하기 위해 여러 서버에 데이터를 복제하는 방식입니다.

• Primary: 모든 쓰기 작업을 처리하고 Oplog(Operations Log)를 생성.
• Secondary: Primary의 Oplog를 복제하여 데이터를 동기화. 읽기 작업 분산 가능.
• Arbiter: 데이터를 저장하지 않으며 투표(Election)에만 참여. 하드웨어 자원이 부족할 때 사용.

2. Oplog (Operations Log)

Primary에서 수행된 모든 데이터 수정 로그를 담고 있는 특수한 Capped Collection입니다. Secondary는 이 로그를 보고 자신의 데이터를 최신 상태로 유지합니다.

3. 장애 조치 (Failover) 및 선출 (Election)

Primary가 응답하지 않으면 Secondary 노드들이 투표를 통해 새로운 Primary를 선출합니다.

• 과반수(Majority) 이상의 노드가 살아있어야 새로운 Primary 선출이 가능합니다.

4. 읽기 선호도 (Read Preference)

• Primary: 오직 Primary에서만 읽음 (기본값).
• Secondary: Secondary에서만 읽음.
• Nearest: 네트워크 레이턴시가 가장 낮은 노드에서 읽음.

5. 실습 명령어

// 레플리카 셋 초기화 (최초 1회)
rs.initiate()
 
// 새로운 멤버 추가
rs.add("server-ip:port")
 
// 레플리카 셋 상태 확인
rs.status()
 
// 현재 노드가 Primary인지 확인
rs.isMaster()

6. 시험 팁 (Certification Tips)

• 3노드 구성에서 1대가 죽었을 때와 2대가 죽었을 때 각각 새로운 Primary 선출이 가능한지 구분하세요 (과반수 원칙).
• Arbiter는 데이터를 저장하지 않으므로 데이터 백업 용도로 사용할 수 없습니다.
• Oplog의 크기가 너무 작으면 Secondary 동기화가 끊길 수 있습니다.

7. 베스트 프랙티스

• 가급적 홀수(3, 5, 7) 대의 노드로 구성하여 투표 시 동점을 방지하세요.
• 중요한 환경에서는 w: majority 쓰기 확인 옵션을 사용하여 데이터 유실을 방지하세요.