Docs Menu
Docs Home
/
MongoDB Cluster-to-Cluster Sync
/ /

mongosync 행동

이 페이지의 내용

  • 임베디드 검증자 면책조항
  • 설정
  • 클러스터 독립성
  • 구성 파일
  • 클러스터 및 컬렉션 유형
  • 샤딩된 클러스터
  • 다중 클러스터
  • 고정 사이즈 컬렉션
  • 읽기 및 쓰기
  • 쓰기 차단
  • 읽기 및 쓰기 고려
  • 읽기 설정
  • 레거시 인덱스 처리
  • 연속 동기화에 대한 고려 사항
  • 컬렉션 특성에 대한 일시적인 변경 사항
  • 롤링 인덱스 빌드
  • 대상 클러스터
  • 일관성
  • 프로파일링
  • 조회수
  • 시스템 컬렉션
  • UUID
  • 정렬
  • 성능
  • 회복 탄력성
  • 데이터 정의 언어(DDL) 작업
  • 자세히 알아보기

mongosync 바이너리는 Cluster-to-Cluster Sync에 사용되는 프라이머리 프로세스입니다. mongosync는 한 클러스터에서 다른 클러스터로 데이터를 마이그레이션하고 클러스터를 지속적으로 동기화합니다.

mongosync 프로세스 에 대한 개요는 mongosync 정보를 참조하세요.

mongosync 사용을 시작하려면 퀵 스타트 가이드를 참조하세요.

자세한 내용은 상황에 가장 적합한 설치 또는 mongosync연결 페이지를 참조하세요.

1.9부터, mongosync 에는 대상 클러스터 에서 지원되는 모든 컬렉션에 대해 일련의 검증 검사를 수행하여 소스 클러스터 에서 대상으로 문서를 성공적인 으로 전송했는지 확인하는 내장된 검증자가 포함되어 있습니다.

mongosync 프로세스 를 시작하면 검증자는 기본값 활성화되어 있음을 사용자에게 알리는 면책조항이 표시됩니다.

Embedded verification is enabled by default for replica set to replica set migrations.
Verification checks for data consistency between the source and destination clusters.
Verification will cause mongosync to fail if any inconsistencies are detected, but it
does not check for all possible data inconsistencies. Please see the documentation at
https://www.mongodb.com/ko-kr/docs/cluster-to-cluster-sync/current/reference/verification/embedded
for more details. Verification requires approximately 0.5 GB of memory per 1 million documents
on the source cluster and will fail if insufficient memory is available. Accepting this
disclaimer indicates that you understand the limitations and memory requirements for this
tool. To skip this disclaimer prompt, use –-acceptDisclaimer.
To disable the embedded verifier, specify 'verification: false' when starting mongosync. Please see
https://www.mongodb.com/ko-kr/docs/cluster-to-cluster-sync/current/reference/verification/
for alternative verification methods.
Do you want to continue? (y/n):

면책 조항을 이미 읽고 동의한 경우 mongosync --acceptDisclaimer 옵션으로 을(를) 시작하여 이 알림을 건너뛸 수 있습니다.

mongosync 소스 클러스터 와 대상 클러스터 간에 컬렉션 데이터를 동기화합니다. mongosync 이(가) 사용자 또는 역할을 동기화하지 않습니다. 따라서 각 클러스터 에서 서로 다른 액세스 권한을 가진 사용자를 만들 수 있습니다.

mongosync 에 대한 옵션은 YAML 구성 파일 에서 설정하다 수 있습니다. --config 옵션을 사용합니다. 예를 예시 다음과 같습니다.

$ mongosync --config /etc/mongosync.conf

사용 가능한 설정에 대한 자세한 내용은 구성을 참조하세요.

Cluster-to-Cluster Sync 는 샤딩된 클러스터 간의 복제 를 지원합니다. mongosync 은(는) 개별 샤드를 소스 클러스터 에서 대상 클러스터 로 병렬로 복제합니다. 그러나 mongosync 은 소스 클러스터의 샤딩 구성을 보존하지 않습니다.

중요

소스 또는 대상 클러스터 가 샤딩된 클러스터 인 경우, 두 클러스터 모두에서 밸런서 를 중지하고 moveChunk 마이그레이션 기간 동안 또는 명령을 실행 moveRange balancerStop 하지 않아야 합니다. 밸런서 를 중지하려면 명령을 실행 하고 명령이 완료될 때까지 기다립니다.

