자체 관리형 복제본 세트를 샤드 클러스터로 변환

복제본 세트에서 기존 사용자 및 역할 가져오기

기존 사용자 및 역할을 가져오려면 mongodump를 실행합니다.

mongodump -d=admin --out=adminDump -u <adminUser> -p <password> --host <replicaSetURI> --dumpDbUsersAndRoles

config 서버 복제본 세트 배포

config 서버에 대해 3명의 멤버로 구성된 복제본 세트를 배포합니다. 이 예시에서 config 서버는 다음 호스트를 사용합니다.

• mongodb7.example.net

• mongodb8.example.net

• mongodb9.example.net

1. Config 서버 구성

   각 Config 서버 호스트에서 mongod 인스턴스를 구성합니다. 각 mongod 인스턴스에 대해 구성 파일에서 이러한 옵션을 지정합니다.

   옵션	값
   replication.replSetName	configReplSet
   sharding.clusterRole	configsvr
   net.bindIp	localhost, 그 뒤에 mongod가 클라이언트 연결을 수신해야 하는 다른 호스트 이름을 지정합니다.

   replication:
     replSetName: configReplSet
   sharding:
     clusterRole: configsvr
   net:
     bindIp: localhost,<hostname(s)>

   배포에 적합한 추가 옵션을 포함하세요.

2. Config 서버 시작

   지정된 구성으로 mongod를 배포합니다.

   mongod --config <PATH_TO_CONFIG_FILE>

   config 서버는 기본 데이터 디렉토리 /data/configdb 및 기본 포트 27019를 사용합니다.

3. config 서버 중 하나에 연결합니다.

   mongosh(을)를 사용하여 config 서버 중 하나에 연결합니다. 예를 들면 다음과 같습니다.

   mongosh "mongodb://mongodb7.example.net:27019"

4. config 서버 복제본 세트를 시작합니다.

   복제본 세트를 시작하려면 rs.initiate()를 실행합니다.

   rs.initiate( {
      _id: "configReplSet",
      configsvr: true,
      members: [
         { _id: 0, host: "mongodb7.example.net:27019" },
         { _id: 1, host: "mongodb8.example.net:27019" },
         { _id: 2, host: "mongodb9.example.net:27019" }
      ]
   } )

   앞의 명령은 로컬 호스트 예외를 사용하여 인증 없이 관리 작업을 수행합니다.

   중요

   rs.initiate()를 복제본 세트의 단일 mongod 인스턴스에서만 실행합니다.

기존 사용자 및 역할을 새 구성으로 복원

mongodump를 실행했을 때 얻은 기존 사용자와 역할을 복원합니다.

mongorestore ./adminDump --nsInclude "admin.*" --host <configPrimaryURI>

앞의 명령은 로컬 호스트 예외를 사용하여 인증 없이 관리 작업을 수행합니다.

이 명령을 실행하면 다음과 비슷한 결과가 나올 수 있습니다.

0 document(s) restored successfully

이 메시지는 문제를 나타내지 않습니다. 이 출력은 사용자 및 역할 이외의 0개의 문서가 복원되었음을 의미합니다.

보안 구성 서버 복제본 세트

구성 서버 복제본 세트를 재구성하고 다시 시작합니다.

1. Config 서버 재구성

   인증 메커니즘의 탭을 선택합니다.

   키 파일 인증

   x.509 인증

   다음 각 호스트에서 mongod 인스턴스를 다시 시작합니다.

   • mongodb7.example.net

   • mongodb8.example.net

   • mongodb9.example.net

   각 mongod 인스턴스에 대해 구성 파일에서 이러한 옵션을 지정합니다:

   옵션	값
   security.keyFile	초기 복제본 세트에 사용되는 키 파일의 경로입니다.

   security:
      keyFile: <PATH_TO_KEYFILE>
   replication:
      replSetName: configReplSet
   sharding:
      clusterRole: configsvr
   net:
      bindIp: localhost,<hostname(s)>

   배포에 적합한 추가 옵션을 포함하세요.

   다음 각 호스트에서 mongod 인스턴스를 다시 시작합니다.

   • mongodb7.example.net

   • mongodb8.example.net

   • mongodb9.example.net

   이미 구성한 mongod 옵션 외에도 각 인스턴스에 대한 구성 파일에서 다음 옵션을 지정하세요.

   옵션	값
   security.clusterAuthMode	x509
   net.tls.mode	requireTLS
   net.tls.certificateKeyFile	TLS 인증서와 키가 모두 포함된 .pem 파일의 절대 경로입니다.
   net.tls.CAFile	인증 기관의 루트 인증서 체인이 포함된 .pem 파일의 절대 경로입니다.
   net.bindIp	localhost, 그 뒤에 mongod가 클라이언트 연결을 수신해야 하는 다른 호스트 이름을 지정합니다. 경고: 공개적으로 액세스할 수 있는 IP 주소 에 인스턴스 를 바인딩하기 전에 무단 액세스 로부터 클러스터 를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버를 위한 보안 체크리스트를 참조하세요. 최소한 인증 을 활성화 하고 네트워크 인프라를 강화하는 것을 고려하세요.

   sharding:
      clusterRole: configsvr
   replication:
      replSetName: configReplSet
   security:
      clusterAuthMode: x509
   net:
      tls:
         mode: requireTLS
         certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
         CAFile: <CA_FILE>
      bindIp: localhost,<hostname(s)>

   TLS 인증서 키 파일이 비밀번호로 암호화된 경우 net.tls.certificateKeyFilePassword와 같이 배포에 적합한 추가 옵션을 포함합니다.

