세상의 모든 Software 지식을 정리

* Arbiter 는 데이터셋을 복사할 수 없고 primary가 될 수 없다. 레플리카 셋들은 arbiters를 가질 수 있고 primary를 선정하기 위해 투표를 한다. Arbiters 항상 1개의 표를 행사한다. 결국 Primary가 죽어 새로운 Primary를 선정하기 위해서는 투표가 이뤄지게되고, Arbiter가 한표를 행사하게 되면서 홀수 표가 되어 새로운 레플리카셋을 생성하는 오버헤드가 없어지게 된다. 중요사항 :  Do not run an arbiter on systems that also host the primary or the secondary members of the replica set aribter를 가지고 있는 레플리카 셋에서, 프로토콜 버전1 (pv1) 은 프로토콜 버전 0 (pv 0)과 비교했을 때 rollback의 가능성을 증가시킨다. w:1  예) 예를들어 다음과 같은 replica set에서 arbiter가 있으므로 투표결과가 홀수가 되게 만든다. <Security> Authentication : aribiter는 데이터를 저장하지 않는다. 그래서 aribiter는 유저테이블 그리고 권한인증을 위한 맵핑정보가 없다. 그래서 local host Exception을 이용해 로그를 남긴다. Communication : arbiters와 다른 set 멤버들간의 유일한 커뮤니케이션은 투표, heartbeats 그리고 configuration data이다. 이것들은 암호화되지 않는다. 그러나 만약 몽고db 배치가 TLS/SSL이면 커뮤니케이션은 암호화된다. * Local host Exception ?

* Delayed memebers 는레플리카 복사본을 포함한다. Delayed memebers은 rolling backup 을 한다. 또는 "historical"이라는 데이터셋의 스냅샷을 작동한다. 그것은 다양한 실수를 대비해 복원시켜주는 기능이다.  <Consideration> Requirements priority 0이어야 한다.  hidden memeber이어야 한다. primary를 결정하기 위한 투표를 해야 한다.  Behavior Delayed memebers는 delay에 대한 오피로그를 복사하고 적용한다. dealy의 시간양을 선택했을 때,  딜레이 시간을 다음과 같이 고려한다. must be equal to or greater than your expected maintenance window durations. must be  smaller  than the capacity of the oplog. For more information on oplog size, see  Oplog Size . Sharding 샤드 클러스터에서는, delayed memebers 는 balancer가 enable되었을때 제한된 기능을 가지고 있다. 왜냐하면 delayed members 들은 딜레가 있을 때 대량의 마이그레이션이 발생하기 때문이다. 예) 5개의 replica set이 있고,  primary와 모든 secondaries가 데이터셋을 복제한다. 그때 한 멤버가 약 1시간동안 delay를 적용한다. 이러한 delayed member는 hidden 이고 priority 0 멤버이다. 설정 A delayed member는 members[n].priority 가 0가 되어야 한다. 그리고 members[n].hidden은 true로 설정되어야한다.

