여러분이 MongoDB 를 도입하려 사용하려고 한다면 주변에서는 한번 말릴 것이다. 의심의 눈초리로 “MongoDB 가 DB가 깨질 수 있다는데 안전한가요?” 이러한 질문들을 많이 들어봤다.
결론적으로말하자면 깨질 수 도 있다. 하지만 복구가 가능하다. 다른 데이터베이스도 깨질 수 있지 않는가 하는 것이 필자의 생각이다. 한가지 예를 들면 MySQL 이 깨질 수도 있는 것이다. 물리적인 손상은 어쩔 수 없는거 아닌가? 하는 것이다.
물론 예전 버전에서는 안정성이 낮았지만 현재의 버전, 특히 WiredTiger 엔진에서는 안정성이 대폭적으로 좋아졌기 때문에 깨질 확률이 그렇게 많지는 않다는 것을 말하고 싶다.
기본적으로 데이터베이스의 백업은 주기적으로 (최소 Daily) 하는 것이 원칙이며, 시스템이 다운되거나 물리적 손상이 있어서 복구가 못하게 되는 순간이 오면 백업해 놓은 백업으로 복구하는 것이 일반적인 복구 절차이며, 이는 모든 데이터베이스 시스템에서 동일하게 적용되는 것이다.
MongoDB 서비스가 가동중에 갑자기 전원을 끈다면, mongod 실행시에 –repair 옵션을 써서 복구를 진행해야 할 것이다. 아직 물리적인 손상으로 인하여 MongoDB를 재가동 시키지 못한 경우는 없지만, 대부분은 –repair 옵션으로 복구가 가능할 것이다.
MongoDB 라고 하여 안정성이 낮다고 하는 것은 “기우이다”라는 것을 말하고 싶다.
그럼 접근 방법을 달리하여 아에 안정적으로 구동될 수 있는 시스템을 구성한다면 어떨까 하는 것이다.
이 때 사용하는 것이 Replication이다.
Master / Slave 라고도 하며 Primary / Slave 라고도 하는 이 구조, (MongoDB 에서는 Primary / Slave) 로 표현한다.
대부분의 DB에서 지원하며 , 안정성을 위해 데이터베이스를 복제하며, 한쪽 데이터베이스가 구동되지 않은 상태라고 하더라도, 다른 나머지 데이터베이스 중 하나가 그 역할을 대신할 수 있게 하는 방법이다.
MongoDB에서는 보통 3개로 된 Replica set(복제셋) 을 사용하며 Master , Slave 2개로 구성한다.
그리고 이 3개의 Replica set 으로 구성되면 상시 구동되는 데이터베이스를 만들 수 있다.
만약 시스템 중 한곳에서 물리적인 업그레이드를 한다거나해서 시스템을 리부팅을 시킬 필요가 있을 경우에도 그냥 작업을 하고 다시 구동을 하면 자동적으로 그 중지되어 있던 상태의 데이터 값을 다른 데이터베이스에서 복제해 오게 된다. (정말 아무런 작업을 안해줘도 다시 살아난다.)
따라서 중단 없이 운영을 해야 하는 시스템에는 이 Replica set이 필수라고 할 수 있겠다.
Replica set 을 구성해서 좋은점 중 한가지를 소개하면, 만약 통계 프로그램을 구동시킬 때 부하가 많이 걸리게 될 것이다. 이것을 Slave 데이터베이스에 연결하여 작업을 하면 실 서비스에 영향을 받지 않으면서 통계를 낼 수 있다. 안정적으로 운영하면서도 통계가 필요할 경우 적합한 사용방법이라고 할 수 있겠다.
다음 챕터에는 이 Replica set 을 직접 만들어 보는 방법을 안내하겠다.