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

이 페이지의 내용

개요

고려 사항
전제 조건
절차
자세히 알아보기

개요

이 튜토리얼에서는 3명의 멤버로 구성된 단일 복제본 세트를 2개의 샤드가 있는 샤드 클러스터로 변환합니다. 각 샤드는 독립적인 3개의 멤버로 구성된 복제본 세트입니다. 이 튜토리얼은 MongoDB 6.0 에만 해당됩니다. 다른 버전의 MongoDB에 대해서는 해당 버전의 MongoDB 매뉴얼을 참조하세요.

MongoDB Atlas에서 호스팅되는 배포서버에 대해 UI에서 샤딩된 클러스터로 변환할 수 있습니다.

고려 사항

이 절차의 개별 단계에서는 다운타임이 발생하는 시점을 명시합니다.

중요

이러한 절차로 인해 배포서버에 약간의 다운타임이 발생합니다.

전제 조건

이 튜토리얼에서는 mongos 에 서버 1대, 첫 번째 복제본 세트, 두 번째 복제본 세트 및 config 서버 복제본 세트에 각각 3개씩 총 10개의 서버 를 사용합니다.

각 서버에는 시스템 내에서 확인 가능한 도메인, 호스트 이름 또는 IP 주소가 있어야 합니다.

이 튜토리얼은 기본값 데이터 디렉토리를 사용합니다(예: /data/db 및 /data/configdb). 적절한 권한으로 적절한 디렉토리를 만듭니다. 다른 경로를 사용하려면 자체 관리 구성 파일 옵션 을 참조하세요.

절차

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

기존 사용자 및 역할을 가져오려면 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

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)>

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

Config 서버 시작
지정된 구성으로 mongod를 배포합니다.
```
mongod --config <PATH_TO_CONFIG_FILE>
```
config 서버는 기본 데이터 디렉토리 /data/configdb 및 기본 포트 27019를 사용합니다.
config 서버 중 하나에 연결합니다.
mongosh(을)를 사용하여 config 서버 중 하나에 연결합니다. 예를 들면 다음과 같습니다.
```
mongosh "mongodb://mongodb7.example.net:27019"
```

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" }
   ]
} )

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

중요

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

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

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

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

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

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

0 document(s) restored successfully

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

보안 구성 서버 복제본 세트

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

Config 서버 재구성

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

다음 각 호스트에서 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와 같이 배포에 적합한 추가 옵션을 포함합니다.

MongoDB 다시 시작
지정된 구성으로 mongod를 다시 시작합니다.
```
mongod --config <PATH_TO_CONFIG_FILE> --shutdown
mongod --config <PATH_TO_CONFIG_FILE>
```

다음을 배포합니다. `mongos`

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

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

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)>

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

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 설정을 적용합니다.

참고

shardsvr 역할을 가진 mongod 인스턴스의 기본 포트는 27018입니다. 다른 포트를 사용하려면 net.port 설정을 지정하세요.

초기 복제본 세트의 멤버에 연결합니다.
mongosh를 사용하여 초기 복제본 세트의 멤버 중 하나에 연결합니다.
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>
복제본 세트의 프라이머리 및 세컨더리를 결정합니다.
rs.status() 실행하여 프라이머리 및 세컨더리를 합니다.
```
rs.status()
```
명령 출력에서 replSetGetStatus.members[n].stateStr 필드는 어떤 멤버가 프라이머리이고 어떤 멤버가 세컨더리 멤버인지를 나타냅니다.

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

경고

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

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

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

