[10장] 복제 셋 설정

1. 복제 소개

• 1장부터 지금까지 시작하기 쉽도록 독립 실행형 서버인 단일 mongod 서버를 사용해 왔지만 실제 서비스를 운영하는 데 사용하면 매우 위험한 방식
  • 만약 서버가 고장이 나거나 이용 불가능한 상태가 될 경우 적어도 잠시 동안은 DB를 사용할 수 없을 것
  • 최악의 경우에는 디스크나 네트워크 문제가 데이터 손상이나 접근 불가 문제를 야기할 것

 

• 복제는 데이터의 동일한 복사본을 여러 서버상에서 보관하는 방법이며 실제 서비스를 배포할 때 권장되는 방식
  • 한 대 또는 그 이상의 서버에 이상이 발생하더라도, 복제는 애플리케이션이 정상적으로 동작하게 하고 데이터를 안전하게 보존해 줌
  • 복제를 사용하는 상태에서 서버가 다운되면, 복제 셋에 있는 다른 서버를 통해 데이터 접근 가능
  • 서버상의 데이터가 손상되거나 접근할 수 없는 상태라면 복제 셋의 다른 멤버로부터 새로운 복제 데이터 생성 가능

 

• 몽고DB를 사용하면 복제 셋을 생성함으로써 복제를 설정 가능
  • 복제 셋은 클라이언트 요청을 처리하는 Primary 서버 한 대와, Primary 데이터의 복사본을 갖는 Secondary 서버 여러 대로 이루어짐
  • Primary 서버에 장애가 발생할 경우 Secondary 서버는 자신들 중에서 새로운 Primary 서버를 선출할 수 있음

 

2. 복제 셋 설정 - 1장

이 장에서는 복제 셋 메커니즘을 실행할 수 있도록 단일 장비에 3-노드 복제 셋을 설정하는 방법을 보여줍니다.

• 해당 설정 유형을 통해 몽고DB가 고가용성 및 재해 복구를 처리하는 방법을 이해 가능
• 운영 환경에서는 항상 복제 셋을 사용하며, 각 멤버에 전용 호스트를 할당해 리소스 경합을 방지하고 서버 오류에 대한 격리를 제공해야 함
• 추가적인 복원력을 제공하려면 DNS Seedlist 연결 형식을 사용해 애플리케이션이 복제 셋에 연결하는 방법을 지정해야 함
  
  • DNS를 사용할 경우 몽고DB 복제 셋 멤버를 호스팅 하는 서버를 클라이언트 재구성 없이 돌아가면서 변경할 수 있다는 장점이 있음

 

테스트 복제 셋을 시작하기에 앞서 각 노드에 대해 별도의 데이터 디렉토리를 생성합니다.

• 리눅스나 맥 OS에서는 터미널에서 다음 명령을 실행해 세 개의 디렉토리를 생성 가능
• 아래 명령은 ~/data/rs1, ~/data/rs2, ~/data/rs3 디렉토리가 생성됨

 

$ mkdir ~p ~/data/rs{1,2,3}

 

다음으로 리눅스나 맥 OS에서 다음 명령을 각각 별도의 터미널에서 실행합니다. 

 

 

명령을 실행했다면 세 개의 별도 mongod 프로세스가 실행돼야 합니다.

 

3. 네트워크 고려 사항

• 복제 셋의 모든 멤버는 자기 자신과 같은 셋 내 다른 멤버와 연결할 수 있어야 함
  • 만약 이미 작동 중인 다른 멤버에 연결할 수 없다는 오류가 발생할 경우 연결이 이루어지도록 네트워크 구성을 변경해야 함

 

• 시작한 프로세스는 별도의 서버에서 쉽게 실행 가능하지만 몽고DB 3.6이 출시되면서 mongod는 기본적으로 localhost에만 바인딩되는 제약조건이 생김
  • 따라서 복제 셋의 각 멤버가 다른 멤버와 통신하기 위해서는 다른 멤버가 연결할 수 있는 IP 주소에도 바인딩해야 함
  • ex) IP 주소가 198.51.100.1인 네트워크 인터페이스가 있는 서버에서 mongod 인스턴스를 실행 중일 때 인스턴스를 각기 다른 서버의 멤버와 함께 복제 셋의 멤버로 실행하려면, 명령행 매개변수 --bind_ip를 지정하거나 인스턴스 구성 파일에 있는 bind_ip를 사용해야 함

 