* Hiddent 멤버는 primary`s데이터 셋을 복사해놓지만 클라이언트 애플리케이션에 보이지 않는다. Hidden members는 항상 priority 0 멤버이며 primary가 될 수 없다. * db.isMaster() 를 치더라도 히든 멤버는 노출되지 않는다. 그러나 투표에는 참여한다. <Behavior> Read Operation 클라이언트는 읽기를 적절한 히든 멤버들에게 분배시키지 못한다. 결과적으로 이러한 멤버들은 트래픽을 받지 않는다. 그러므로 Hidden members는 reporting이나 backups와 같은 헌신적인 일들을 하는데 주로 쓰인다. Delayed member들은 히든이 된다. 샤드클러스터에서는 mongos는 히든 멤버들과 상호작용하지 않는다. Voting 히든 멤버들은 replica set 투표에 참여한다. MMAPv1 스토리지 엔진을 사용하는 경우, db.fsyncLock() 와 db.fsynUnlock()을 사용하여 히든멤버가 stop하는것을 막을 수 있다. 버전 3.2에서는 db.fsyncLock() 는 데이터 파일들이 변화하는 것을 막을 수 있다.그러므로 일관성을 제공하고 백업의 목적을 달성 할 수 있다. 이전 버전의 몽고디비에서는 db.fsyncLock()은 Wired Tiger에서의 로우 레벨의 백업을 보장하지 않았다.

priority 0로 설정된 멤버는 primary가 될 수 없다. 또한 투표의 계기(trigger)가 될 수 없다. 대신 A priority 0 멤버는 데이터의 복사본을 유지하고, read하고, election에 투표할 수 있다. priority 0로 설정된 멤버는 primary가 될 수 없다고 했는데, 이것은 multi-data center 개발에서 유용히 쓰인다. <Priority 0 Members as Standbys> priority 0 멤버는 standby 와 비슷한 기능을 사용할 수 있는데, 충분한 시간안에 새로운 멤버를 추가하는 것이 불가능하다. standby 멤버는 현재의 데이터 copy를 유지하고 이용가능하지 않은 멤버로 대체할 수 있다. 많은 케이스에 우리는 priorty 0 로 설정할 필요없다. 그러나 다양한 하드웨어, geographic distribution 같은 경우, priority 0 standby는 qualified member의 경우 primary가 되는 것을 보장한다. priority 0 standby는 아마 몇몇 멤버가 다양한 하드웨어, workload profiles의 종류라면 가치가 있다. 이러한 경우에도 priority 0 는 primary가 될수 없다. 이러한경우는 hidden member를 고려해보는것도 좋은 방버이다.

* 비록 클라이언트가 secondaries에 write 할 수 없을지라도 read는 가능하다. 만약 primary 가 이용 불가능해지면 남은녀석들이 투표를 진행하고 primary를 새로 선정한다.

* Primary는 write Operation을 적용한 후 그 operation을 primary`s oplog에 기록한다. Secondary members 는 이 로그를 replicate하고 그들의 데이터셋에 그 operation을 적용한다. 그렇다면 데이터를 복제하는 것이 아니라, 로그를 복제하고 그 해당 로그로 작업을 수행시켜 데이터를 만드는 것인가?  모든 멤버들( sencondary, primary)은 read operation을 허용한다. 그러나 default적으로 애플리케이션은 그것의 read 작업을 primary에 직접적으로 한다. 이러한 디폴트값은 변경가능하다. 레플리카셋에서 무조건1개의 primary는 필요하다. 위 그림은 3 member의 replica set을 보여준다. 만약 primary가 이용 불가능 해지면 남은 녀석들로 election을 선정한다. * 몇가지 상황에서는 replica set의 두 노드가 일시적으로 자신들이 primary라고 믿는 경우가 생긴다.   but at most, one of them will be able to complete writes with  {   w:   "majority"   }  write concern

*레플리카셋에는 3가지 멤버가있다. -> Primary -> Secondaries -> Arbiter *Arbiter ->Arbiter는 데이터의 복사본을 유지 하지 않는다, 그러나 Primary가 이용가능하지 않는다면 Primary를 유지하기 위한 투표에 참여한다, <Primary> Primary는 write 오퍼레이션을 사용하는 멤버이다,  MongoDB는 write오퍼레이션을 작동한다 그리고 Primary`s oplog에 저장한다, Secondary는 이 로그를 복제하고 데이터셋에 적용한다, Replica Set 멤버들은 read Operation을 사용한다. 그러나 default 조건으로 application은 primary member에서 read를 다이렉트로 한다. 레플리카셋에서 많아야 한 개의 Primary를 가진다. 만약 현재의 primary가 이용 불가능해지면 투표를 통해 primary를 선정한다.  <Secondaries> Secondary는 Primary`s data set의 복사본을 유지한다. 데이터를 복제하기 위해 secondary는 primary`s oplog로부터 비동기적 프로세스로 작업을 수행한다. 클라이언트는 secondaries로 부터 write를 할 수 없을 지라도, read는 가능하다. 다음은 특별한 목적에 따라 secondary를 설정할 수 있는 것들이다. Primary가 투표에 참여하는 것을 막는다.  읽기 작동을 방지한다. application이 작동하는 경우 seperation이 필요하다. historical snapshot을 계속 유지하는 것이 가능하다. 이것은 특별한 에러가 발생했을 때 회복시켜주는 것이다. 의도하지 않게 데이터베이스가 삭제된 경우 <Arbiter> Arbiter는 데이터셋을 복사 할 수 없고, primary가 될...