세컨더리에 연결합니다.
mongosh를 사용하여 세컨더리 중 하나에 연결합니다.
```
mongosh "mongodb://<username>@<host>:<port>"
```
세컨더리를 종료합니다.
다음 명령을 실행합니다.
```
use admin
db.shutdownServer()
```
세컨더리 구성 파일을 편집합니다.
세컨더리 구성 파일에서 sharding.clusterRole를 shardsvr로 설정합니다.
```
security:
   keyFile: <PATH_TO_KEYFILE>
replication:
  replSetName: rs0
sharding:
   clusterRole: shardsvr
net:
   port: 27017
   bindIp: localhost,<hostname(s)>
```
배포에 적합한 추가 옵션을 포함하세요.
세컨더리를 샤드 서버로 다시 시작합니다.
세컨더리가 포함된 호스트에서 다음 명령을 실행합니다.
```
mongod --config <PATH_TO_CONFIG_FILE>
```
다른 세컨더리에 대해 종료 및 재시작 단계를 반복합니다.

세컨더리에 연결합니다.
mongosh를 사용하여 세컨더리 중 하나에 연결합니다.
배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.
```
mongosh "mongodb://<username>@<host>:<port>" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
```
세컨더리를 종료합니다.
다음 명령을 실행합니다.
```
use admin
db.shutdownServer()
```

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

세컨더리 구성 파일에서 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와 같이 배포에 적합한 추가 옵션을 포함합니다.

세컨더리를 샤드 서버로 다시 시작합니다.
세컨더리가 포함된 호스트에서 다음 명령을 실행합니다.
```
mongod --config <PATH_TO_CONFIG_FILE>
```
다른 세컨더리에 대해 종료 및 재시작 단계를 반복합니다.

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

경고

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

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

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

프라이머리에 연결합니다.
mongosh를 사용하여 프라이머리에 연결합니다.
```
mongosh "mongodb://<username>@<host>:<port>"
```
프라이머리을 내려놓습니다.
다음 명령을 실행합니다:
```
rs.stepDown()
```
강등이 완료되었는지 확인합니다.
rs.status()를 실행하여 연결된 멤버가 세컨더리로 변경되었는지 확인합니다.
```
rs.status()
```
이전 프라이머리를 종료합니다.
다음 명령을 실행합니다.
```
use admin
db.shutdownServer()
```
종료가 완료될 때까지 기다립니다.
프라이머리의 구성 파일을 편집합니다.
프라이머리 구성 파일에서 sharding.clusterRole을 shardsvr로 설정합니다.
```
security:
   keyFile: <PATH_TO_KEYFILE>
replication:
   replSetName: rs0
sharding:
   clusterRole: shardsvr
net:
   port: 27017
   bindIp: localhost,<hostname(s)>
```
배포에 적합한 추가 옵션을 포함하세요.
프라이머리를 샤드 서버로 다시 시작합니다.
프라이머리가 포함된 호스트에서 다음 명령을 실행합니다.
```
mongod --config <PATH_TO_CONFIG_FILE>
```

프라이머리에 연결합니다.
mongosh를 사용하여 세컨더리 중 하나에 연결합니다.
배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.
배포에 x.509 인증을 사용하는 경우 다음 mongosh 옵션을 지정하세요.
```
mongosh "mongodb://<username>@<host>:<port>" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
```
프라이머리을 내려놓습니다.
다음 명령을 실행합니다:
```
rs.stepDown()
```
강등이 완료되었는지 확인합니다.
rs.status()를 실행하여 연결된 멤버가 세컨더리로 변경되었는지 확인합니다.
```
rs.status()
```
이전 프라이머리를 종료합니다.
다음 명령을 실행합니다.
```
use admin
db.shutdownServer()
```
종료가 완료될 때까지 기다립니다.

프라이머리의 구성 파일을 편집합니다.

프라이머리 구성 파일에서 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와 같이 배포에 적합한 추가 옵션을 포함합니다.

프라이머리를 샤드 서버로 다시 시작합니다.
프라이머리가 포함된 호스트에서 다음 명령을 실행합니다.
```
mongod --config <PATH_TO_CONFIG_FILE>
```

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

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

클러스터의 관리 사용자로 mongos에 연결합니다.
mongos 인스턴스가 호스트 mongodb6.example.net에서 실행 중입니다.
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 사용자로 인증합니다. 명령을 입력한 후 사용자 비밀번호를 입력합니다.
샤드를 추가합니다.
클러스터에 샤드를 추가하려면 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

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