$ mongod --bind_ip localhost,192.51.100.1 --replSet mdbDefGuide --dbpath ~/data/rs1 --port 27017 --oplogSize 200

 

4. 보안 고려 사항

• localhost 이외의 IP 주소에 바인딩하기 전 복제 셋을 구성할 때, 권한 제어를 활성화하고 인증 메커니즘을 지정해야 함
• 또한 디스크의 데이터를 암호화하고, 복제 셋 멤버 간 통신 및 셋과 클라이언트 간 통신을 암호화하는 것을 권장

 

5. 복제 셋 설정 - 2장

• 지금까지 수행한 작업으로는 아직 각 mongod가 다른 mongod의 존재를 알지 못함
  • 각 멤버를 나열하는 구성을 만들어 mongod 프로세스 중 하나로 보내면 멤버들은 서로의 존재를 알 수 있음
  • 구성을 전달받은 프로세스는 이를 다른 멤버들에 전파함

 

네 번째 터미널에서 실행 중인 mongod 인스턴스 중 하나에 연결하는 mongo 셸을 시작하는 명령어는 아래와 같습니다.

• 명령은 포트 27017에서 실행 중인 mongod에 연결시킴

 

$ mongo --port 27017

 

그런 다음 mongo 셸에서 구성 도큐먼트를 생성하고 rs.initiate() 보조자에 전달해 복제 셋을 시작합니다.

• 그러면 세 개의 멤버가 있는 복제 셋이 시작되며 구성을 나머지 mongod들에 전파해 복제 셋이 형성됨

 

 

복제 셋 구성 도큐먼트에는 몇 가지 중요한 부분이 있습니다.

• 구성의 "_id"는 명령행에 전달한 복제 셋의 이름
• 도큐먼트의 다음 부분은 셋 멤버의 배열
  • 각 멤버에는 두 개의 필드 "_id"와 호스트명이 필요
  • "_id"는 정수이며 복제 셋 멤버 간에 고유해야 함

 

• 이 구성 도큐먼트는 복제 셋 구성
  • localhost:27017에서 실행 중인 멤버는 구성을 구문 분석하고 다른 멤버들에 메시지를 보내 새 구성을 알림
  • 멤버들은 구성을 모두 로드한 뒤 기본 구성을 선택하고 읽기 및 쓰기 처리를 시작함

 

새로운 셋을 시작한다면 셋 내 어떤 멤버로든 구성을 보낼 수 있습니다.

• 한 멤버에 있는 데이터로 셋을 시작하려면 해당 데이터를 갖는 멤버로 구성을 보내야 함
• 둘 이상의 멤버에 대한 데이터로 복제 셋을 시작할 수 없음

 

시작하고 나면 완전히 기능하는 복제 셋이 있어야 합니다.

• 복제 셋은 Primary를 선출해야 함
• 복제 셋의 상태는 rs.status()를 사용해서 확인 가능한데, 출력은 복제 셋에 대해 꽤 많은 것을 알려줌
• 아직 다루지 않은 필드가 많으므로 지금은 우선 members 배열을 살펴보는 것으로 시작
  • 배열에 세 개의 mongod 인스턴스가 모두 나열되며, 그중 하나가 Primary로 선출됨
  • 나머지 두 개는 Secondary

 

 

6. 복제 관찰

복제 셋이 포트 27017에 있는 mongod를 Primary로 선출했다면, 복제 셋을 시작하는 데 사용된 mongo 셸이 현재 Primary에 연결돼 있습니다.

• "_id"가 "mdbDefGuide"인 복제 셋 Primary에 연결됐음

 

mdbDefGuide:PRIMARY>

 

복제 셋이 다른 노드를 Primary로 선출했다면, 셸을 종료하고 이전에 mongo 셸을 시작할 때 했던 것처럼 명령행에서 올바른 포트 번호를 지정해 Primary 노드에 연결합니다.

• i.g. 셋의 Primary가 포트 27018에 있으면 다음 명령을 사용해 연결

 

$ mongo --port 27018

 

이제 Primary에 연결됐으므로 쓰기를 시도해 보고 어떤 일이 벌어지는지 확인 가능합니다.

 

이제 Secondary 중 하나를 확인해 모든 도큐먼트의 사본이 있는지 확인 가능합니다.

