[컴][db] mongodb replica set 의 Read Preference

replica set 설정 / 읽기 우선순위

ref. 1 에 대한 번역이다.

mongodb replica set 의 Read Preference

• 기본값은 read operation 들을 replica set 의 primary member 에게 보내는 것이다.(즉, read preference mode 가 primary)
• Read preference 는 다음 4가지로 구성된다.
  • read preference mode
  • optional: tag set
  • optional: maxStalenessSeconds
  • optional: headged read : non-primary read preference를 사용하는 read를 위한 MongoDB 4.4+ sharded cluster들에서 가능하다.

4.4 버전부터, non-primary read preference 모드들은 sharded cluster들에서 hedged read 를 지원한다.

Read Preference Mode

• primary : default 값이다. 모든 명령들은 현재 replica set 의 primary 에서 이뤄진다.
  

  read operation들을 가지고 있는 multi-document transactions 들은 primary read preference를 이용해야만 한다. 주어진 transaction에 있는 모든 operation들은 같은 member로 가야 한다.

• primaryPreferred: 대부분의 경우에, opration들은 primary 에서 읽어오지만, 만약 그것이 가능하지 않을때, operation들은 secondary member들에게서 읽어온다.

  4.4버전 부터, primaryPreferred는 shared cluster에서 hedged reads 를 지원한다.

• secondary : 모든 operation들은 replica set 의 secondary member들에게서 읽는다.

  4.4버전 부터, secondary는 shared cluster에서 hedged reads 를 지원한다.

• secondaryPreferred: 대부분의 경우에, operation들은 secondary member들에게서 읽어온다. 그러나 가능한 secondary member가 없거나, operation들이 sharded cluster의 primary 에서 읽어온다.

  4.4 버전부터, secondaryPreferred 는 shared cluster에서 hedged reads 를 지원한다.

• nearest : operation들(명령어들)은 member 가 primary 인지 secondary 인지 관계없이 정의된 latency threshold 에 기초해서 random eligible replica set member 에게서 읽어온다. operation 들은 latency 를 계산할 때 다음을 고려한다.

  • localThresholdMS connection string option
  • maxStalenessSeconds read preference option
  • 정의된 tag set들

  4.4 버전부터, nearest option 은 sharded cluster들에 hedged reads 를 지원한다. 그리고 기본적으로 hedged read option 을 enable 한다.

자세한 사항은 Read Preference Modes 를 참고하자.

• Read Preference Modes | Read Preference — MongoDB Manual

동작

• primary read preference 모드를 제외한 모든 read preference mode 들은 stale data (오래된 data) 를 반환할 수 있다. 왜냐하면 secondary는 비동기 처리로 operation들을 복제하기 때문이다.

  non-primary 모드를 사용하도록 선택한 경우 응용 프로그램에서 오래된 데이터(stale data)를 사용해도 문제가 없는지 확인해야 한다.

• read preference 는 데이터의 visibility에 영향을 주지 않는다. 즉, 클라이언트들은 write 결과를, 그 결과 들이 승인(acknowlegded)되기 전에, 또는 대부분의 replica set member들로 전파되기 전에 볼 수 있다. 자세한 내용은 Read Isolation, Consistency, and Recency 를 보자.

• read preference 은 인과적 일관성(casual consistency)에 영향을 주지 않다.

  ‘majority’ read concern read operation 들과 ‘majority’ write concern write operation 들을 위한 casual consistency guarantees 는 인과적으로 일관된 세션들에 의해 제공된다.

  이 인과적 일관성 보장들(casual consistency guarantees)은 MongoDB deployment의 모든 member들에 걸쳐 유지된다.

maxStalenessSeconds

• Read Preference maxStalenessSeconds — MongoDB Manual

maxStalenessSeconds read preference option 은 seondary들에서 읽기를 하면서, ’primary의 writes를 replicating하는 것에 아주많이 뒤떨어진 seondary들’로 부터 읽기를 하는 것을 피하고 싶어하는 application 들을 위한 것이다.

예를 들어 seondary들는 자신과 primary 간의 네트워크 중단으로 인해 복제가 중단될 수 있다. 이 경우 관리자가 운영 중단을 해결하고 seondary들이 따라잡기 전까지 클라이언트는 seondary들에서 읽기를 중지해야 한다.

이 옵션을 이용하기 위해서는 모든 node instance 의 mongod version 이 3.4이상이어야 한다. 하나라도 버전이 낮으면 driver가 error 를 발생시킨다.

이 옵션은 primary mode 에서는 호환되지 않고, 단지 secondary member 를 선택하는 때에만 사용된다.

maxStalenessSeconds 를 이용해서 read operation 을 위한 서버를 선택할 때,

• client들은 각각의 secondary 가 얼마나 오래됐는지를(how stale) 측정한다. 이 측정은 secondary 의 “primary 로의 마지막 write”을 비교하는 것을 통해서 하게 된다.
• 그리고나서, client 는 read operation 을 그것의 측정된 지연(estimated lag) 이 maxStalenessSeconds이하인 secondary 로 향하게 한다.
• primary 가 없으면 client 는 비교를 위한 write중 ’가장 최근 write’를 가진 secondary 를 이용한다.
• 기본적으로, staleness 에 max 값은 없다. 그리고 client 들은 read operation을 어디로 보내는지 선택할 때 secondary의 지연을 고려하지 않는다.
• maxStalenessSeconds 값은 90초 이상으로 지정해야 한다. 이보다 작은 maxStalenessSeconds 값을 지정하면 오류가 발생한다.
• maxStalenessSeconds 값을 90초 미만으로 적용할 수 없는 이유
  • client들은 각 replica set member의 최신 write 날짜를 주기적으로 확인하여 secondary들의 staleness 측정한다.
  • 이러한 검사는 자주안하기 때문에 staleness 추정치는 대략적입니다. 따라서 client들은 maxStalenessSeconds 값을 90초 미만으로 적용할 수 없다.

References

1. Read Preference — MongoDB Manual