제스트의 블로그

앞서 보여준 그림을 보시면 오른쪽 위가 config server 되있을 것이다. 이는 shard에 대한 모든 쿼리(?) 들을 저장하며, 이를 가지고 백업 등에 사용 하게 된다.  그림의 가운데 위 mongos 라 써있는 서버 보다 먼저 셋팅 해야하는 이유는 mongos 에 config server의 설정을 써야 하므로 config server 를 먼저 셋팅 해야한다. 

설정 정보는 기존 yml 파일과 거의 비슷하다. 

기존 replica set 과 다른점은 replication을 안쓰고 sharding이라는 설정이 추가 됐다. 그리고 clusterRole이라는 항목에 configsvr 이라는 configserver의 약자를 써주면 된다. 

공식 사이트에선 이 서버를 여러대 설치 하라고 권장한다. 이유는 다른 정책 서버가 장애가 났을 시 다른 서버에서 값을 가져올 수 있으므로 권장한다. 머 다른이유는 없는거 같다. 

서버는 replicaset 과 동일하게 실행하면 된다. 

실행 후 process는 다음과 같은 형태가 될 것이다. 

아래 shard_config.yml이 정책 서버가 된다. 그럼 다음에는 mongos에 대해 알아본다. 

이번에는 replicaset에 대해 설정해보자. 먼저 단일 서버를 셋팅한 yml 파일을 복사후 replication name을 셋팅하면 된다. 

그럼 위에 서버들이 replicaset으로 제대로 셋팅이 되었는지 확인해보자. 

아무 몽고 서버에 먼저 접속을 한다. (robomngo tool 추천 또는 ./bin/mongo 아이피:포트 로 접속 하면된다.)

mongodb의 replication 정보는 rs 명령어로 한다. rs.status() 함수를 하면 위 정보와 같이 나온다. 여기서  누가 primary이고 secondary인지 알 수있다. 기본적으로 모든 cloud는 대장(?)을 선출하는데 mongodb는 primary라 칭한다. 설정 정보를 보고싶으면, rs.config() 를 하면된다. 

다음은 shard config server에대해 알아보겠다. 

몽고 db는 아래 그림과 같은 모양으로 구성된다. 

(출처는 http://mobicon.tistory.com/307 이분 블로그는 볼게 많아요.) 

설명을 하자면 아마도 클라우드 환경을 지원하는 대부분의 것들이 mongodb와 유사할 것이다. (solr와 es를 좀 틀리다... =-=;;;) 

먼저 cloud는 두가지 말들이 많이 나온다. shard(파편)와 replica(복제) 이 두말이 가장 먼저 나온다. 몽고 db의 shard는 위에 그림과 같이 몽고db의 물리적 서버를 여러개 합쳐놓은 논리적 단위이다. 그럼 전체 데이터를 봤을때 샤드라고 하는 논리적 단위는 일부 만을 가지게 되고 이들이 합쳐져서 전체 데이타를 이룬다. 

 물리적 서버는 다시 노드 또는 데이터 서버 라고 칭하며, 저 노드들간의 여러개를 replicaset 이라는 이름으로 다시 집합을 이룬다. 결론은 replicaset은 흔히 말하는 replica가 된다.  replica는 들어온 데이타들을 상호간에 복제를 하게 된다. 

그럼 mongos라는 넘을 무얼까? 이넘은 클러스터 서버라는 넘이다. 유저가 쿼리를 전송을 하면 클러스터 서버는 데이터를 저장하지 않고 일종의 queue역활을 해준다. 어느 데이터를 누구한테 전할지 이러한 역활을 한다. 오른쪽 위에 보면 config servers 라는 넘이 있는데 이넘은 모든 쿼리를 저장하며 백업등을 관리한다. 이 역시 장애가 발생할 수 있으므로 여러개를 권장한다.