[MongoDB] MongoDB - 복제 (1)

MongoDB in Action을 바탕으로 정리한 내용입니다.

“장애는 항상 발생한다”

복제는 여러 MongoDB 서버에 데이터를 분산하고 관리하는 것이다.
MongoDB는 하나 이상의 노드로 데이터를 복사할 수 있으며, 변경이 발생하면 지속적으로 동기화한다.
이러한 유형의 복제는 복제 세트 (Replica set)이라고 불리는 메커니즘을 통해 제공.
- 노드 그룹이 자동으로 데이터를 동기화하고 노드가 사라지면 장애조치를 수행하도록 구성한다.
프라이머리 노드에서 모든 쓰기 연산이 수행되고 세컨드리 노드는 읽기를 수행하는데, 쓰기는 비동기적으로 세컨더리 노드에 적용된다.

참고로 오래된 방법인 Master-Slave 방식도 제공하는데, Replica set과 같은 복제 메커니즘을 사용하지만, 복제 세트는 추가로 자동 장애조치를 보장한다.

복제 세트에서 데이터는 서버의 50% 이상을 의미하는 과반수의 멤버 노드에 기록될 때까지 실제로 커밋된 것으로 간주되지 않는다.

모든 데이터베이스는 실행되는 환경에서 장애를 겪을 수 있다. (네트워크 단절, 하드웨어 고장 등 다양한 이유)
외부적 장애로부터 보호하는 목적 이외에 MongoDB에서 복제가 중요한 이유는 MongoDB의 내구성 때문이다.
- 저널링이 사용되지 않을 때 MongoDB의 데이터 파일은 예기치 않은 셧다운으로 인해 손상될 수도 있다.
저널링을 사용할 때도 복제가 바람직하다.
- 높은 가용성과 빠른 장애복구를 위해서는 복제가 여전히 필요함.

일반적으로 백업은 복제가 실행하는 경우에도 신중하면서 권장되는 사항이다.

복제는 일차적으로 중복성을 위해 설계된다.
- 중복성을 인해 복제 노드는 프라이머리 노드와 동기화된 상태를 유지한다.
- 복제는 비동기적이므로 노드 사이의 어떠한 종류의 네트워크 지연이나 장애도 프라이머리 노드의 성능에 영향을 끼치지 못한다.
  - 복제 노드는 프라이머리보다 몇 초, 몇 분, 심지어 몇 시간 정도 지연될 수 있다.
복제의 또 다른 용례는 장애복구.
- 높은 가용성을 위해 중복 노드를 가지고 있고 비상시에 이 중복 노드로 전환할 수 있는 능력이 있어야 하는데, MongoDB의 복제 세트는 이것을 편리하게, 자동으로 해 준다.
리소스를 많이 사용하는 연산을 프라이머리 외에 다른 노드에서 실행함으로써 데이터베이스 관리 작업을 단순하게 해준다.
- ex) 프라이머리 노드에서 필요 없는 작업을 피하고 다운타임을 미연에 방지하기 위해 백업을 세컨더리 노드에서 수행하는 것이 일반적인 관행.
복제 노드 간 로드 밸런서를 해준다.
- 주로 읽기 위주의 애플리케이션에서 복제는 MongoDB를 확장하는 가장 쉬우면서도 단순한 방법.

작업 데이터가 가용 RAM보다 많을 경우 세컨더리 노드로 읽기 요청을 하면 기대했던 만큼의 성능이 나오지 않을 것.
- 이 경우 샤딩이 더 나은 옵션이 될 수 있다.
읽기에 대한 쓰기 비율이 50%를 초과하는 경우 (대략적인 수치)
애플리케이션에 일관성이 요구되는 읽기가 필요한 경우
- 세컨더리 노드는 비동기적으로 복제를 수행하므로 프라이머리 노드에서 수행된 마지막 쓰기를 반영하지 못할 수도 있다. (최종 일관성)
- 세컨더리 노드로 가서 쓰기를 보장할 수는 있지만 대기 시간에 대한 오버헤드가 존재.

즉 복제 세트는 즉각적인 일관성이 필요하지 않은 읽기 확장에 적합하다고 할 수 있다.

복제 세트에 대해 권장되는 최소의 구성은 세 개의 노드로 이뤄진 것.
- 이유는 노드가 두 개인 복제 세트에서 프라이머리 노드가 다운될 경우 과반수를 확보할 수 없기 때문.
3-멤버 복제 세트에는 데이터를 보유하는 3개 노드 or 데이터를 보유한 2개 노드와 아비터 1개로 구성 가능.
- 참고로 아비터는 프라이머리 선출에 참여하지만, 어떤 데이터도 복제하지 않는 경량의 mongod 서버.
프라이머리는 복제 세트에서 쓰기 작업을 허용할 수 있는 유일한 멤버.
- 복제 세트 멤버는 투표를 통해 새로운 마스터를 선출하는 프로세스를 거침.
- 프라이머리가 사용할 수 없는 상태가 되면 선거로 인해 수동적인 개입 없이 정상적인 연산을 복구할 수 있다.

복제 동작 방식

Oplog는 capped 컬렉션으로 모든 복제 노드에서 local이라는 데이터베이스 내에 있고, 데이터에 대한 모든 수정사항을 기록한다.
클라이언트가 프라이머리 노드에 대해 쓰기를 할 때마다 해당 쓰기를 세컨더리에서 재생하기 위한 충분한 정보가 프라이머리 노드의 oplog에 자동으로 추가된다.
- 일단 쓰기가 세컨더리 노드에 복제되고 나면 쓰기 정보가 세컨더리 노드의 oplog에도 기록된다.

세컨더리 노드가 어떻게 oplog에서의 위치에 대한 정보를 계속해서 유지하는가?

프라이머리 노드에 쓰기가 수행되면, 프라이머리 노드의 기록이 oplog에 추가된다.
곧이어 모든 세컨더리 노드도 자신의 oplog에 프라이머리 노드의 oplog를 복제한다. (다음 3가지 단계로 복제한다)
- 자신의 oplog에서 가장 최근 항목의 타임스탬프를 검사한다.
- 프라이머리 노드의 oplog에서 이 타임스탬프 이후의 모든 항목을 질의한다.
- 데이터 쓰기를 수행하고 이들 항목을 자신의 oplog에 추가한다.

이러한 이유로 장애 복구의 경우에 프라이머리로 승격된 어떤 세컨더리라도 다른 세컨더리가 복제할 수 있는 oplog를 갖게 된다.

[MongoDB] MongoDB ReplicaSet 설정 방법 (샤딩 X ) (0)	2022.07.20
[MongoDB] MongoDB 배포 형태 (0)	2022.03.18
[MongoDB] 샤딩 개념 (0)	2022.02.08