복제본 세트의 각 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에서 실행됩니다.

복제본 세트의 각 멤버를 시작합니다.
복제본 세트 멤버에 연결합니다.
mongosh를 사용하여 복제본 세트 멤버 중 하나에 연결합니다. 예를 들면 다음과 같습니다.
mongosh "mongodb://mongodb3.example.net:27018"
mongosh "mongodb://mongodb3.example.net:27018" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

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

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" }
   ]
} )

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

중요

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

복제본 세트에 대한 관리 사용자를 추가합니다.
복제본 세트를 배포한 후 로컬 호스트 예외를 사용하여 복제본 세트의 첫 번째 사용자를 생성합니다.
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을 샤딩된 클러스터에 추가합니다.

mongosh을 mongos에 연결합니다.
명령줄에서 다음 명령을 실행하여 호스트 mongodb6.example.net에서 실행 중인 mongos 인스턴스에 연결합니다.
mongosh "mongodb://admin01@mongodb6.example.net:27017/admin"
mongosh "mongodb://admin01@mongodb6.example.net:27017/admin" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
이 명령은 샤딩된 클러스터에서 생성한 admin01 사용자로 인증합니다. 명령을 입력한 후 사용자 비밀번호를 입력합니다.
두 번째 샤드를 추가합니다.
mongos에 연결한 후, sh.addShard() 메서드를 사용하여 클러스터에 복제본 세트 rs1을 샤드로 추가합니다.
```
sh.addShard( "rs1/mongodb3.example.net:27018,mongodb4.example.net:27018,mongodb5.example.net:27018" )
```

Collection 샤드

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

샤드 키를 결정합니다.
컬렉션의 샤드 키를 결정합니다. 샤드 키는 MongoDB가 샤드 간에 문서를 배포하는 방법을 나타냅니다. 적절한 샤드 키는 다음과 같습니다.
- 모든 문서에 균등하게 분산된 값이 있어야 합니다.
- 동시에 자주 액세스되는 문서를 연속된 청크로 그룹화합니다.
- 샤드 간에 활동을 효과적으로 분산할 수 있습니다.
자세한 내용은 샤드 키 선택을 참조하세요.
이 절차에서는 number 필드를 test_collection 컬렉션의 샤드 키로 사용합니다.
샤드 키에 인덱스를 생성합니다.
비어 있지 않은 컬렉션을 샤딩하기 전에 샤드 키에 인덱스를 생성하세요.
```
use test
db.test_collection.createIndex( { "number" : 1 } )
```
컬렉션을 샤딩합니다.
test 데이터베이스에서 test_collection을 샤딩합니다 number를 샤드 키로 지정합니다.
```
sh.shardCollection( "test.test_collection", { "number" : 1 } )
```
다음에 밸런서가 실행될 때 샤드 간에 문서 청크를 재배분합니다. 클라이언트가 이 컬렉션에 추가 문서를 삽입하면 mongos는 해당 문서를 적절한 샤드로 라우팅합니다.
밸런서가 청크를 재분배하면 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니다. 성능에 미치는 영향을 최소화하기 위해 밸런서 실행 시기를 지정하여 사용량이 많은 시간에는 실행되지 않도록 할 수 있습니다. 자세히 알아보려면 밸런싱 기간 예약을 참조하세요.

자세히 알아보기

샤딩 튜토리얼과 절차에 대한 자세한 내용은 이 페이지를 참조하세요.

돌아가기

샤딩된 클러스터를 복제본 세트로 변환

스토리지

개요

고려 사항

중요

전제 조건

절차

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

config 서버 복제본 세트 배포

중요

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

보안 구성 서버 복제본 세트

다음을 배포합니다. mongos

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

참고

경고

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

경고

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

경고

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

두 번째 복제본 세트 배포

참고

중요

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

Collection 샤드

자세히 알아보기

다음을 배포합니다. `mongos`

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