MongoDB 활용가이드TIP 35 ~ TIP 41

TIP 35 w를 사용할 때는 항상 wtimeout을 같이 사용하라.서버 3개의 레플리카셋(주 서버 한 대 와 부 서버 두대)에서동기화 보장

> db.runCommand({"getlasterror" : 1, "w" : 2})

이 때, 부 서버 다운시 무한정 응답을 기다리게됨.

> db.runCommand({"getlasterror" : 1, "w" : 2, "wtimeout" : 100})

timeout 시간이 지나면 실패로 간주

부서버 동기화로 시간이 많이 걸릴 수 있음.  그림 10-3

TIP 36 쓰기 연산마다 fsync를 수행하지 말라.

이유 : 속도 엄청 느려짐.

fsync 사용은 가급적 삼가

fsync : flush가 수행되기를 기다렸다가 저널에 기록된 것을 확인 후 성공여부 반환. 프로그램을 대기하게 만듦.

단, 중요한 데이터가 저널에 씌어질 것을 보장받고 싶다면 사용. - 저널링을 할 때만.

TIP 37 서버가 멈추었을 때는 보통의 방법으로 재시작하라.

저널링 사용 중, 복구 가능한 시스템 다운인 경우 MongoDB를 일반적인 방법으로 재시작하면 됨.

이 경우 모든 일반적인 옵션을 사용하여야 함. --dbpath (저널 파일을 찾을 수 있도록)--journal

재시작시에 외부에서의 접속 허용 전에 자동으로 데이터를 고치게 됨. 

저널 파일은 journal 디렉토리에 저장되어있음. 삭제하지 않도록 주의.

TIP 38 서버의 순간적인 백업을 만들 때

단순히 모든 파일을 그냥 복사하면 안됨.

이유 : 저널을 복사하는 시점과 데이터베이스를 복사하는 시점이 다르기 때문.

복원시에 저널 파일이 데이터 파일을 손상시킬 수 있음. 다른 시점의 데이터로 인식하게 되기 때문...

추천방법1 - 파일시스템 스냅샷추천방법2 - fsync + lock 조합 수행 후 dump

TIP 39 청크컬렉션은 수동으로 삭제하라

GridFS는 파일의 (이진)데이터를 fs.chunks 컬렉션에 저장파일의 이름 및 다른 데이터는 fs.files 컬렉션에.

fs.chunks에 저장된 후 fs.files 가 씌어지기 전에 DB가 다운되면 fs.chunks 와 fs.files의 연결이 없는 고아 chunk가 생기게 됨.

이때, 가끔 서버 유휴기동안 직접 삭제해주자.

TIP 40 repair 명령을 통해 데이터베이스를 밀도있게 관리하라

repair 디스크 조각모음 ( mongodump와 mongorestore를 실행)

repair 명령은 연산수행을 멈추고 진행하므로 주서버에서는 X부서버로 다운시키고 진행

DB용량의 두배공간이 확보되어야 실행가능.

이런 제약을 만족 repair를 실행하는 대신 mongodump와 mongorestore를 수동으로 실행할 수 있음.

TIP 41 레플리카 셋 구성원 표 수를 변경하지 말라

주서버 선출할 때의 우선 순위.

1.9.0 버전 이전- 우선순위는 1, 0 둘 중의 하나로만 지정

1.9.0 버전부터- 다양한 수를 지정할 수 있음.- 다양한 환경에서 특정 서버들이 주 서버가 되도록 설정 용이

서버의 투표권을 늘려주면 그 서버는 선거에서 당선될 가능성 높아진다는 의견이 있지만, 서버들은 의외로 이기적이지 않아서 효과 없음.