MongoDB 투표 및 선거 알고리즘 정리
1. 투표를 위한 최소 노드 수
MongoDB의 레플리카 셋에서 선거가 진행되려면 투표 가능한 노드가 과반수를 넘어서야 함. 즉, 전체 노드 중 절반 이상의 노드가 가용 상태여야 선거가 진행되며, 과반수를 확보하지 못하면 선거가 일어나지 않음.
아래는 각 노드 수에 따른 투표를 위한 최소 노드 수를 정리한 표임.
전체 노드 수 | 투표를 위한 최소 노드 수
------------------------------
2 | 2
3 | 2
4 | 3
5 | 3
6 | 4
7 | 42. 선거 알고리즘
MongoDB는 Replica Set에서 Primary 노드가 다운되거나 네트워크 문제가 발생하면, 남아 있는 Secondary 노드 중 하나가 Primary로 선출되기 위해 선거(Election)가 진행됨. MongoDB의 protocolVersion 1에서는 Raft 합의 알고리즘을 기반으로 새로운 Primary를 선출함. 이 알고리즘은 이전 버전보다 직관적이고 효율적인 합의 메커니즘을 제공하며, failover 시간을 단축시킴.
- 투표 과반수 필요: 선거를 통해 Primary가 되려면 투표 가능한 노드의 과반수를 넘는 투표를 받아야 함. 과반수를 확보하지 못하면 Primary 선출이 이루어지지 않음. 따라서 최소 과반수 이상의 노드가 온라인 상태여야 선거가 진행됨.
3. Election에 영향을 미치는 요인들
-
Replication Election Protocol (protocolVersion)
- protocolVersion 1에서는 Raft 합의 알고리즘을 도입하여 failover 속도를 높이고, 선거 과정을 더 효율적으로 만듦. 이전 버전(protocolVersion 0)에도 선거 메커니즘이 있었지만, protocolVersion 1에서 Raft로 변경됨으로써 합의 과정이 더 직관적으로 개선되었음.
- catchUpTimeoutMillis: 새로운 Primary가 기존 Primary로부터 데이터를 동기화하는 데 걸리는 시간을 설정함. 이 값이 너무 짧으면 동기화 도중 선거가 다시 일어나면서 데이터 롤백이 발생할 수 있음. 반대로 너무 길면 failover 과정이 지연될 수 있음. 기본값은 -1이며, 이 경우 무제한 동기화를 진행하게 됨.
-
Heartbeats (하트비트)
- 모든 노드는 2초마다 heartbeat(핑)을 주고받아 서로의 상태를 확인함. 10초 동안 응답이 없으면 해당 노드를 실패로 간주함. 하트비트는 노드 간의 네트워크 연결 상태를 감지하는 중요한 메커니즘임.
-
Member Priority (우선순위)
- 각 노드는 priority 값에 따라 Primary로 선출될 가능성이 달라짐. priority 값이 높은 노드가 선거에서 우선적으로 Primary가 될 수 있으며, priority가 0인 노드는 Primary로 선출될 수 없음. 이 값은 선거 타이밍과 결과에 직접적인 영향을 미침.
-
Mirrored Reads
- Mirrored Reads는 Secondary 노드의 캐시를 최신 상태로 유지하여, Primary에서 발생한 데이터를 더 빠르게 읽을 수 있도록 함. 이를 통해 읽기 성능을 향상시키는 데 중점을 두고 있음. 이 기능은 읽기 성능을 최적화하는 데 도움이 되며, 선거에 직접적인 영향을 미치지는 않음.
-
Loss of a Data Center (데이터 센터 손실)
- 데이터 센터의 손실이 발생하면 남은 Replica Set 내에서 과반수를 확보한 노드 중 하나가 새로운 Primary로 선출될 가능성이 높음. 이때 네트워크 파티션이나 데이터 센터 손실로 인해 특정 노드가 선거에 참여하지 못하는 경우가 생길 수 있음.
-
Network Partition (네트워크 분리)
- 네트워크가 물리적으로 분리되어 일부 노드 간 통신이 불가능해지면, Primary 노드는 Secondary로 강등될 수 있음. 이는 네트워크 파티션 상황에서 split-brain 현상을 방지하기 위한 메커니즘으로, 과반수 이상의 노드가 Primary로 인정받지 못하면 자동으로 Secondary로 전환됨.
4. Primary가 혼자 남을 수 없는 이유 (Split-Brain 방지)
Primary 노드가 혼자 남아 있을 경우 여러 문제가 발생할 수 있음. MongoDB는 이러한 상황을 방지하기 위해 Primary가 과반수 노드를 확보하지 못할 경우 자동으로 Secondary로 강등되도록 설계됨.
- Split-Brain 방지: 네트워크 분리로 인해 두 그룹이 분리되면, 각각 자신을 Primary로 인식하는 Split-Brain 현상이 발생할 수 있음. 이를 방지하기 위해 Primary는 과반수 이상의 투표를 얻지 못하면 Secondary로 전환됨.
- 데이터 일관성 문제: Primary가 혼자 남아 데이터를 계속 수정하면, 다른 Secondary 노드들이 이 데이터를 동기화하지 못해 데이터 일관성에 문제가 생길 수 있음.
- 가용성 문제: Primary가 혼자 남았을 때 해당 노드에 장애가 발생하면 전체 시스템이 중단될 수 있음. MongoDB는 이러한 상황을 방지하기 위해 Primary를 강제로 Secondary로 강등시킴.
5. 노드가 다운될 경우의 처리
노드가 2개인 경우
- Primary 노드가 다운된 경우:
- 선거가 진행되지 않으며, 쓰기 작업은 불가능해짐. 그러나 read preference가 Secondary로 설정된 경우 읽기 작업은 계속 가능함.
- Secondary 노드가 다운된 경우:
- 선거가 진행되지 않으며, Primary 노드는 계속해서 읽기 및 쓰기 작업을 처리할 수 있음.
노드가 3개인 경우
- Primary 노드가 다운된 경우:
- Secondary 노드 중 하나가 선거를 통해 새로운 Primary로 선출됨. 선거 도중 일시적으로 쓰기 작업이 중단될 수 있음.
- Secondary 노드가 다운된 경우:
- Primary는 여전히 쓰기 작업을 처리할 수 있으며, 다른 Secondary 노드에서 읽기 작업도 가능함.
참고 사이트
성장중