MongoDB를 백업하는 방법에는 Journaling을 지원하는 Block 장치일 경우 snapshot, lock & fsync, mongodump & mongorestore 등의 여러 가지가 있다. mongo.org 에 의하면 증분 백업(incremental backup)을 지원하지는 않고 있으며, 아직까지 이러한 기능을 수행하는 도구 또한 존재하지 않는 상황이다.


데이터베이스 엔진이 중단되지 않아야 하는 상황의 경우 dump & restore를 통한 방법이 일반적이므로 아래에 그 사용법에 대해 정리해 둔다. 이 방식은 쉽게 표현하자면 단순히 레코드 단위로  백업(dump)을 받고, 복구시에도 레코드 단위로 insert를 반복적으로 수행하게 된다.


[mongodump]

# 전체 데이터베이스 Full backup

/mongo/bin/mongodump --out /mongobackup/20120901 --oplog --host 10.10.0.10 --port 28017 -uuser -ppass


* 특정 데이터베이스 스키마만 백업할 경우에는 --db dbsname 옵션을 사용한다.

* --oplog 옵션은 백업이 진행되고 있는 도중에 발생한 트랜잭션에 대한 데이터를 별도로 처리하여 누락되는 백업데이터가 없도록 해 주는 기능이다.

* 백업이 끝나면 /mongobackup/20120901 디렉토리에 각 데이터베이스 스키마별로 서브디렉토리가 생성되어 컬렉션별로 .bson 파일들이 생성된다.

* 용량과 서버 성능에 따라 수십분 내지 수시간이 걸릴 수 있으며, 백업되는 디스크의 용량도 수백GB 또는 수TB까지도 사용 가능하여야 할 수도 있다.


[mongorestore]

# 전체 데이터베이스 Full restore

/mongo/bin/mongorestore --host 10.10.0.10 --port 28017 -uuser -ppass --oplog --drop  /mongobackup/20120901/


* 특정 데이터베이스 스키마만 복구하려면 아래와 같이 수행한다. 백업디렉토리의 하위 디렉토리 위치에 대상 데이터베이스명을 정확히 기입하여야 한다.

/mongo/bin/mongorestore --host 10.10.0.10 --port 28017 -uuser -ppass --drop --db dbname /mongobackup/20120901/dbname/


* --drop 옵션은 복구시에 해당 컬렉션을 삭제하는 방식이다. 즉 복구시에 동일한 컬렉션이 존재할 경우 컬렉션을 초기화하고 dump된 데이터만을 채워 넣으므로, dump 이후에 저장된 데이터는 소실됨을 의미하므로, 데이터베이스 전체를 dump된 시점으로 되돌릴 때 사용한다.

*  데이터베이스 개별 복구일 경우 --oplog 옵션은 적용되지 않는다.

 


- Barracuda -


블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


Mongo DB를 사용한 Replication은 그 조합과 목적에 따라 여러 가지 구조로 구현된다. Master-Slave 이중화 및 다중화, Master-Master 이중화, Master-Master Circular 구조의 다중화, Cluster 기술이 적용된 Replica Set 등, ... 결국은 데이터베이스의 고가용성을 갖추기 위한 목적은 같지만 말이다.

가장 대표적이고 단순한 것은 Master-Slave이다. 이를 통해서 Data redundancy는 구현되지만, Fail-over 문제, 자원의 비효율적 사용 때문에 Master-Master 구조를 선호하는 것이 일반적이다. 또한 그 구조도 비교적 단순하며 Fail-over 를 통한 Availability 뿐 아니라 Read/Write 부하의 분산의 측면에서 아직까지 중/소규모 데이터 처리시에 효과적으로 활용될 수 있다. 물론 Database의 앞 쪽에 Load Balancer가 있어, 양쪽으로 부하를 분산해 줄 수 있을 경우 또는 드라이버나 Application 에서 Fail-over에 대응하는 접속 설정이 가능할 경우에 해당된다.

