문서 메뉴
문서 홈
/
MongoDB 아틀라스
/ / /

마이그레이션 대상: mongomirror

이 페이지의 내용

  • 전제 조건
  • 경로 업그레이드
  • 다운로드 mongomirror
  • mongomirror 프로세스
  • 실행 mongomirror
  • Atlas로 전환
  • 모니터링
  • 성능
  • 명령 구문, 옵션 및 예제
  • 문제 해결

mongomirror는 기존 MongoDB 복제본 세트에서 MongoDB Atlas 복제본 세트로 데이터를 수동으로 마이그레이션하는 도구입니다. mongomirror는 기존 복제본 세트 또는 애플리케이션을 종료할 필요가 없으며, 사용자 또는 역할 데이터를 가져오거나 config 데이터베이스를 복사하지 않습니다.

다음과 같은 경우 mongomirror를 사용하세요.

  • MongoDB Atlas 외부에서 호스팅되는 MongoDB 배포에서 MongoDB Atlas 클러스터로 데이터 세트 마이그레이션을 1회 실행합니다.

  • 한 Atlas 클러스터에서 다른 Atlas 클러스터로 데이터 세트 마이그레이션을 1회 실행합니다.

또한 데이터 가져오기 및 마이그레이션 도구 선택을 참조하세요.

  • 소스 MongoDB deployment는 복제본 세트여야 합니다. 소스가 독립형 MongoDB 배포인 경우 mongomirror, 를 실행하기 전에독립형을 복제본 세트로 변환합니다.

  • 소스 복제본 세트는 MongoDB 버전 2.6 이상을 실행해야 합니다.

  • 소스 MongoDB 복제본 세트는 M0 무료 클러스터 또는 M2/M5 공유 클러스터가 될 수 없습니다.

  • 절차 중 어떤 경우에도 featureCompatibilityVersion 플래그를 변경하지 않습니다.

  • MongoDB 4.4 이하에서 MongoDB 5.0 이상을 실행하는 Atlas 클러스터로 마이그레이션하는 경우, 컬렉션에서 geoHaystack 인덱스를 제거하세요.

  • mongomirror 은(는) TTL 인덱스 와 호환되지 않습니다. 마이그레이션 프로세스가 완료되면 기존 TTL 인덱스를 모두 삭제하고 다시 작성합니다. 쿼리 성능에 중요하기 때문에 기존 인덱스를 삭제하지 않으려면 지원팀에 문의 하여 대체 옵션을 알아보세요.

  • 마이그레이션 프로세스 중에는 renameCollection 명령을 사용하거나 $out 집계 단계가 포함된 집계 파이프라인을 실행하는 등 네임스페이스를 변경하지 마세요.

  • 프로세스의 일부로 실행되는 초기 renameCollection $out 동기화의 일부로 명령 mongomirror 또는 애그리게이션 단계를 사용할 수 없습니다.

  • 마이그레이션의 초기 동기화 단계에서는 프라이머리 계정을 다시 시작하지 않아야 합니다.

  • MongoDB 배포에 인덱스 키 제한 을 초과하는 키가 있는 인덱스가 포함되어 있는 경우, 실시간 마이그레이션 절차를 시작하기 전에 크기가 큰 키가 포함되지 않도록 인덱스를 수정합니다.

    중요

    인덱스 키 한도

    param.failIndexKeyTooLong MongoDB 버전 4 에서 더 이상 사용되지 않습니다.2 및 MongoDB 4 에서 제거되었습니다.4 이상. 4 이전 MongoDB의 경우.2, 이 매개변수를 false 로 설정합니다.

mongomirror믐 소스 복제본 세트에 대한 네트워크 액세스 권한이 있어야 합니다. 소스 복제본 세트에 인증이 필요한 경우 mongomirror를 실행할 때 사용자 자격 증명을 포함해야 합니다. 최소한 다음 권한을 가진 데이터베이스 사용자를 지정해야 합니다.

  • 모든 데이터베이스와 컬렉션을 읽습니다. admin 데이터베이스의 readAnyDatabase 역할이 이 요구 사항을 충족합니다.

  • oplog를 읽어 보세요. Oplog 액세스를 참조하세요.

  • getParameter 명령을 실행합니다.