• 셸을 종료하고 Secondary의 포트 번호를 사용해 작업 수행 가능
• 하지만 실행 중인 셸 내에서 Mongo 생성자를 사용해 연결 객체를 인스턴스화할 경우 Secondary에 대한 연결을 쉽게 얻을 수 있음

 

먼저 Primary의 test 데이터베이스에 대한 연결을 사용해 isMaster 명령 예제를 실행하겠습니다.

• 이는 rs.status() 보다 훨씬 더 간결한 형태로 복제 셋의 상태를 보여주며 애플리케이션 코드를 작성하거나 스크립팅할 때 어느 멤버가 Primary인지 판별하는 편리한 방법
• 어느 시점이든 선출이 호출되고 연결돼 있던 mongod가 Secondary가 되면 isMaster 명령을 사용해 어느 멤버가 Primary가 됐는지 확인 가능

 

다음 출력은 localhost:27018과 localhost:27019가 둘 다 Secondary이므로 용도에 따라 둘 중 하나를 사용할 수 있음을 알려줍니다.

• 아래 예제는 localhost:27019에 대한 연결을 인스턴스화함

 

이제 Secondary로 복제된 컬렉션에 읽기를 시도하면 오류가 발생합니다.

• 컬렉션에서 find를 시도하면 왜 오류를 얻었는지 알 수 있음
• Secondary는 Primary보다 뒤처지며 데이터가 최신이 아닐 수 있기 때문에 애플리케이션이 실수로 실효 데이터를 읽지 않도록 읽기 요청을 거부함
• 따라서 Secondary를 쿼리 하려고 하면 Primary가 아니라는 오류가 표시됨

 

Seconary에 대한 쿼리를 허용하려면 다음처럼 `Secondary에서 읽어도 괜찮다`라는 의미의 플래그를 설정합니다.

• slaveOk는 데이터베이스 (secondaryDB)가 아니라 연결 (secondaryConn)에 설정됨
• 이제 이 멤버로부터 읽을 수 있음

 

> secondaryConn.setSlaveOk()

 

이제 Secondary에 쓰기를 시도했지만 Secondary가 쓰기를 받아들이지 않음을 알 수 있습니다.

• Secondary는 클라이언트가 아닌 복제를 통해 가져오는 쓰기만 수행

 

Primary가 중단되면 Secondary 중 하나가 자동으로 Primary로 선출되는데 이를 `자동 장애 조치`라고 부릅니다.

• 테스트를 위해 Primary를 중지하면 포트 27017에서 실행 중인 mongod가 종료되고 사용 중인 셸의 연결이 끊어지기 때문에 몇 개의 오류 메시지가 발생하지만 이는 문제가 되지 않으며 셸의 crash를 야기하지 않음
• 계속해서 Secondary에서 isMaster를 실행하면 Primary 서버가 27018로 전환된 것을 확인 가능
• Primary의 중단을 가장 먼저 발견한 Secondary가 선출되며 실행할 때마다 다른 서버가 Primary가 될 수 있음
• 이제 새 Primary에 쓰기를 보낼 수 있음

 

이 장의 핵심 개념을 복습하면 다음과 같습니다.

• 클라이언트는 독립 실행형 서버에 보낼 수 있는 모든 작업을 Primary 서버에 보낼 수 있음 (읽기, 쓰기, 명령, 인덱스 구축 등)
• 클라이언트는 Secondary에 쓰기를 할 수 없음
• 기본적으로 클라이언트는 Secondary로부터 읽을 수 없음
  • `Secondary에서 읽고 있음을 알고 있다`를 뜻하는 설정을 연결에 명시적으로 설정하면 읽기를 활성화할 수 있음

 

7. 복제 셋 구성 변경

• 복제 셋 구성은 언제든지 변경할 수 있으며 멤버 추가, 삭제 및 변경이 가능함
• 셸 보조자로 몇 가지 일반적인 작업 수행 가능

 

 

앞서 작업한 멤버 추가 및 제거 작업은 셸에서 rs.config()를 실행해 확인할 수 있습니다.

• 구성을 변경할 때마다 "version" 필드 값이 증가하며 해당 필드는 1부터 시작함

 

멤버를 추가하고 제거할 뿐 아니라 이미 존재하는 멤버를 수정할 수도 있습니다.