mongosync 이(가) 샤딩된 대상 클러스터에 동기화되면 대상 클러스터 에서 샤딩된 컬렉션에 대한 청크를 미리 분할 클러스터. 각 샤딩된 컬렉션 에 대해 mongosync 는 대상 클러스터 에 있는 샤드보다 두 배 많은 청크를 생성합니다.

mongosync mongosync 인스턴스가 여러 개 있어도 소스에서 대상까지의 청크 분포를 유지하지 않습니다. 대상 클러스터 의 소스 클러스터 에서 사전 분할된 특정 청크를 재현하는 것은 불가능합니다.

mongosync 가 소스 클러스터 에서 대상 클러스터 로 보존하는 유일한 샤딩 구성은 샤딩 키입니다. 마이그레이션 이 완료되면 소스 클러스터의 배포와 독립적으로 문서를 배포하는 대상 클러스터의 밸런서 를 활성화 할 수 있습니다.

샤딩된 대상 클러스터 에 동기화 하면 mongosync 는 라운드 로빈을 통해 각 데이터베이스 에 프라이머리 샤드 를 할당합니다.

경고

movePrimary 마이그레이션 중에 소스 또는 대상 클러스터 에서 를 실행하면 치명적인 오류가 발생하거나 마이그레이션 을 처음부터 다시 시작해야 할 수 있습니다. 자세한 내용은 샤드 클러스터를 참조하세요.

소스 클러스터를 여러 대상 클러스터에 동기화하려면 각 대상 클러스터에 mongosync 인스턴스를 하나를 사용합니다. 자세한 내용은 다중 클러스터 제한 사항을 참조하세요.

1.3.0부터 Cluster-to-Cluster Sync는 고정 사이즈 컬렉션을 지원하지만 일부 제한이 있습니다 .

  • convertToCapped는 지원되지 않습니다. convertToCapped를 실행하면 mongosync가 오류와 함께 종료됩니다.

  • cloneCollectionAsCapped 은(는) 지원되지 않습니다.

원본 클러스터의 제한된 컬렉션은 동기화 중에 정상적으로 작동합니다.

대상 클러스터의 제한된 컬렉션에는 동기화 중에 일시적인 변경 사항이 있습니다.

  • 최대 문서 수에는 제한이 없습니다.

  • 최대 컬렉션 크기는 1PB입니다.

mongosync 커밋 중 최대 문서 수 및 최대 문서 크기에 대한 원래 값을 복원합니다.

mongosync 기본적으로 쓰기 차단을 활성화하지 않습니다. 쓰기 차단을 활성화하면mongosync가 다음과 같이 쓰기를 차단합니다.

  • 동기화 중 대상 클러스터에서.

  • commit이 수신되었을 때 소스 클러스터에서.

쓰기 차단을 활성화하려면 start API를 사용하여 enableUserWriteBlockingtrue로 설정합니다. 동기화가 시작된 후에는 쓰기 차단을 활성화할 수 없습니다.

역동기화를 이후에 사용하려면 mongosync을(를) 시작할 때 쓰기 차단을 활성화해야 합니다.

enableUserWriteBlocking을 설정하기 위해서는 mongosync 사용자에게 setUserWriteBlockModebypassWriteBlockingMode ActionType을 포함하는 역할이 있어야 합니다.

참고

enableUserWriteBlocking을 사용하는 경우, bypassWriteBlockingMode 작업 유형이 없는 사용자에 대해서만 쓰기가 차단됩니다. 이 작업 유형이 있는 사용자는 쓰기를 수행할 수 있습니다.

소스 클러스터에 대한 읽기 작업은 항상 허용됩니다.

/progress 엔드포인트가 canWritetrue로 보고하면 소스 및 대상 클러스터의 데이터가 일치합니다.

mongosync 상태를 확인하려면 /progress API 엔드포인트를 호출합니다. /progress 출력에는 불리언 값인 canWrite가(이) 포함됩니다.

  • canWritetrue인 경우 대상 클러스터에 쓰는 것이 안전합니다.

  • canWritefalse인 경우 대상 클러스터에 쓰지 않습니다.