해당 사용자가 없는 경우 소스 MongoDB 복제본 세트에서 사용자를 생성하세요. MongoDB 서버 버전마다 기본 제공 역할이 다릅니다. MongoDB Server 버전에 따라 기본 제공 역할을 선택하고 mongosh 에서 적절한 명령을 실행합니다.

  • 소스 클러스터의 경우 사용자는 readAnyDatabase, clusterMonitor, backup 역할이 있어야 합니다.

    실시간 마이그레이션 프로세스를 실행할 데이터베이스 사용자에게 이러한 역할이 있는지 확인하려면 admin 데이터베이스에서 db.getUser() 명령을 실행합니다.

    use admin
    db.getUser("admin")
    {
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
    {
    "role" : "backup",
    "db" : "admin"
    },
    {
    "role" : "clusterMonitor",
    "db" : "admin"
    }
    {
    "role" : "readAnyDatabase",
    "db" : "admin"
    }
    ]
    } ...

    이외에도 소스 클러스터의 데이터베이스 사용자는 데이터베이스의 oplog를 읽을 수 있는 역할이 있어야 admin 합니다. 자세히 알아보려면 Oplog 액세스를참조하십시오.

  • MongoDB 3.4를 실행하는 소스 클러스터의 경우 사용자는 최소한 clusterMonitorreadAnyDatabase 역할을 모두 가지고 있어야 합니다. 예를 들면 다음과 같습니다.

    use admin
    db.createUser(
    {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "clusterMonitor", "readAnyDatabase" ]
    }
    )
  • MongoDB 3.2를 실행하는 소스 클러스터의 경우 사용자는 최소한 clusterManagerreadAnyDatabase 역할과 local 데이터베이스에 대한 읽기 액세스 권한이 모두 있어야 합니다. 여기에는 사용자 지정 역할이 필요합니다. 이 역할은 다음 명령을 사용해서 생성할 수 있습니다.

    use admin
    db.createRole(
    {
    role: "migrate",
    privileges: [
    { resource: { db: "local", collection: "" }, actions: [ "find" ] }
    ],
    roles: ["readAnyDatabase", "clusterManager"]
    }
    )
    db.createUser(
    {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "migrate" ]
    }
    )
  • MongoDB 2.6 또는 3.0을 실행하는 소스 클러스터의 경우 사용자에게는 최소한 readAnyDatabase 역할이 있어야 합니다. 예를 들면 다음과 같습니다.

    use admin
    db.createUser(
    {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "readAnyDatabase" ]
    }
    )

대상 Atlas 배포:

  • M0 무료 클러스터, M2 또는 M5 공유 클러스터일 수 없습니다.

  • 서버리스 인스턴스가 될 수 없습니다.

  • 복제본 세트이어야 합니다.

  • 소스 클러스터 MongoDB 버전과 동일하거나 아니면 그 이상인 버전이 있어야 합니다. 업그레이드 경로를 참조합니다.

  • 소스 클러스터와 겹치는 네임스페이스를 포함해서는 안 됩니다. mongomirror 2}가 대상 클러스터에서 겹치는 네임스페이스를 감지하는 경우 프로세스를 시작하기 전에 실패합니다. 대상 클러스터에 네임스페이스가 겹치는 경우 --drop 사용하여 대상 클러스터에서 데이터를 모두 삭제하거나 --includeNamespace사용하여 소스 클러스터에서 가져올 네임스페이스를 나열합니다.

  • 다음 중 하나의 IP 액세스 목록에도 포함되어야 합니다.

    • mongomirror가 실행 중인 서버의 공용 IP 주소 또는

    • VPC 피어링을 설정한 경우, 상대방의 VPC CIDR 블록(또는 서브넷) 또는 상대방 VPC의 보안 그룹(Security Group) 중 하나를 사용해야 합니다.

    참고

    클러스터 내 임의의 노드에 대한 공용 IP 주소를 찾으려면 명령줄에서 nslookup 도구를 사용합니다. 자세한 내용은 Atlas cluster의 공용 IPs를 변경할 수 있나요?를 참조하세요.