2. MongoDB 다시 시작

   지정된 구성으로 mongod를 다시 시작합니다.

   mongod --config <PATH_TO_CONFIG_FILE> --shutdown
   mongod --config <PATH_TO_CONFIG_FILE>

다음을 배포합니다. mongos

mongos는 클라이언트 애플리케이션과 샤딩된 클러스터 간의 인터페이스를 제공합니다.

1. mongos에 대한 구성 파일을 생성합니다.

   키 파일 인증

   x.509 인증

   mongos 구성 파일에 다음 옵션을 지정합니다.

   옵션	값
   sharding.configDB	configReplSet, 뒤에 슬래시 / 및 config 서버 호스트 이름 및 포트 중 최소 한 개가 이어집니다.
   security.keyFile	초기 복제본 세트에 사용되는 키 파일의 경로입니다.
   net.bindIp	localhost, 그 뒤에 mongos가 클라이언트 연결을 수신해야 하는 다른 호스트 이름을 지정합니다.

   sharding:
      configDB: configReplSet/mongodb7.example.net:27019,mongodb8.example.net:27019,mongodb9.example.net:27019
   security:
      keyFile: <PATH_TO_KEYFILE>
   net:
      bindIp: localhost,<hostname(s)>

   배포에 적합한 추가 옵션을 포함하세요.

   mongos 구성 파일에 다음 옵션을 지정합니다.

   옵션	값
   sharding.configDB	configReplSet, 뒤에 슬래시 / 및 config 서버 호스트 이름 및 포트 중 최소 한 개가 이어집니다.
   security.clusterAuthMode	x509
   net.tls.mode	requireTLS
   net.tls.certificateKeyFile	TLS 인증서와 키가 모두 포함된 .pem 파일의 절대 경로입니다.
   net.tls.CAFile	인증 기관의 루트 인증서 체인이 포함된 .pem 파일의 절대 경로입니다.
   net.bindIp	localhost, 그 뒤에 mongos가 클라이언트 연결을 수신해야 하는 다른 호스트 이름을 지정합니다.

   sharding:
      configDB: configReplSet/mongodb7.example.net:27019,mongodb8.example.net:27019,mongodb9.example.net:27019
   security:
      clusterAuthMode: x509
   net:
      tls:
         mode: requireTLS
         certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
         CAFile: <CA_FILE>
      bindIp: localhost,<hostname(s)>

   배포에 적합한 추가 옵션을 포함합니다.

2. mongos를 배포합니다.

   지정된 구성으로 mongos를 배포합니다.

   mongos --config <PATH_TO_CONFIG_FILE>

초기 복제본 세트를 샤드로 다시 시작

이 예시에서 초기 복제본 세트는 3명의 멤버로 구성된 복제본 세트입니다. 이 단계에서는 샤딩된 클러스터에 샤드로 추가될 수 있도록 초기 복제본 세트를 업데이트합니다.

복제본 세트는 다음과 같은 호스트에서 실행됩니다.

• mongodb0.example.net:27017

• mongodb1.example.net:27017

• mongodb2.example.net:27017

샤딩된 클러스터의 경우, 샤드의 각 mongod 인스턴스에 대한 역할을 shardsvr로 설정해야 합니다. 서버 역할을 설정하려면 mongod 구성 파일에서 sharding.clusterRole 설정을 적용합니다.