• 수정을 하려면 셸에서 구성 도큐먼트를 만들고 rs.reconfig를 호출
• 아래 예제는 실수로 호스트명 대신 IP 주소로 멤버 0을 추가했을 때 현재 구성을 로드하고 관련 필드를 변경함

 

복잡한 작업에는 rs.config()가 rs.add()와 rs.remove() 보다 유용할 때가 많습니다.

• 예를 들면 멤버의 구성을 변경하거나, 여러 멤버를 한 번에 추가하거나 제거하는 작업이 있을 때 rs.reconfig()를 사용하면 어떤 구성이든 변경 가능
  • 원하는 구성을 나타내는 구성 도큐먼트를 작성해 rs.config()에 전달하면 됨

 

8. 복제 셋 설계 방법

• 복제 셋을 설계하기에 앞서 과반수 개념을 알아둬야 함
  • Primary를 선출하려면 멤버의 과반수 이상이 필요하고, Primary는 과반수 이상이어야만 Primary 작겨을 유지할 수 있음
  • 또한 쓰기는 과반수 이상에 복제되면 안전해짐
  • 과반수는 복제 셋의 구성에 따라 산정되므로, 얼마나 많은 멤버가 다운되거나 사용할 수 없는 상태인지는 중요하지 않음

 

복제 셋 내 멤버의 수	복제 셋의 과반수
1	1
2	2
3	2
4	3
5	3
6	4
7	4

 

 

• 프라이머리를 하나만 갖도록 셋을 구성하는 것이 중요
• 요구사항이 복잡할수록 다른 구성이 필요할 수도 있지만, 셋이 불리한 조건에서 어떻게 과반수를 획득할 것인지에 대해 항상 생각해야 함
• Primary를 하나 이상 갖도록 몽고DB가 지원한다면 모든 복잡성이 해결될 것
  • 하지만 다중 마스터는 그 자체로 복잡성을 수반함
  • Primary가 두 개가 되면 쓰기 충돌을 처리해야 할 수도 있음 i.g. 누군가가 하나의 Primary에서 도큐먼트를 갱신하고, 다른 사용자가 또 다른 Primary에서 이를 삭제할 수 있음
  • 다중 쓰기를 지원하는 시스템에서 충돌 상황을 처리하는 방법은 일반적으로 두 가지가 있음
    • 수동 조정 방식
    • 시스템이 임의로 `승자`를 선택하게 하는 방식
    • 두 방식 모두 개발자가 코드화하기 쉬운 모델은 아님
  • 따라서 몽고DB는 오직 단일 Primary만 지원

 

8.1 어떻게 산출하는가

• Secondary가 Primary가 되지 못하면 다른 멤버들에 이를 알리고 자신을 Primary로 선출할 것을 요청
• 요청을 받은 멤버들은 다음과 같은 항목을 토대로 검사를 수행
  • 요청받은 멤버가 Primary에 도달할 수 있는가?
  • 선출되고자 하는 멤버의 복제 데이터가 최신인가?
  • 대신 선출돼야 하는 우선순위가 더 높은 멤버는 없는가?

 

• 몽고DB는 버전 3.2에서 복제 프로토콜 버전 1을 도입함
  • 프로토콜 버전 1은 RAFT 합의 프로토콜을 기반으로 함
  • 가장 큰 특징은 RAFT와 유사하다는 점이며, 아비터, 우선순위, 비투표 멤버, 쓰기 결과 확인 등 몽고DB 특유의 복제 개념을 포함함
  • 프로토콜 버전 1은 장애 조치 시간 단축 등 새로운 기능의 기반이 되며, 잘못된 Primary 상황을 감지하는 데 걸리는 시간을 크게 줄이며 용어 ID를 사용함으로써 이중 투표를 방지함

 

• 복제 셋 멤버는 2초마다 서로 하트비트 (ping)을 보냄
  • 10초 이내에 멤버가 하트비트를 반환하지 않으면, 다른 멤버가 그 불량 멤버를 `접근할 수 없음`으로 표시
  • 선출 알고리즘은 우선순위가 가장 높은 Secondary가 선출을 호출하도록 `최선의 노력`을 함
  • 멤버 우선순위는 선출 시기와 결과에 영향을 미침
  • 우선순위가 더 높은 Secondary가 더 낮은 Secondary보다 상대적으로 더 빨리 선출되며 이길 가능성도 더 높지만 우선순위가 더 높은 Secondary가 있더라도, 더 낮은 인스턴스가 잠시 동안 Primary로 선출될 수 있음
  • 복제 셋 멤버들은 우선순위가 가장 높은 멤버가 Primary가 될 때까지 계속해서 선출을 호출

 