mongosync가 동기화되는 동안에는 소스 클러스터에 안전하게 쓸 수 있습니다. canWritetrue가 아닌 경우 대상 클러스터에 쓰지 않도록 합니다.

기본적으로 mongosync는 소스 클러스터의 읽기에 대해 읽기 고려 수준을 "majority"로 설정합니다. 대상 클러스터에 대한 쓰기의 경우 mongosync는 쓰기 문제 수준을 "majority"로 설정하고 j: true 옵션을 사용합니다.

읽기 및 쓰기 문제 구성 및 동작에 대한 자세한 내용은 읽기 고려쓰기 고려 를 참조하세요.

mongosync 에는 소스 및 대상 클러스터에 연결할 때 primary 읽기 설정(read preference)이 필요합니다. 자세한 내용은 읽기 설정 옵션을 참조하세요.

mongosync 0 또는 빈 문자열과 같은 레거시 인덱스 값을 대상의 1 로 다시 씁니다. mongosync 는 대상에서 잘못된 인덱스 옵션도 제거합니다.

mongosync 을 사용하는 지속적인 동기화 사용 사례의 경우 소스에서 대상으로 전환하기 전에 mongosync 커밋을 확인합니다.

재해 시나리오와 같이 mongosync 가 커밋 되기 전에 소스 클러스터 가 종료되는 경우 대상 클러스터 에 소스 데이터의 일관적인 스냅샷 이 없을 수 있습니다. 학습 내용은 일관성을 참조하세요.

참고

커밋 후에는 mongosync 은 빈 대상 클러스터로만 동기화 할 수 있으므로 두 클러스터 간의 지속적인 동기화 를 다시 시작할 수 없습니다. 전환 후 동일한 두 클러스터를 사용해야 하는 경우 reverse 엔드포인트를 호출하여 클러스터를 동기화 된 상태로 유지할 수 있습니다. 그렇지 않으면 비어 있는 새 대상 클러스터 를 사용하여 새로운 연속 동기화 작업을 시작합니다.

mongosync 동기화 중에 다음 컬렉션 특성을 일시적으로 변경합니다. 커밋 프로세스 중에 원래 값이 복원됩니다.

변경
설명

Unique Indexes

소스 클러스터 의 고유 인덱스는 대상 클러스터 의 비고유 인덱스로 동기화됩니다.

TTL Indexes

동기화하면 대상 클러스터에서 expireAfterSecondsMAX_INT의 값으로 설정됩니다.

Hidden Indexes

동기화에서는 숨겨진 인덱스가 숨겨지지 않은 인덱스로 복제됩니다.

쓰기 차단

쓰기 차단을 활성화하면mongosync가 다음과 같이 쓰기를 차단합니다.

  • 동기화 중 대상 클러스터에서.

  • commit이 수신되었을 때 소스 클러스터에서.

학습 내용은 쓰기 차단을 참조하세요.

고정 사이즈 컬렉션

동기화 하면 고정 사이즈 컬렉션이 허용되는 최대 크기로 설정됩니다.

더미 인덱스

경우에 따라 동기화는 샤딩된 된 컬렉션 또는 데이터 정렬된 컬렉션에 대한 쓰기를 지원 하기 위해 대상에 더미 인덱스를 생성할 수 있습니다.

mongosync 마이그레이션 중에는 롤링 인덱스 빌드를 지원 하지 않습니다. 마이그레이션 중에 인덱스가 롤링 방식으로 빌드되지 않도록 하려면 다음 방법 중 하나를 사용하여 대상 인덱스가 소스 인덱스와 일치하는지 확인합니다.

mongosync 대상 클러스터 에서 궁극적 일관성 을 지원합니다. 커밋 할 때까지 대상 클러스터 에서 읽기 일관성 이 보장되지 않습니다. 커밋하기 전에는 특정 점 에 소스 클러스터와 대상 클러스터가 다를 수 있습니다. 학습 내용 은 연속 동기화 시 고려 사항을 참조하세요.

mongosync mongosync 동기화되는 동안 는 소스에서 대상으로 쓰기를 릴레이할 때 쓰기를 재정렬하거나 결합할 수 있습니다. 특정 문서 의 경우 총 쓰기 횟수는 소스와 대상에 따라 다를 수 있습니다.