1. 초기 복제본 세트의 멤버에 연결합니다.

   mongosh를 사용하여 초기 복제본 세트의 멤버 중 하나에 연결합니다.

   키 파일 인증

   x.509 인증

   mongosh "mongodb://<username>@mongodb0.example.net:27017"

   배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.

   • --tls

   • --tlsCAFile

   • --tlsCertificateKeyFile

   예를 들면 다음과 같습니다.

   mongosh "mongodb://<username>@mongodb0.example.net:27017" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

2. 복제본 세트의 프라이머리 및 세컨더리를 결정합니다.

   rs.status() 실행하여 프라이머리 및 세컨더리를 합니다.

   rs.status()

   명령 출력에서 replSetGetStatus.members[n].stateStr 필드는 어떤 멤버가 프라이머리이고 어떤 멤버가 세컨더리 멤버인지를 나타냅니다.

3. --shardsvr 옵션으로 세컨더리를 다시 시작합니다.

   경고

   이 단계에서는 복제본 세트 세컨더리에 연결된 애플리케이션에 대해 약간의 중단 시간이 필요합니다.

   세컨더리 를 다시 시작한 후 초기 복제본 세트를 샤드로 추가의단계를 수행할 때까지 해당 세컨더리 에 연결된 모든 애플리케이션은 CannotVerifyAndSignLogicalTime 오류를 반환합니다.

   애플리케이션을 다시 시작하여 CannotVerifyAndSignLogicalTime 오류를 수신하지 않도록 할 수도 있습니다.

   키 파일 인증

   x.509 인증

   1. 세컨더리에 연결합니다.

      mongosh를 사용하여 세컨더리 중 하나에 연결합니다.

      mongosh "mongodb://<username>@<host>:<port>"

   2. 세컨더리를 종료합니다.

      다음 명령을 실행합니다.

      use admin
      db.shutdownServer()

   3. 세컨더리 구성 파일을 편집합니다.

      세컨더리 구성 파일에서 sharding.clusterRole를 shardsvr로 설정합니다.

      security:
         keyFile: <PATH_TO_KEYFILE>
      replication:
        replSetName: rs0
      sharding:
         clusterRole: shardsvr
      net:
         port: 27017
         bindIp: localhost,<hostname(s)>

      배포에 적합한 추가 옵션을 포함하세요.

   4. 세컨더리를 샤드 서버로 다시 시작합니다.

      세컨더리가 포함된 호스트에서 다음 명령을 실행합니다.

      mongod --config <PATH_TO_CONFIG_FILE>

   5. 다른 세컨더리에 대해 종료 및 재시작 단계를 반복합니다.

   1. 세컨더리에 연결합니다.

      mongosh를 사용하여 세컨더리 중 하나에 연결합니다.

      배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.

      • --tls

      • --tlsCAFile

      • --tlsCertificateKeyFile

      mongosh "mongodb://<username>@<host>:<port>" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

   2. 세컨더리를 종료합니다.

      다음 명령을 실행합니다.

      use admin
      db.shutdownServer()

   3. 세컨더리 구성 파일을 편집합니다.

      세컨더리 구성 파일에서 sharding.clusterRole를 shardsvr로 설정합니다.

      replication:
         replSetName: rs0
      sharding:
         clusterRole: shardsvr
      security:
         clusterAuthMode: x509
      net:
         port: 27017
         tls:
            mode: requireTLS
            certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
            CAFile: <CA_FILE>
         bindIp: localhost,<hostname(s)>

      TLS 인증서 키 파일이 비밀번호로 암호화된 경우 net.tls.certificateKeyFilePassword와 같이 배포에 적합한 추가 옵션을 포함합니다.

   4. 세컨더리를 샤드 서버로 다시 시작합니다.

      세컨더리가 포함된 호스트에서 다음 명령을 실행합니다.

      mongod --config <PATH_TO_CONFIG_FILE>

   5. 다른 세컨더리에 대해 종료 및 재시작 단계를 반복합니다.

옵션을 --shardsvr 사용하여 프라이머리 를 다시 시작합니다.

초기 복제본 세트를 샤드로 추가

초기 복제본 세트(rs0)를 샤드로 변환한 후 이를 샤딩된 클러스터에 추가합니다.