이 방식에서의 치명적인 단점은 바로 운영의 부담이 크다는 것이다. 데이터를 양쪽 노드에 모두 쓰기가 가능함으로 해서, Fail-over의 혜택을 누렸지만, 이를 복구한 이후에 재 투입을 할 경우, 짧은 순간이지만, 각 노드가 Master 이면서 Slave 이기 때문에 살아 있던 Master의 replication 옵션을 바꾸어서 장애 복구한 노드를 재 투입하여 Replication을 하고, 정상적으로 Replication될 경우 다시 한번 양 쪽의 raplication 옵션을 Master-Master 바꾸어서 재실행하여야 한다.

10Gen 에서는 MongoDB 초창기(1.4?) 부터 Master/Slave Replication 의 단점을 보완하고자 지금은 없어진 Replica Pair, Replica Set 기능을 개발 해 왔고 1.6.* 이후 부터 본격적으로 안정된 Replica Set 기능을 제공하고 있다. 즉 2대 이상의 서버를 이용해 Master-Slave(1:n) 구조로Data를 복제하여 저장하되, 정상 상황에서 하나의 Primary만 존재하여 작동하되, Primary에 문제가 생길 경우 Slave 중의 하나를 Primary로 선정(vote)하여 Master 기능을 넘겨 받는 구조이다.


[주의] 
모든 경우에 Replica Set이 만능은 될 수 없다. mongos와 Config server를 사용하여 쓰기 부하를 분산하도록 해야 하며, Master-Slave 이중화 구성에서 Replica Set으로 이전하려면, Application 측의 driver 를 변경하여 Primary 노드를 찾아가도록 하는 추가적인 노력이 필요한 점에 유의하여야 하며, 기존의 이중화 구성에서 사용한 Load Balancer의 설정 방식에도 변화를 주어야 한다. 하지만 한 번 적용해 놓으면 트리 구조의 단순성과 추가 노드 투입(확장성)또는 장애 대처의 편리성(운영 편의), 거의 100%에 가까운 가용성 때문에 중 대규모 데이터를 처리하고자 하는 환경인 경우에 지극히 효과적인 장점을 보이는 것은 분명하다.


블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


mongo db는 몽고 라는 나라와 전혀 상관이 없다. Humongous 하는 단어에서 만들어진 것.

설치후 아무런 제약 없이 ./mongo 만 치면 db에 접속된다. 개발환경이라면 문제 없지만
개념 없이 쓰다가 큰 일 ㅡ_-? 이 날지도...

우선 mongod를 기동시킬 때 --auth 옵션을 추가해 두자.
다음 글에서 mongod 를 시스템 스타트시에 기동되도록 설정하는 방법을 정리할 것이다. ubuntu, centos, suse 등
거의 모든 linux 머신에서 특정 App을 기동시키는 일반적인 방법이 되겠다.

각설하고,
mongo db는 system 영역 내에 admin 이라는 DB 관리를 위한 스키마 영역(database)를 가진다.
* 메서드 Name에 대소문자 구분 주의
# ./mongo
# use admin
# db.addUser( "adminname", "adminpassword" )
이제 관리자로 접근하려면
# db.auth( "adminname", "adminpassword" )
라고 입력해야만 DB를 use 할 수 있다.

* 이제 DB를 관리하기 위해서는 반드시 아래와 같이 해야만 정상적으로 접속되고 user 생성 등을 할 수 있다.
# mongo -uroot -padminpassword --port 12345 admin

# db.system.useres.find() => users 테이블 내용을 select

일반적인 작업 영역을 위해 별도의 DB를 만들고 권한을 설정하려면
# use newdb => mongo는 newdb가 없으면 자동으로 생성한다. table(collection이라고도 한다)이나
                        key(attribute, column)에 대해서도 마찬가지. 즉, DDL이 따로 없다. C/C++의 structure
                        구조와 같은 composite한 다중 컬럼도 생성이 가능하므로 자칫하면 table 구조가 엉망이 될
                        수도 있다.
# db.addUser( "newdbuser", "newpassword" )
이제 newdb 데이터베이스로 접근하려면
# db.auth( "newdbuser", "newpassword" ) 로 접근할 수 있다.

* 데이터베이스마다 owner 개념으로 접근 계정을 각각 할당하는 방식에 유의 !!!

이제 데이터베이스에 접속하려면  아래 방법들 처럼 접속이 가능하다
# mongo -unewdbuser -pnewpassword newdb --port 27017 --host 100.100.100.20
# mongo -uroot -padminpassword --port 29007 newdb
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들