• 어떤 멤버가 Primary로 선출되려면 복제 데이터가 최신이어야 함
  • 복제된 모든 작업은 오름차순 식별자에 따라 엄격하게 정렬되므로, 후보는 도달할 수 있는 모든 멤버보다 작업이 늦거나 같아야 함

 

9. 멤버 구성 옵션

• 지금까지 구성한 복제 셋은 모든 멤버의 구성이 동일하므로 상당히 균일하지만 멤버들이 동일하지 않기를 원할 때도 많음
  • 특정 멤버가 우선적으로 Primary가 되게 하거나, 클라이언트에 보이지 않게 해 읽기 요청이 라우팅 되지 않도록 할 수 있음
  • 이를 비롯한 다양한 구성 옵션은 복제 셋 구성의 멤버 서브 도큐먼트에 명시할 수 있음

 

9.1 우선순위

• 우선순위는 특정 멤버가 얼마나 Primary가 되기를 `원하는지` 나타내는 지표
  • 우선순위는 0과 100 사이 값으로 지정할 수 있으며 기본값은 1
  • 멤버의 `priority`를 0으로 지정하면 그 멤버는 절대 Primary가 될 수 없으며 이러한 멤버를 수동적 멤버라고 함

 

• 우선순위가 높은 멤버는 언제나 Primary로 선출됨
• 우선순위를 설정하면 복제 셋에 Primary가 없는 상황이 발생하지 않으며 데이터가 최신이 아닌 멤버가 Primary가 되는 현상 또한 방지 가능
• `priority`의 절댓값은 다른 복제 셋 멤버의 우선순위와 비교해 큰지 혹은 작은지만 중요함
  • 우선순위가 [100, 1, 1]인 멤버들은 우선순위가 [2, 1, 1] 일 때와 동일한 방식으로 동작

 

9.2 숨겨진 멤버

• 클라이언트는 숨겨진 멤버에 요청을 라우팅 하지 않으며, 숨겨진 멤버는 복제 소스로서 바람직하지 않음
• 따라서 많은 이들이 덜 강력한 서버 또는 백업 서버를 숨김
  • 서버를 숨기려면 `hidden: true` 필드를 구성에 추가해야 함
  • 멤버가 숨겨지려면 우선순위가 0이어야 함 (Primary는 숨길 수 없음)

 

• 멤버를 다시 노출시키려면 hidden 옵션을 false로 변경하거나 옵션을 완전히 제거해야 함

 

9.3 아비터 선출

• 멤버가 두 개인 복제 셋은 대부분의 요구 사항에서 명확한 단점이 있지만 소규모를 배포하는 사람들은 데이터 복사본을 세 개나 보관하기를 꺼림
  • 복사본은 두 개면 충분하고, 세 번째 복사본은 관리, 운영, 비용을 고려하면 별 가치가 없다고 생각하기 때문

 

• 이러한 배포에 대해 몽고DB는 Primary 선출에 참여하는 용도로만 쓰이는 아비터라는 특수한 멤버를 지원
  • 아비터는 데이터를 가지지 않으며 클라이언트에 의해 사용되지 않음
  • 오로지 2-멤버 복제 셋에서 과반수를 구성하는 데 사용되며 일반적으로는 아비터가 없는 배포가 바람직

 

• 아비터는 mongod 서버의 작동과는 아무런 연관이 없으므로 일반적으로 몽고DB에 사용하는 서버보다 사양이 낮은 서버에서 경량화 프로세스로 실행 가능
  • 가능하면 다른 멤버와 분리된 별도의 장애 도메인에서 아비터를 실행함으로써 아비터가 복제 셋에 `외부 관점`을 갖게 하는 것을 권장

 

• `--replSet name` 옵션과 빈 데이터 디렉토리를 이용해 일반적으로 mongod를 시작하는 방식처럼 아비터를 시작할 수 있음
  • rs.addArb() 보조자를 이용하면 아비터를 복제 셋에 추가 가능

 