1. 클러스터의 관리 사용자로 mongos에 연결합니다.

   mongos 인스턴스가 호스트 mongodb6.example.net에서 실행 중입니다.

   키 파일 인증

   x.509 인증

   mongosh을 mongos에 연결하려면 다음 명령을 실행합니다:

   mongosh "mongodb://admin01@mongodb6.example.net:27017"

   배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.

   배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.

   • --tls

   • --tlsCAFile

   • --tlsCertificateKeyFile

   mongosh "mongodb://admin01@mongodb6.example.net:27017" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

   이 명령은 샤딩된 클러스터에서 생성한 admin01 사용자로 인증합니다. 명령을 입력한 후 사용자 비밀번호를 입력합니다.

2. 샤드를 추가합니다.

   클러스터에 샤드를 추가하려면 sh.addShard() 메서드를 실행합니다.

   sh.addShard( "rs0/mongodb0.example.net:27017,mongodb1.example.net:27017,mongodb2.example.net:27017" )

   경고

   새 샤드가 활성화되면 mongosh 및 다른 클라이언트는 항상 mongos 인스턴스에 연결해야 합니다. mongod 인스턴스에 직접 연결하지 마세요. 클라이언트가 샤드에 직접 연결하는 경우 데이터 또는 메타데이터 불일치가 발생할 수 있습니다.

애플리케이션 연결 string업데이트

클러스터에 첫 번째 샤드를 추가한 후, 애플리케이션에서 사용하는 연결 문자열을 샤딩된 클러스터의 연결 문자열로 업데이트합니다. 그런 다음 애플리케이션을 다시 시작합니다.

두 번째 복제본 세트 배포

rs1이라는 새 복제본 세트를 배포합니다. 복제본 세트 rs1의 멤버가 다음 호스트에 있습니다.

• mongodb3.example.net

• mongodb4.example.net

• mongodb5.example.net

1. 복제본 세트의 각 멤버를 시작합니다.

   키 파일 인증

   x.509 인증

   복제본 세트의 각 mongod 인스턴스에 대해 다음 옵션을 사용하여 구성 파일을 생성합니다.

   옵션	값
   security.keyFile	초기 복제본 세트에 사용되는 키 파일의 경로입니다.
   replication.replSetName	rs1
   sharding.clusterRole	shardsvr
   net.bindIp	localhost, 그 뒤에 mongod가 클라이언트 연결을 수신해야 하는 다른 호스트 이름을 지정합니다.

   security:
      keyFile: <PATH_TO_KEYFILE>
   replication:
      replSetName: rs1
   sharding:
      clusterRole: shardsvr
   net:
      bindIp: localhost,<hostname(s)>

   배포에 적합한 추가 옵션을 포함하세요.

   각 멤버에 대해 다음 옵션을 사용하여 mongod를 시작합니다.

   옵션	값
   replication.replSetName	rs1
   sharding.clusterRole	shardsvr
   security.clusterAuthMode	x509
   net.tls.mode	requireTLS
   net.tls.certificateKeyFile	TLS 인증서와 키가 모두 포함된 .pem 파일의 절대 경로입니다.
   net.tls.CAFile	인증 기관의 루트 인증서 체인이 포함된 .pem 파일의 절대 경로입니다.
   net.bindIp	localhost, 그 뒤에 mongod가 클라이언트 연결을 수신해야 하는 다른 호스트 이름을 지정합니다.

   replication:
      replSetName: rs1
   sharding:
      clusterRole: shardsvr
   security:
      clusterAuthMode: x509
   net:
      tls:
         mode: requireTLS
         certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
         CAFile: <CA_FILE>
      bindIp: localhost,<hostname(s)>

   지정된 구성으로 mongod를 배포합니다.

   mongod --config <PATH_TO_CONFIG_FILE>

   참고

   mongod 인스턴스에 대해 --shardsvr 옵션을 지정하면 인스턴스는 기본적으로 포트 27018에서 실행됩니다.

2. 복제본 세트의 각 멤버를 시작합니다.

3. 복제본 세트 멤버에 연결합니다.

   mongosh를 사용하여 복제본 세트 멤버 중 하나에 연결합니다. 예를 들면 다음과 같습니다.

   키 파일 인증

   x.509 인증

   mongosh "mongodb://mongodb3.example.net:27018"

   mongosh "mongodb://mongodb3.example.net:27018" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

4. 복제본 세트를 시작합니다.

   mongosh에서 rs.initiate() 메서드를 실행하여 현재 노드를 포함하는 복제본 세트를 시작합니다.

   rs.initiate( {
      _id : "rs1",
      members: [
          { _id: 0, host: "mongodb3.example.net:27018" },
          { _id: 1, host: "mongodb4.example.net:27018" },
          { _id: 2, host: "mongodb5.example.net:27018" }
      ]
   } )

   앞의 조치는 로컬 호스트 예외를 사용하여 인증 없이 관리 작업을 수행합니다.

   중요

   rs.initiate()를 복제본 세트의 단일 mongod 인스턴스에서만 실행합니다.

