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 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들