replica set

moongq·2021년 1월 8일
0

MongoDB

목록 보기
5/7

Replica Set

replica set은 mongod process들의 한 그룹을 말합니다. 이 그룹은 같은 데이터 셋을 가지고 있으며 같은 값을 유지하게 됩니다. 레플리카 셋은 데이터 중복성(Redundancy)과 고가용성(high availablity)을 제공해줍니다. 그리고 production 배포에서는 필수적인 요소입니다. (당연하게도 단일 갯수의 db로 데이터를 유지하면 불안정하죠). MongoDB의 데이터 복사/복제와 replica set의 구조를 알아봅시다.

중복성과 데이터 가용성

Replication은 데이터 중복(여러 군데에 저장해준다.)을 만들어주고 데이터 가용성을 향상시킵니다. 여러 데이터베이스 서버에 걸쳐 데이터 복사본들이 저장되어 있게 되기 때문에 단일 데이터베이스를 이용하는 것보다 큰 안정성을 제공해줍니다.
보통의 replication은 여러 곳의 db서버로부터 읽기를 진행하기 때문에 향상된 읽기 성능을 제공해줍니다. 또한 재해 복구, report, 백업등의 특별한 작업을 위해 추가적인 복사본들을 저장해둘 수도 있습니다.

high abailablity
high availablity(고가용성)은 시스템에서 지원하는 애플리케이션이 장기간 다운 타임없이 지속적으로 작동할 수 있도록 내구성, 중복성 및 자동 장애 조치를 위해 설계된 시스템을 나타냅니다.

MongoDB의 Replication

replica set은 같은 데이터 셋을 유지하는 mongod 인스턴스들의 그룹입니다. 레플리카 셋은 여러개의 bearing 노드들과 선택적인 한개의 arbiter(중재자) 노드로 구성됩니다. bearing 노드중에 오직 하나만이 primary 노드가 되며 나머지는 secondary 노드가 됩니다.

primary node는 모든 쓰기작업을 받습니다. replica set은 오직 한개의 primary만을 가질수 있으며 write concern을 { w: "majority" }로 설정함으로 써 확실히 해둘수 있습니다.

#write concern

  • w: 얼마나 많은 수의 mongod 인스턴스들에 새로운 쓰기 데이터가 전파되어야 확인하는 옵션, 확인이 되어야만 db 작업의 결과를 리턴하게 됩니다.
    새로운 쓰기 작업마다 과반수 이상의 노드에서 같은 데이터를 가지게 되었을 때 response를 하게 됩니다.
  • wtimeout: 작업이 어떠한 이유로든 지연되는 상황에 무기한 지연이 되지 않도록 시간 제한을 두는 옵션입니다.

[이미지1]

secondary들은 primary의 작업 로그를 복제하여 같은 데이터셋을 유지하게 됩니다. 그리고 만약 primary가 멈췄거나 문제가 생겼을 때는 선거를 통해 새로운 primary 를 선정합니다.

어떤 상황에서는 mongod 인스턴스중에 한개를 특정하여 arbiter(중재자)로 두기도 합니다. 이 중재자 인스턴스는 투표에만 참석할 뿐 데이터를 가지지 않습니다.(데이터 저장소의 역할을 하지않고 정말 투표에만 쓰입니다.)

자동 장애 조치

primary 가 replica set의 멤버들과 정해진 electionTimeoutMillis 기간만큼 연락되지 않는다면, secondary는 투표를 실행하고 새로운 primary가 선택됩니다. 그리고 자연스래 다시 데이터베이스 본연의 업무를 재개합니다.

[이미지2]

  • 장애 상황에서의 쓰기
    replica set은 투표가 성공적으로 완료되기전에는 쓰기 작업을 진행할 수 없습니다. 다만 retryWrites=true 옵션을 설정해둔다면 primary가 생성된뒤 다시 다시 한번 쓰기 작업이 실행됩니다.

  • 장애 상황에서의 읽기
    장애 상황에서 쓰기는 진행할수 없지만 읽기 작업은 가능하게 할 수 있습니다. run on secondaries를 설정해둔다면 primary가 offline 인 상태에서도 secondary들을 통해 읽기 작업은 문제없이 진행됩니다.

Transactions

mongoDB 4.0부터 replica set에서 multi-document transaction이 가능해졌습니다. 읽기 작업이 포함된 multi-document transaction이라면 반드시 primary안에서만 진행되어야 합니다. 멤버마다 데이터의 통일성이 항상 지켜질수는 없기 때문에 모든 작업은 같은 멤버에서 진행되어야만 합니다.

profile
https://medium.com/nodejs-server

0개의 댓글