5. 복제본 세트에 대한 관리 사용자를 추가합니다.

   복제본 세트를 배포한 후 로컬 호스트 예외를 사용하여 복제본 세트의 첫 번째 사용자를 생성합니다.

   1. 복제본 세트의 프라이머리를 결정합니다.

      프라이머리를 결정하려면 rs.status()를 실행합니다.

      rs.status()

      명령 출력에서 replSetGetStatus.members[n].stateStr 필드는 어떤 멤버가 프라이머리인지 나타냅니다.

   2. 복제본 세트 프라이머리에 연결합니다.

      mongosh를 사용하여 복제본 세트 프라이머리에 연결합니다. 예를 들어 프라이머리가 mongodb4.example.net인 경우 이 명령을 실행합니다.

      키 파일 인증

      mongosh "mongodb://mongodb4.example.net:27018"

   3. 관리 사용자를 생성합니다.

      다음 db.createUser() 메서드를 실행하여 userAdmin 역할을 가진 rs1Admin이라는 사용자를 생성합니다.

      use admin
      db.createUser(
         {
            user: "rs1Admin",
            pwd: passwordPrompt(),
            roles: [
               { role: "userAdmin", db: "admin" }
            ]
         }
      )

      명령을 실행하면 rs1Admin 사용자의 암호를 입력하라는 메시지가 데이터베이스에 표시됩니다.

두 번째 복제본 세트를 샤드로 클러스터에 추가

새 복제본 세트 rs1을 샤딩된 클러스터에 추가합니다.

1. mongosh을 mongos에 연결합니다.

   명령줄에서 다음 명령을 실행하여 호스트 mongodb6.example.net에서 실행 중인 mongos 인스턴스에 연결합니다.

   키 파일 인증

   x.509 인증

   mongosh "mongodb://admin01@mongodb6.example.net:27017/admin"

   mongosh "mongodb://admin01@mongodb6.example.net:27017/admin" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

   이 명령은 샤딩된 클러스터에서 생성한 admin01 사용자로 인증합니다. 명령을 입력한 후 사용자 비밀번호를 입력합니다.

2. 두 번째 샤드를 추가합니다.

   mongos에 연결한 후, sh.addShard() 메서드를 사용하여 클러스터에 복제본 세트 rs1을 샤드로 추가합니다.

   sh.addShard( "rs1/mongodb3.example.net:27018,mongodb4.example.net:27018,mongodb5.example.net:27018" )

Collection 샤드

절차의 마지막 단계는 샤딩된 클러스터에서 컬렉션을 샤딩하는 것입니다.

1. 샤드 키를 결정합니다.

   컬렉션의 샤드 키를 결정합니다. 샤드 키는 MongoDB가 샤드 간에 문서를 배포하는 방법을 나타냅니다. 적절한 샤드 키는 다음과 같습니다.

   • 모든 문서에 균등하게 분산된 값이 있어야 합니다.

   • 동시에 자주 액세스되는 문서를 연속된 청크로 그룹화합니다.

   • 샤드 간에 활동을 효과적으로 분산할 수 있습니다.

   자세한 내용은 샤드 키 선택을 참조하세요.

   이 절차에서는 number 필드를 test_collection 컬렉션의 샤드 키로 사용합니다.

2. 샤드 키에 인덱스를 생성합니다.

   비어 있지 않은 컬렉션을 샤딩하기 전에 샤드 키에 인덱스를 생성하세요.

   use test
   db.test_collection.createIndex( { "number" : 1 } )

3. 컬렉션을 샤딩합니다.

   test 데이터베이스에서 test_collection을 샤딩합니다 number를 샤드 키로 지정합니다.

   sh.shardCollection( "test.test_collection", { "number" : 1 } )

   다음에 밸런서가 실행될 때 샤드 간에 문서 청크를 재배분합니다. 클라이언트가 이 컬렉션에 추가 문서를 삽입하면 mongos는 해당 문서를 적절한 샤드로 라우팅합니다.

   밸런서가 청크를 재분배하면 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니다. 성능에 미치는 영향을 최소화하기 위해 밸런서 실행 시기를 지정하여 사용량이 많은 시간에는 실행되지 않도록 할 수 있습니다. 자세히 알아보려면 밸런싱 기간 예약을 참조하세요.