Mongodb cluster

MongoDB
클러스터 운영과 관리
(Chapter 4~5)

KyungSeok

Agenda

쿼리 수행

왜 이런 결과를 얻게 될까?

맵리듀스

셸 사용하기

모니터링

백업

시스템 구성 제안

오작동에 대한 대처

쿼리 수행

 부하 분산을 이유로 읽기 작업을 클러스터 내의 부 서버로 분산 할
수 있다.
– 읽기 작업의 부하 처리에는 매우 용이
– 부 서버에 대한 데이터를 수행할 때에는 오래된 데이터를 얻을 수 도 있음.
 사용 방법
– Slave okay 옵션을 설정한다
db. getMongo( ) . setSlaveOk( )

왜 이런 결과를 얻게 될까?

 클러스터 환경에서는 컬렉션 전체를 조회 할때의 결과 데이터가 실제
데이터의 스냅샷 이라는 보장을 할 수 없다.
– 문서 개수
샤딩된 컬렉션에서 count 수행시 상황에 따라 다른 결과를 얻을 수 있다.
–Mongos 는 count 명령을 각 샤드에 전달하고 mongos는 이들을 합산한다. 만약 이때 데이
터 이동이 발생하면 다른 결과가 나타날 수 있다.

왜 이런 결과를 얻게 될까?

 고유 색인
– 샤드키를 제외한 다른 키에 대해서는 유일성을 보장할 수 없다.
– 입력되는 문서는 청크하나에만 전달될 수 있으므로 그 청크가 저장된 샤드에서만 유일성을 보장 받
으면 됨.
따라서 전체 클러스터에서 유일성을 보장할 수 있다.
 갱신
– 갱신 작업은 단 하나의 문서만 변경하는것이 기본 설정
– 클러스터 환경에서는 update 메소드의 인수에 샤드키를 지정 해야 한다.
– 만약 갱신 명령이 여러개의 문서를 변경하는 일을 허용하면 이러한 제약은 없어진다.

맵리듀스

 클러스터 환경에서 맵리듀스를 실행하면 각 샤드에서 자신의 맵과
리듀스 연산을 수행한다.
– 샤드가 작업을 여러개의 장치로 분산시켜 주기 때문에 단일 서버보다는 빠르지만, 실시간 처리
는 불가능 하다.

임시 컬렉션
– 1.6 버전에서는 맵리듀스 수행시 “out” 옵션을 설정하지 않으면, 생성된 임시컬렉션은 이를 생
성한 연결이 끊기면 자동 삭제
단일 서버는 잘 작동 하지만 mongos 가 connection pool을 관리하는 클러스터 환경에서는 임시 컬렉션이
삭제 되지 않아 수동으로 삭제 해 주어야 한다.
– 이후 버전에서는 맵리듀스를 수행할 때 결과값을 저장할 컬렉션을 필수로 받고 있
다.

셸 사용하기

 요약 정보 보기
– clb.printSharclingStatus()
 클러스터 운용에 관한 요약 정보를 볼 수 있다. 이 멍 령은 클러스터 에 관해 중요한 모든 정보를 수집 해서
보기 편한 형 태로 표시해준다
– > db.printShardingStatus()
– sharding version: { .,id" 1, "version" 3 } shards
– --- Sharding Status ---
– { " id"
– 닝hard0000", 개ost"
– “ubuntu:27017" }
– {" databases
– id" 닝hard0001", "host" "ubuntu:27018" }
– { " id" "admin",
– "partitioned“ false, '’prlmary" "config" }

– 알수 있는 정보
모드 샤드
데이터베이스 목록
샤딩된 컬렉션 목록
청크의 분산된 모습
개별 청크에 대한 정보 및 범위
주샤드

셸 사용하기

 config.mongos
– Mongos 프로세스 일람 (ping)
 config.shards
– 클러스터에 저장된 모든 샤드
 config.database
– 모든 데이터 베이스 (샤딩 여부 관계없이)
 config.collections
– 샤딩된 모든 컬렉션
 config.chunks
– 클러스터에 저장된 모든 청크
 config.setting
– 주요 시스템 설정
db.settings‘update({"_id":“balancer“!. {"$set":{"stopped":true !!. true)
–벨런서 작동 중지
 config.changelog
– 청크를 분할하고 이동할때 마다 기록된다.
– 클러스터가 현재 상태가 되기까지의 기록

모니터링

 네트워크 자원은 항시 중요한 관리 포인트
– 가능하면 클러스터에 접속되어 있는 쉘을 하나 정도 유지 할 필요가 있음
 mongostat
– Page fault 에 의한 부하 체크
– 접속된 연결수

클러스터 운영시
– mongos에서 mongostat --discover를 실행하는 방법
클러스터의 모든 구성원을 감시한다
Web 관리 도구
–http://localhost:28017/_replSet

백업

 벨런서의 작동으로 인해 특정 청크가 이동하고 있는 시점에서의 백
업본의 복구는 특정 청크의 자료를 잃어 버리게 할 수 있다.

시스템 구성 제안

 mongodb 클러스터와 관계 없는 별도의 시스템 구성을 가진 정적
사이트 또는 다른 mongo db 클러스터를 준비해야 한다.

 mongodb 클러스터로의 접근을 하나의 큐를 통해서 처리한다
– 입력과 출력을 모두 캐싱하여 안정성을 도모

샤드 자체가 다운된 경우
– 여러개의 샤드로 분산된 데이터를 질의 하는 경우 일부 샤드가 다운되어 결
과셋에 오류가 나오는 경우를 application 개발시 대비해야 한다.

 샤드 구성원 대부분이 다운된 경우
– 레플리카 셋에서 구성원 과반수가 다운되면 읽기 전용으로 전환된다.
주 서버를 선출 할 수 없기 때문에

시스템 구성 제안

 설정 서버가 다운된 경우
– 클러스터 성능에 즉각적인 영향은 없다.
– 하지만 클러스터 설정 변경이 불가능.
– 바로 복구 해야 한다.

 mongos 프로세스가 다운된 경우
– Application server 당 하나의 monogos 수행
– Application server 는 자신의 local mongos 와 통신 수행하도록 함
– 장치가 다운 되더라도 해당 장치의 mongos 도 같이 다운 되므로 다른 클
러스터에서 교신 하지 않음.
– 단 application server외부에 여분의 mongos를 설치하여 mongos
process 자체의 다운을 대비하자.

 그밖에 고려할 점
– Mongodb 는 많은 문제가 누적되어도 가능한 기능을 정지하지는 않는다.
– 모든 외부 상황(네트웍 분할등)을 고려해서 트러블 슈팅을 고민해야 한다.

Mongodb cluster

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Mongodb cluster (20)

Mongodb cluster

Editor's Notes