[MongoDB] 백업 및 복구(1)

 

mongodump 와 mongorestore 를 이용한 논리 백업 및 복구

백업

mongodump 는 공식적으로 제공되는 유일한 백업 도구인데, 논리적인 수준의 백업을 실행하는 도구이다.

즉 물리적인 파일을 복사하는게 아니라 서버에 로그인 후 도큐먼트를 한건씩 덤프해서 bson 파일로 저장하는 방식이다.

 

그래서 mongodump 는 백업 시간뿐 아니라 복구 시간도 상당히 오래 걸린다.

mongodump 는 기본적으로 특정 시점의 스냅샷을 덤프하지 않는다.

즉, mongodump 도구가 데이터를 덤프하는 동안 변경되는 데이터에 대해서는 백업이 일관된 상태를 유지하지 못한다.

그래서 mongodump 를 이용해 백업하는 경우 --oplog 옵션을 이용해서 실행해야만 덤프가 실행 중인 동안 변경되는 데이터의 OpLog 이벤트를 같이 백업할 수 있다.

 

특정 시점의 일관된 상태를 백업하려면 --oplog 옵션을 사용해야 하지만, MongoDB 라우터를 통해서 mongodump 백업을 수행하는 경우 --oplog 옵션을 사용할 수 없다.

그래서 --oplog 옵션으로 스냅샷 백업을 실행할 때는 MongoDB 서버에 직접 로그인해서 백업을 수행해야 한다.

 

백업이 실행되면 --out 파라미터에 지정한 디렉터리로 덤프한 BSON 도큐먼트를 기록하고,

덤프가 실행되는 동안 OpLog 이벤트를 덤프해서 "oplog.bson" 이라는 덤프 파일을 출력디렉터리에 기록한다.

 

백업이 완료되면 각 데이터베이스의 컬렉션이 디렉터리 단위로 저장되고 OpLog 의 내용이 덤프돼서 oplog.bson 파일로 저장된 것을 확인할 수 있다.

 

복구

mongodump 를 이용해 백업된 데이터 파일을 복구하는 방법은 mongorestore 명령어를 사용하면 되며 매우 간단하다.

--oplogReplay 옵션은 덤프된 데이터 파일을 모두 적재한 후에 백업 디렉터리의 oplog.bson 파일을 적재하도록 해주는 옵션인데, oplog.bson 파일은 --oplog 옵션을 사용해서 mongodump 를 실행한 경우에만 생성되는 파일이다.

 

그래서 만약 mongodump 로 백업하면서 --oplog 옵션을 주지 않았다면 --oplogReplay 옵션은 사용하면 안된다.

 

mongorestore 명령이 완료되면 백업된 시점의 데이터베이스 상태로 복구시켜준다.

물론 mongodump 명령은 local 데이터베이스의 컬렉션은 별도로 백업하지 않기 때문에 백업을 수행했던 서버와 다른 상태일 수 있으나, 사용자 데이터를 저장하는 데이터베이스가 아니고 서버 시작에 아무 문제가 없으니 무시해도 된다.

 

Mongodump 로 ㅐㅂㄱ업된 데이터로부터 일부 데이터베이스나 컬렉션만 적재하고자 한다면 --nsInclude 나 --nsExclude 옵션을 사용하면 된다.

그리고 백업 디렉터리에서 특정 데이터베이스의 데이터를 다른 데이터베이스나 컬렉션으로 적재하고자 한다면 --nsFrom 과 --nsTo 옵션을 활용한다.

 

mongorestore 를 빠르게 실행하고자 한다면 --numParallelCollections 옵션을 활용하면 되고 기본값은 4로 4개의 쓰레드를 이용해서 데이터를 적재한다.

 

 

물리 백업 및 복구

셧다운 상태의 백업

가장 간단한 방법은 서비스에 투입되지 않은 세컨드리 멤버의 MongoDB 서버를 셧다운하고 데이터파일을 복사하는 방법이다.

그렇지만 셧다운 하는 경우 장애가 발생하면 새로운 프라이머리 선출을 하지 못할 수 있으므로 MongoDB 레플리카 셋의 고가용성을 고려해야 한다.