트랜잭션은 대상 클러스터 에 원자적으로 표시되지 않을 수 있습니다. 재시도 가능한 쓰기는 대상 클러스터 에서 재시도할 수 없을 수 있습니다.

소스 데이터베이스에서 프로파일링이 활성화된 경우, MongoDB는 <db>.system.profile이라는 이름의 특수 컬렉션을 만듭니다. 동기화가 완료된 후 Cluster-to-Cluster Sync는 나중에 소스 데이터베이스가 제거되더라도 <db>.system.profile 컬렉션을 대상에서 제거하지 않습니다. <db>.system.profile 컬렉션은 대상에 있는 사용자 데이터의 정확성을 변경하지 않습니다.

뷰가 있는 데이터베이스가 소스에서 제거되면 대상이 해당 데이터베이스에 빈 system.views 컬렉션을 표시할 수 있습니다. 빈 system.views 컬렉션은 대상에 있는 사용자 데이터의 정확성을 변경하지 않습니다.

Cluster-to-Cluster Sync는 system collections 대상 클러스터에 복제하지 않습니다.

소스 클러스터에서 dropDatabase 명령을 실행하는 경우 이 변경 사항은 대상 클러스터에 직접 적용되지 않습니다. 대신 Cluster-to-Cluster Sync는 대상 클러스터의 데이터베이스에서 사용자 컬렉션 및 뷰를 삭제하지만 해당 데이터베이스의 시스템 컬렉션은 삭제하지 않습니다.

예를 들어, 대상 클러스터에서:

  • 제거 작업은 사용자가 만든 system.js 컬렉션에 영향을 주지 않습니다.

  • 프로파일링을 활성화하면 system.profile 컬렉션은 그대로 유지됩니다.

  • 소스 클러스터에서 뷰를 만든 후 데이터베이스를 제거하는 경우, 제거를 복제하면 뷰는 제거되지만 빈 system.views 컬렉션이 남습니다.

이 경우 을(를) 복제하면 dropDatabase 사용자가 생성한 컬렉션이 데이터베이스에서 전부 제거되지만, 시스템 컬렉션은 대상 클러스터에 남습니다.

mongosync 대상 클러스터에 새 UUID가 있는 컬렉션을 만듭니다. 소스 클러스터와 대상 클러스터의 UUID 간에는 관계가 없습니다. 애플리케이션에 하드 코딩된 UUID (MongoDB에서 권장하지 않음)가 포함되어 있는 경우 마이그레이션된 클러스터에서 제대로 작동하려면 먼저 해당 애플리케이션을 업데이트해야 할 수 있습니다.

mongosync 소스 클러스터의 자연 정렬 순서를 유지하지 않는 미지정 순서로 대상 cluster에 문서를 삽입합니다. 애플리케이션이 문서 순서에 따라 달라지면서도 이 애플리케이션에 대한 정렬 방법이 지정되지 않은 경우, 해당 애플리케이션을 업데이트해서 예상 정렬 순서를 지정해야 애플리케이션이 마이그레이션된 클러스터에서 제대로 작동하게 됩니다.

mongosync 은(는) 복원력이 뛰어나고 치명적이지 않은 오류를 처리할 수 있습니다. "오류" 또는 "실패"라는 단어가 포함된 로그는 mongosync 에 오류가 발생했거나 데이터가 손상되었음을 의미하지 않습니다. 예를 들어, 네트워크에 오류가 발생하면 mongosync 로그에 "오류"라는 단어가 포함될 수 있지만 mongosync 은(는) 여전히 동기화를 완료할 수 있습니다. 동기화가 완료되지 않으면 mongosync 은(는) 치명적인 로그 항목을 기록합니다.

동기화 중에 DDL 작업(db.createCollection()db.dropDatabase()와 같은 컬렉션 또는 데이터베이스에 작용하는 작업)을 사용하면 마이그레이션 실패 위험이 증가하고 mongosync 성능에 부정적인 영향을 미칠 수 있습니다. 최상의 성능을 위해 동기화가 진행되는 동안에는 소스 클러스터에서 DDL 작업을 수행하지 마세요.

DDL 작업에 대한 자세한 내용은 보류 중인 DDL 작업 및 트랜잭션을 참조하세요.

돌아가기

mongosync