[MongoDB] Replica set이란?

 

A replica set in MongoDB 

몽고디비에서 A replica set이란 똑같은 데이터 set을 유지하는 mongod processes의 한 그룹이다. Replica sets은 redundancy(중복)과 high availability(높은 사용성)을 제공하고 모든 production deployments의 기본이 된다. 

 



 

Redundancy & Data Availability

Replication은 redundancy와 data availability를 제공한다. 다른 데이터베이스 서버들의 여러개의 데이터 카피본들로, replication은 하나의 데이터베이스 서버의 손상에 대항할 수 있다. 

 

어떤 경우에는 Replication은 읽기 능력을 향상시켜주기도 한다. clients가 다른 서버들로 read operations (읽기 처리)를 보낼 수 있기 때문이다. 다른 데이터 센터에 복제 데이터를 가지고 있는 것은 광범위한 applications들에게 데이터의 locality와 이용가능성을 높여준다. 자연재해, 리포팅, 백업 등, dedicated 목적을 위해 추가적인 복제본을 지닐 수 있다.

 

=> 이 이유로 mongoDB schema를 짤 때, read: 'secondaryPreferred'로 설정 -> 부하 방지 

example code : 

    // 삭제 날짜
    deletedAt: { type: Date },
  },
  {
    timestamps: true,
    read: 'secondaryPreferred',    // secondary로 먼저 읽기
    skipVersioning: true,
    versionKey: false,
  },
);

 

 

Replication in MongoDB

A replica set은 같은 데이터를 저장하고 있는 mongod 인스턴스들의 한 그룹이다. A replica set은 몇몇의 노드들과 optional한 하나의 결정권자 노드를 bearing하고 있는 데이터를 가지고 있다. 노드들을 bearing하고 있는 데이터 중에 오직 하나의 멤버가 primary node로 여겨진다. 요 primary node를 제외한 다른 모든 노드들은 secondary nodes로 여겨진다. 

The primary node는 모든 write operations (쓰기 처리) 를 받는다. A replica set can have only one primary capable of confirming writes with { w: 'majority' } write concern; 비록 일부 상황에서는 또다른 mongod instance가 아마 일시적으로 스스로가 primary라고 믿을 수도 있다. The primary는 모든 변경사항을 본인의 operation log에 있는 data sets에 기록한다. 더 많은 primary에 관한 정보는, Relica Set Primary를 클릭

 

 

 

 

 

 

 

Secondary들은 primary의 operation log (i.e. oplog) 를 복제해서 그들의 data sets에 적용시켜서 secondaries의 data sets은 결국 primary의 data set을 반영하게 된다. 만약 primary가 사용할 수 없는 상황이면 자격이 괜찮은 secondary 하나가 본인을 새로운 primary로 뽑자고 선거를 스스로 진행한다. (신기한 몽고디비 세계)

더 많은 secondary에 관한 정보는 Replica Set Secondary클릭 

 

 

 

 

 

 

primary 하나, secondary 하나를 각각 가지고 있지만 cost constraints(비용 통제)가 또다른 secondary를 추가하지 못하게 만드는 경우와 같이 어떨 때에는, a mongod instance를 replica set에 결정권자(an arbiter)로써 추가할 수도 있다. 결정권자는 선거에 참여하지만 data를 지닐 수 없다. (i.e. does not provide data redundancy).

 

결정권자는 항상 결정권자이다. 반면 a primary는 선거기간동안 secondary가 될 수도 있고 secondary가 primary가 될 수도 있다. 

 

결정권자에 대한 더 많은 정보는 Replica Set Arbiter 클릭

 

 

 

 

 

Asynchronous Replication

Secondaries는 primary의 operation log를 복제하고 본인들의 data sets에 비동기적으로 붙여넣는다. primary의 data set을 비동기적으로 반영하는 secondaries' data set덕분에, 하나 또는 둘 이상의 멤버가 실패하더라도 replica set은 계속해서 기능할 수 있다. 

 

 

 

 

---

 

 

 

위의 링크걸린 내용들 : 

1) replica set primary 

2) replica set secondary 

3) replica set arbiter 

 

 

Replica Set Primary 

The primary 는 replica set에서 "write" 쓰기 opration을 처리하는 유일한 멤버이다. 몽고디비는 write operations를 primary에 적용하고 그리고 primary의 operation log에 기록한다. 그리고 나서 secondary 멤버들이 primary의 log를 복제하고 본인들의 data sets에 저장한다. 

 

위의 그림처럼 Three-member replica set에서 primay가 모든 write operations를 받고 그리고 secondaries들이 복제한다. 

