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 -
'Technical > DBMS' 카테고리의 다른 글
mongodb ttl collection 사용에 관하여(pymongo 추가) (0) | 2012.11.10 |
---|---|
Silent mode Oracle 11gr2 설치 - CentOS 5.5 x64, cloudn VM에서 (0) | 2012.09.25 |
HammerOra로 DBMS 성능 측정하기(TPC-C) -2 (2) | 2012.09.14 |
HammerOra로 DBMS 성능 측정하기(TPC-C) -1 (0) | 2012.09.05 |
mysqld: Table './mysql/proc' is marked as crashed and should be repaired (0) | 2012.08.20 |