마이그레이션 대상: mongomirror

소스 MongoDB 배포

• 소스 MongoDB 배포는 복제본 세트여야 합니다. 소스가 독립 실행형 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 배포에 인덱스 키 제한을 초과하는 키가 있는 인덱스가 포함된 경우 실시간 마이그레이션 프로시저를 시작하기 전에 크기가 큰 키가 포함되지 않도록 인덱스를 수정합니다.

소스 복제본 세트에 대한 필수 액세스 권한

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를 실행하는 소스 클러스터의 경우 사용자는 최소한 clusterMonitor 및 readAnyDatabase 역할을 모두 가지고 있어야 합니다. 예를 들면 다음과 같습니다.

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

• MongoDB 3.2를 실행하는 소스 클러스터의 경우 사용자는 최소한 clusterManager 및 readAnyDatabase 역할과 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 배포

대상 Atlas 배포:

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

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

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

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

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

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

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

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

  참고

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

대상 cluster에 대한 필수 액세스 권한

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

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