mongomirror 대상 클러스터에 대한 네트워크 액세스 권한이 있어야 합니다.

실행하려면Atlas admin역할이 있는 데이터베이스 사용자를 지정해야 합니다. mongomirror 자세히 알아보려면 Add Database Users 참조합니다.

mongomirror 다음 마이그레이션 경로를 지원합니다.

중요

mongomirror 를 사용하여 소스 복제본 세트 6 에서 마이그레이션할 수 없습니다.0.x 이상을 대상 복제본 세트 6 에 추가합니다.0.x 이상. 복제본 세트 6 를 마이그레이션합니다.0.x 이상 버전에서는 MongoDB를 6 이상으로 업그레이드합니다.0.13 및 이 실시간 마이그레이션 절차를 사용합니다.

소스 복제본 세트
MongoDB 버전
대상 Atlas 복제본 세트
MongoDB 버전
5.0
4.4, 5.0
4.4
4.4, 5.0
4 . 2
4.4, 5.0
4 . 0
4.4, 5.0
3 . 6
4.4, 5.0
3 . 4
4.4, 5.0
3 . 2
4.4, 5.0
3 . 0
4.4, 5.0
2.6
4.4, 5.0

참고

5 에서 다운그레이드합니다.0 ~ 4.4, 소스 FCV 이 대상과 일치해야 합니다.

참고

macOS 64비트에서 mongomirror 파일을 다운로드한 후 처음으로 열려고 하면 보안 경고가 나타납니다. 계속하려면 보안 설정을 재정의하여 앱 열기를 참조하세요.

운영 체제
다운로드
Amazon Linux 1
Amazon Linux 2
Debian 8.1
Debian 9.2
Debian 10
macOS 64-bit
RHEL 6.2
RHEL 7.0
RHEL 7.1 PPC64LE
RHEL 7.2 s390x
RHEL 8.0
RHEL 8.1 PPC64LE
SLES 12
SLES 15
Ubuntu 14.04
Ubuntu 16.04
Ubuntu 16.04 ARM
Ubuntu 16.04 PPC64LE
Ubuntu 18.04
Ubuntu 18.04 ARM
Ubuntu 18.04 PPC64LE
Ubuntu 20.04
Ubuntu 20.04 ARM
Windows

mongomirror를 시작하면 다음과 같은 작업이 수행됩니다.

  1. TLS/SSL을 통해 Atlas에 연결합니다.

  2. 초기 동기화를 수행하면 기존 MongoDB 복제본 세트의 컬렉션이 Atlas의 대상 클러스터로 복사됩니다.

  3. 초기 동기화가 끝난 후 해당 복제본 세트의 oplog를 지속적으로 테일링하여 수신 변경 사항을 확인하고, Atlas의 대상 클러스터에서 이를 재생합니다. mongomirrorconfig 데이터베이스를 복사하지 않습니다. mongomirror는 버전 0.9.0부터 와이어 압축을 사용하고(소스 또는 대상 클러스터에서 와이어 압축이 허용된 경우) --compressors를 사용하여 허용할 압축 라이브러리를 지정합니다.

    참고

    버전 0 부터 시작됩니다.5.0 mongomirror 는 소스 클러스터에 인덱스가 구축된 방식에 관계없이 전경의 대상 클러스터에 모든 인덱스를 구축합니다. 전경 인덱스 빌드는 데이터베이스에 대한 다른 모든 작업을 차단합니다. 자세한 내용 은 채워진 컬렉션에 대한 인덱스 빌드 작업을 참조하세요.

mongomirror는 일단 시작되면 종료될 때까지 계속 실행됩니다.

1