> rs.addArb("server-5:27017")

// 멤버 구성에서 "arbiterOnly" 옵션 지정 가능
> rs.add({"_id": 4, "host": "server-5:27017", "arbiterOnly": true})

 

• 아비터는 복 제 셋에 추가되고 나면 영원히 아비터
  • 아비터에서 아비터가 아닌 것으로 재구성하거나, 아비터가 아닌 것을 아비터로 재구성하는 것은 불가능

 

• 또한 아비터는 큰 클러스터상에서 동점 상황을 없앨 수 있다는 장점이 있음
  • 노드 개수가 짝수이면 절반은 한 멤버에 투표하고 나머지는 다른 멤버에 투표할 수도 있음
  • 이때 아비터를 추가하면 투표 결과를 결정지을 수 있음

 

앞서 아비터의 장점만 나열했지만 아비터를 사용할 때는 몇 가지 주의할 점이 있습니다.

 

주의점 1: 아비터는 최대 하나까지만 사용하라

• 노드의 개수가 홀수이면 아비터는 필요하지 않음
• 흔히 `만약의 경우`를 대비해서 여분의 아비터를 추가해야 한다고 오해함
  • 하지만 아비터를 추가한다고 선출 속도가 빨라지지 않으며, 추가적인 데이터 안전성을 제공하지도 않음

 

• 복제 셋에 멤버가 세 개 있다고 가정했을 때 Primary를 선출하려면 멤버 두 개가 필요함
  • 아비터를 추가하면 복제 셋 멤버는 네 개가 되고, 따라서 Primary를 선발하는 데는 세 개가 필요
  • 따라서 복제 셋은 잠재적으로 덜 안정적인 상태가 되는데, 복제 셋 멤버의 67%가 아니라 이제는 75%가 살아 있어야 하기 때문

 

• 여분의 멤버가 있으면 선출 시간 또한 길어질 수 있음
  • 아비터를 추가해서 노드 개수가 짝수가 되면 아비터는 동점 상황을 막는 것이 아니라 오히려 야기할 수 있음

 

주의점 2: 아비터 사용의 단점

• 작은 규모의 복제 셋에서 데이터 노드 대신 아비터를 사용하면 운영 업무가 더 어려워질 수 있음
  • ex) '일반' 멤버 두 개와 아비터로 구성된 복제 셋을 구동 중에, 데이터를 보관하는 멤버 하나가 다운된다고 가정했을 때 일반 멤버가 죽어 데이터를 복구할 수 없는 경우 현재의 Primary에서 새로운 서버로 데이터 복제본을 가져와야 하는데 데이터 복사는 서버에 상당한 부하를 줄 수 있으며 애플리케이션이 느려질 수 있음

 

• 반대로 데이터를 보관하는 멤버가 세 개라면 하나가 완전히 죽더라도 `숨 쉴 틈`이 있음
  • Primary에 의지하는 대신, 남아 있는 Secondary를 이용해 새로운 서버를 독자적으로 실행할 수 있음
  • 멤버 둘에 아비터가 추가된 경우, Primary는 마지막으로 남아 있는 정상적인 데이터의 복제본이자, 또 다른 복제본을 온라인으로 가져오는 동안 애플리케이션으로부터 부하를 조절하는 개체
  • 따라서 가능하다면 아비터 대신 홀수 개의 일반 멤버를 추가하는 것을 권장

 

9.4 인덱스 구축

• 때때로 Secondary는 Primary에 존재하는 것과 동일한 인덱스를 갖지 않아도 되며, 인덱스가 없어도 됨
  • Secondary를 데이터 백업이나 오프라인 배치 작업에만 사용한다면 "buildIndexes": false를 멤버 구성에 명시하면 되며 해당 옵션은 Secondary가 인덱스를 구축하지 않도록 함
  • 단, "buildIndexes": false는 영구적인 설정이기 때문에 해당 설정이 적용된 멤버는 `일반` 멤버로 재구성 불가
  • 인덱스 비구축 멤버를 인덱스 구축 멤버로 변경하려면, 복제 셋에서 멤버를 제거하고 데이터를 모두 삭제한 뒤 해당 멤버를 다시 복제 셋에 추가해 처음부터 다시 동기화해야 함

 

참고

몽고DB 완벽 가이드 3판 - 한빛미디어