Replica set의 모든 멤버는 "read" 읽기 operations를 처리할 수 있다. 그러나 디폴트값으로 하나의 application은 본인의 "read operation" 읽기 처리 활동을 primary 에게 보낸다. 이 디폴트 값을 변경하고 싶다면 아래표처럼 read 설정을 해주면 된다. 

 

Replica set은 최대 단 하나의 primay를 가질 수 있다. 만약 현재 primary가 이용불가해지면 선거가 열리고 새로운 primary가 결정된다. 자세한 선거 정보는 Replica Set Elections 클릭 

 

Preferences :

Preferences
primary (default)	primary부터 오직 읽는다. 만약 primary를 이용할 수 없다면 에러가 난다.  Read from primary only. Operations will produce an error if primary is unavailable. Cannot be combined with tags.
secondary	secondary부터 읽고 가능하지 않다면 에러  Read from secondary if available, otherwise error.
primaryPreferred	primary부터 읽고, 여의치 않은 경우 secondary를 읽는다.  Rad from primary if available, otherwise a secondary.
secondaryPreferred	secondary부터 읽고, 여의치 않은 경우 primary를 읽는다.  Read from a secondary if available, otherwise read from the primary. * mongoDB가 보통 primary를 주로 씀 (쓰기), 부하 막기위해 읽기는 요 옵션으로 먼저 줌
nearest	가장 가까운 후보자부터 읽는다. primary, secondary 구분하지 않는다.  All operations read from among the nearest candidates, but unlike other modes, this option will include both the primary and all secondaries in the random selection.

 

위의 3-member replica set에서 primary가 이용 불가해졌고 선거로 남은 secondaries중 primary를 선발한다. 

 

** 일부 경우에는 replica set의 두개의 노드가 일시적으로 그들이 모두 스스로 primary라고 믿는 경우가 있다. 그러나 많아봐야 그들 중 한명만이 { w: 'majority' } write concern으로 writes를 완료할 수 있고 이를 작업한 node 가 현재 primary가 된다. 그리고 이전 primary였던 다른 노드는 아직 본인이 primary로부터 강등되었다는 사실을 아직 모른다. (보통 이유는 네트워크 오류) 이러한 일이 발생할 때, 이전 primary에게 연결한 clients들은 read prefernce를 "primary"라고 지정했었어도 아마 이전의 데이터를 받았을 지도 모른다. 이전 primary에게 적용된 writes는 결국에는 이전으로 돌아간다. (roll back)

 

 

 

 

 

Replica Set Secondary 

A secondary는 primary's data set의 복제본을 유지한다. secondary는 primary의 operation log로부터 데이터를 본인의 로그로 "비동기"적으로 복제해온다. A replica set은 하나 또는 그 이상의 secondaries를 가질 수 있다. 

위의 three-member replica set은 두개의 secondary 멤버들을 가지고 있고 primary로부터 복제해온다. 

비록 clients는 secondaries에 "wirte" operation을 요청할 순 없지만 "read"읽기는 가능하다. Secondary는 primary가 될 수 있다. (위에 설명대로 단 하나만 존재하는 primary가 사용불가가 되면 남아있는 secondaries 중 하나를 primary로 선출함) 

 

특정한 목적을 위해 a secondary member를 환경설정할 수 있다. 예를 들면 아래와 같은 이유들로 인해 환경설정 한다. 

 

* 선거에서 primary가 되는 것을 방지하기 위함

(a secondary data center에서 있도록 (reside) 해주거나 또는 a colde

standby로써 serve되도록) 

 

* applications들이 이것으로부터 읽는 것을 방지하기 위함

(정상적인 트래픽으로부터 구분을 요구하는 applications을 진행하도록) 

 

* 특정 에러들로부터의 회복에 사용하기 위한 "historical" snapshot을 계속 운영하기 위함 

(특정 에러의 예: 의도적이지않게 db를 지운 경우) 

 

 

 

 

 

 

Replica Set Arbiter

primary와 secondary를 둘 다 가지고 있지만 cost constraints가 또다른 secondary 추가를 막을 경우 이러한 상황에서는 결정권자로 선택할 수 있다. 결정권자는 data set의 복제를 가질 수 없고 (primary, secondary는 모두 가지고 있음) primary가 될 수 없다. 그러나 결정권자는 선거에는 primary로 참여한다. 하나의 결정권자는 정확히 1개의 선거표를 가지고 있다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

References : 

https://docs.mongodb.com/manual/replication/

Replication — MongoDB Manual