소스 복제본 세트에 인증이 필요한 경우 mongomirror 실행 시 사용자 자격 증명을 포함해야 합니다. 요구 사항은 소스 복제본 세트에 대한 필수 액세스 권한을 참조하세요.

mongomirror 실행하는 경우 이러한 자격 증명을 지정해야 하기 때문에 새 사용자에 대해 선택한 사용자 이름과 패스워드 기록해 둡니다.

2
  1. 아직 표시되지 않은 경우 탐색 표시줄의 Organizations 메뉴에서 프로젝트가 포함된 조직을 선택합니다.

  2. 아직 표시되지 않은 경우 내비게이션 바의 Projects 메뉴에서 프로젝트를 선택합니다.

  3. 사이드바에서 Security 제목 아래의 Database Access 을 클릭합니다.

3

실행하려면Atlas admin역할이 있는 데이터베이스 사용자를 지정해야 합니다. mongomirror 데이터베이스 사용자 생성에 대한 설명서는 데이터베이스 사용자 Add Database Users 참조합니다.

해당 사용자가 없는 경우 사용자를 만듭니다:

  1. 아직 표시되지 않은 경우 Database Users 탭을 클릭합니다.

  2. 딸깍 하는 소리 Add New Database User.

  3. Atlas admin 0} 사용자를 추가합니다.

mongomirror 실행하는 경우 이러한 자격 증명을 지정해야 하기 때문에 새 사용자에 대해 선택한 사용자 이름과 패스워드 기록해 둡니다.

4

mongomirror를 실행할 호스트가 원하는 클러스터의 IP 액세스 목록에 없으면 이 목록을 업데이트하세요. 다음 두 가지 중 하나를 지정할 수 있습니다.

  • mongomirror 실행될 서버의 공인 IP 주소 혹은

  • VPC 피어링을 설정한 경우, 상대방의 VPC CIDR 블록(또는 서브넷) 또는 상대방 VPC의 보안 그룹(Security Group) 중 하나를 사용해야 합니다.

5
  1. 이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.

  2. 이미 표시되어 있지 않은 경우 Projects 탐색 모음의 프로젝트 메뉴에서 원하는 프로젝트를 선택합니다.

  3. Clusters 페이지가 아직 표시되지 않은 경우 사이드바에서 Database를 클릭합니다.

6

데이터를 마이그레이션하려는 Atlas 클러스터에 대해 Connect 를 클릭합니다.

7

Atlas 클러스터의 호스트 이름 정보는 Atlas 사용자 인터페이스에서 확인할 수 있습니다.

참고

mongomirror로 데이터를 마이그레이션할 때는 드라이버를 사용할 필요가 없습니다.

  1. Connect 대화 상자에서 Shell 을 클릭합니다.

  2. 드롭다운 목록에서 3.4 or earlier 선택합니다. 연결 문자열은 다음과 같은 예시와 유사해야 합니다. 이러한 예시는 가독성을 위해 여러 줄로 나뉘어져 있습니다.

    mongodb://<username>:<PASSWORD>@
    00.foo.mongodb.net:27017,
    01.foo.mongodb.net:27017,
    02.foo.mongodb.net:27017/test?
    ssl=true&replicaSet=myAtlasRS&authSource=admin
  3. 다음 예제와 같이 텍스트 편집기에서 replicaSet 값을 붙여 넣고 전방 슬래시(/)를 추가한 다음, 호스트 목록을 쉼표로 구분된 값으로 추가하세요.

    myAtlasRS/00.foo.mongodb.net:27017,01.foo.mongodb.net:27017,02.foo.mongodb.net:27017

다음 단계에서 --destination 에 이 값을 사용합니다.

8

마이그레이션 프로세스를 완료하려면 Atlas로 전환합니다.

mongomirror 초기 동기화를 완료하고 복제본 세트의 oplog를 추적한 후 대상 Atlas 클러스터로 전환할 수 있습니다.

1

이렇게 하면 소스 클러스터에서 쓰기가 추가로 발생하지 않습니다.

2