그래서 만약 셧다운 한 후 백업을 수행하고자 한다면 백업 전용의 새로운 멤버를 추가해서 진행할 것을 권장한다.

 

복제 중지 상태의 백업

공식적으로 복제를 멈추는 방법은 없기 때문에, db.fsyncLock 명령을 이용해 데이터 파일을 복사한다.

완료 후 db.fsyncUnLock 을 활용해 잠금을 해제해야 한다.

 

fsyncLock 명령을 이용하는 경우에도 복제가 동기화되지 않으므로 복제는 지연된 상태이며, 백업이 실행되는 동안 지연된 복제로 인해 새로운 프라이머리 멤버로 선출되지 못하거나 복제 동기화를 위해 매우 오랜 시간이 소요될 수 있다.

 

파일시스템 스냅샷 백업

리눅스의 LVM 과 같이  파일 시스템 레벨에서 지원하는 스냅샷 기능을 이용해 물리 백업을 수행할 수도 있다.

 

Percona 온라인 백업

Percona 에서는 위의 번거로움과 어려움을 해결하기 위해 온라인 백업 기능을 구현했는데,

이 기능을 사용하려면 Percona 에서 배포하는 Percona Server for MongoDB 배포판을 사용해야 한다.

 

물리 백업 복구

물리적으로 백업된 데이터 파일은 운영 중인 MongoDB 서버의 데이터 디렉터리 구조와 컬렉션의 데잍 ㅓ파일을 그대로 가지고 있기 때문에 복구가 매우 간단하다.

복구하고자 하는 MongoDB 서버의 데이터 디렉터리에 백업된 데이터 파일을 그대로 복사하기만 하면 된다.

 

만약 샤딩된 MongoDB 클러스터에서 백업된 데이터 파일을 이용해서 복구하는 경우에는 백업된 데이터 파일을 사용해서 시작되는 MongoDB 서버가 아무런 응답도 없이 무한정 대기에 빠질 수 있다.

이는 백업을 실행했던 원본 MongoDB 서버가 소속된 클러스터의 구조를 확인하기 위해 컨피그 서버로 접속하려 하기 떄문이다.

이런경우recoverShardingState 옵션을 false 로 설정하면 기존 샤드 클러스터 컨피그 서버 정보를 무시하고 서버를 시작한다. ( 3.6 버전부터 옵션 삭제 됨 )

 

PIT 복구 ( Point In Time )

잘못 실행된 명령 직전까지의 데이터를 복구하는 것을 PIT 복구라고 한다.

MongoDB 에서 PIT 복구는 물리 또는 논리 풀 백업의 최근의 OpLog 를 복구하는 방식으로 진행된다.

 

이 절차는 백업 시점으로부터의 OpLog 를 가진 멤버가 있어야만 가능하다.

우선 복구한 백업의 OpLog 시점을 확인하기 위해 서버에 로그인해서 local 데이터베이스의 oplog.rs 컬렉션의 가장 마지막 이벤트를 확인한다.

이제 가장 최근까지의 OpLog 를 가진 MongoDB 서버에서 OpLog 를 덤프한다.

이 때 전체 OpLog 를 덤프하는 것이 아니라, 백업의 마지막 OpLog 이벤트부터 덤프하도록 한다. * 이렇게 안해도 복구에는 무관

 

이제 덤프된 OpLog 에서 삭제한 이벤트의 시점을 찾아야 하는데 BSON 파일이어서 사람의 눈으로 확인이 불가능해 JSON 파일로 변환한다.

JSON 으로 변환된 데이터에서 복구시점 ts 를 찾는다.

 

Oplog 재생을 위해 mongorestroe 명령을 사용하는데, 이 때 백업 데이터 파일이 저장된 디렉터리에는 덤프 받은 oplog.bson 파일만 있어야 한다.

그렇지 않고 다른 데이터베이스의 컬렉션 덤프 파일이 있으면 이 데이터 파일들도 기존 컬렉션에 다시 적재되어서 데이터가 이중으로 적재될 수도 있다.

 

또한 mongorestore 명령으로 OpLog 를 재실행할 때에는 --oplogReplay 옵션을 사용해야 하며, 재생을 멈춰야 할 OpLog 이벤트 지점을 --oplogLimit 옵션에 같이 지정해야 한다.