이는 소스 클러스터와 대상 클러스터가 일관적인 상태임을 나타냅니다.

3

Atlas 클러스터가 최신 버전이 되면 mongomirror 중지합니다.

4

cluster 패널의 Connect 버튼을 통해 제공된 Atlas 연결 문자열로 클라이언트 애플리케이션을 업데이트하세요.

Atlas 연결에 대한 자세한 내용은 드라이버를 통한 연결을 참조하세요.

mongomirror진행 상황을 터미널의 표준 출력에 기록합니다. 초기 동기화가 진행되는 동안 mongomirror 복사하는 각 collection에 대해 진행 표시줄을 기록합니다. 예를 들면 다음과 같습니다.

2021-08-09T16:35:50.227-0000 [#....................] park.events 2179/34184 (6.4%)
2021-08-09T16:35:50.227-0000 [#############........] zoo.animals 29000/49778 (58.3%)

oplog를 테일링할 경우 mongomirror 소스 클러스터의 가장 최근 oplog 항목과 대상 클러스터에서 마지막으로 처리된 oplog 항목 간의 지연 시간(단위: 초)을 기록합니다. 예를 들면 다음과 같습니다.

2016-12-12T16:22:17.027-0800 Current lag from source: 6s

지연 시간이 6초라는 것은 마지막으로 처리된 mongomirror oplog 항목이 소스 클러스터에서 사용 가능한 가장 최근 항목보다 6초 전에 발생했다는 의미입니다.

참고

mongomirror를 사용해서 따라잡기까지 걸리는 시간은 초당 유입되는 항목의 수에 따라 6초보다 많을 수도 있고 적을 수도 있습니다.

지연 시간이 0초라는 것은 mongomirror가 최신 oplog 항목보다 1초 이내에 빨리 유입된 항목을 처리 중이라는 뜻입니다.

소스 클러스터에 인덱스가 있다면 mongomirror가 대상 클러스터에서 동일한 인덱스를 구축합니다. 진행 로그에는 인덱스 구축 프로세스의 시작 시간과 종료 시간이 표시됩니다. 인덱스 빌드의 진행 상황을 보려면 다음 두 가지 방법 중 하나를 사용하면 됩니다.

  • 대상 cluster의 프라이머리 노드에서 currentOp 명령어를 사용합니다. command 필드는 실행 중인 작업에 대한 정보를 표시합니다. 인덱스 구축 항목은 다음과 유사합니다.

    "command" : {
    "createIndexes" : "perfs",
    "indexes" : [
    {
    "key" : {
    "animal" : "text"
    },
    "name" : "animal_text"
    }
    ]...
  • 대상 클러스터에 대한 mongodb 로그를 다운로드하고 인덱스 관련 라인의 최근 항목을 검색합니다. 인덱스 작성과 관련된 로그 메시지는 다음과 유사하게 표시됩니다.

    {"t":{"$date":"2021-08-09T16:35:50.227+00:00"},"s":"I", "c":"INDEX", "id":20447, "ctx":"conn1080","msg":"Index build: completed","attr":{"buildUUID":{"uuid":{"$uuid":"c4a62739-bf19-456d-bbd6-7baa29f1063b"}}}}

네트워크 및 CPU 리소스에 대한 경합을 피하려면 mongomirror 복제본 세트의 mongod 인스턴스 호스트가 아닌 호스트에서 를 실행합니다.

  • mongomirror 은(는) 소스 복제본 세트의 성능에 보조로 설정할 때와 비슷한 영향을 미칩니다.

    • 초기 동기화 단계에서는 데이터 세트의 크기에 따라 로드가 확장됩니다.

    • 초기 동기화가 완료되면 시간당 사용되는 oplog 기가바이트에 따라 로드가 확장됩니다.

mongomirror의 구문, 옵션 및 예제는 mongomirror 참조 페이지를 참조하세요.

mongomirror 문제 해결의 경우 Common Post-Validation Errors for Live Migration (Pull) 참조합니다.

돌아가기

자체 관리형 도구

다음

mongomirror