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

이 페이지의 내용

이 작업에 관한 정보

시작하기 전에
단계
자세히 알아보기

샤드 클러스터는 샤드 키 를 기반으로 여러 서버에 데이터를 분할합니다. 샤드 클러스터는 데이터 세트가 크고 작업 처리량이 많은 배포의 경우 복제본 세트보다 확장성이 뛰어납니다.

이 튜토리얼에서는 3명의 멤버로 구성된 단일 복제본 세트를 2개의 샤드가 있는 샤드 클러스터로 변환합니다. 새 클러스터의 각 샤드는 독립적인 3개의 멤버로 구성된 복제본 세트입니다.

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

이 작업에 관한 정보

이 튜토리얼의 일부 단계에서는 배포에 가동 중지 시간이 발생합니다. 개별 단계에서는 가동 중지 시간이 발생할 시기를 표시합니다.
이 튜토리얼은 인증이 활성화된 배포를 위한 것입니다.
이 튜토리얼에서는 구성 파일을 사용하여 서버 설정을 지정합니다. 구성 파일에는 mongod 및 mongos 명령줄 옵션에 해당하는 설정이 포함되어 있습니다.
이 튜토리얼을 통해 배포하는 샤드 클러스터에는 10개의 서버가 포함되어 있습니다.
- mongos에 대한 1개의 서버입니다.
- 클러스터에 있는 두 개의 샤드에 각각 3개의 서버(총 6개의 서버)가 필요합니다.
- config 서버 복제본 세트를 위한 3개의 서버입니다.

서버 아키텍처

이 튜토리얼에서는 다음 서버를 사용합니다.

호스트 이름	포트	설명
`mongodb0.example.net`	`27017`	초기 데이터 보유 샤드의 멤버 `rs0`입니다.
`mongodb1.example.net`	`27017`	초기 데이터 보유 샤드의 멤버 `rs0`입니다.
`mongodb2.example.net`	`27017`	초기 데이터 보유 샤드의 멤버 `rs0`입니다.
`mongodb3.example.net`	`27018`	두 번째 데이터 보유 샤드의 멤버 `rs1`입니다.
`mongodb4.example.net`	`27018`	두 번째 데이터 보유 샤드의 멤버 `rs1`입니다.
`mongodb5.example.net`	`27018`	두 번째 데이터 보유 샤드의 멤버 `rs1`입니다.
`mongodb6.example.net`	`27017`	샤드 클러스터에 연결하는 데 사용되는 `mongos`입니다.
`mongodb7.example.net`	`27019`	config 서버 복제본 세트의 입니다.
`mongodb8.example.net`	`27019`	config 서버 복제본 세트의 입니다.
`mongodb9.example.net`	`27019`	config 서버 복제본 세트의 입니다.

이 튜토리얼에 사용된 호스트 이름은 예시입니다. 예제 명령에 사용된 호스트 이름을 배포에 사용된 호스트 이름으로 바꿉니다.

중요

변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤드 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.

IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.

시작하기 전에

이 튜토리얼을 완료하려면 키파일 또는 x.509 인증서 인증을 사용하는 복제본 세트가 있어야 합니다. 이러한 인증 방법 중 하나를 사용하는 보안 복제본 세트를 배포하려면 다음 중 하나를 참조하세요.
- 키 파일 인증을 사용하여 자체 관리형 복제본 세트 배포
- x를 사용합니다. 자체 관리형 MongoDB를 사용한 멤버십 인증을 위한 509 인증서
이 튜토리얼에서는 기본 데이터 디렉토리 /data/db 및 /data/configdb를 사용합니다. 다른 경로를 사용하려면 구성 파일에서 storage.dbPath 설정을 적용하세요.

단계

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

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

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

2. config 서버 복제본 세트 배포

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

mongodb7.example.net
mongodb8.example.net
mongodb9.example.net

Config 서버 구성

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

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

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

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

구성 서버 시작

지정된 구성으로 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() 하나의 인스턴스에서만 를 실행합니다.

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

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

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

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

이 명령을 실행한 결과는 다음과 유사할 수 있습니다.

0 document(s) restored successfully

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

4. 보안 구성 서버 복제본 세트

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>

5. 다음을 배포합니다. `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>

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

이 예제에서 초기 복제본 세트는 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 옵션을 지정합니다.

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

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

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

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

rs.status()

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

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

경고

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

세컨더리를 다시 시작하면 7. 초기 복제본 세트를 샤드로 추가 단계를 수행할 때까지 해당 세컨더리에 연결된 모든 애플리케이션이 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` 사용하여 프라이머리를 다시 시작합니다.

경고

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

프라이머리를 다시 시작하면 7의 단계를 수행할 때까지 프라이머리에 연결된 모든 애플리케이션이 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 옵션을 지정합니다.

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>

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

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

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

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

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

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

배포에서 x를 사용하는 경우.509 인증의 경우 다음 mongosh 옵션을 지정합니다.

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 인스턴스에 직접 연결하지 마세요. 클라이언트가 샤드에 직접 연결하는 경우 데이터 또는 메타데이터 불일치가 발생할 수 있습니다.

8. 애플리케이션 연결 문자열 업데이트

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

9. 두 번째 복제본 세트 배포

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에서 실행됩니다.

복제본 세트의 다른 두 멤버에 대해 이전 단계를 `rs1` 반복합니다.

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

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() 하나의 인스턴스에서만 를 실행합니다.

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

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

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

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

rs.status()

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

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

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

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

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

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

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

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

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

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

새 복제본 세트 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" )

11. 컬렉션 샤드

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

샤드 키를 결정합니다.

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

모든 문서에 균등하게 분산된 값이 있어야 합니다.
동시에 자주 액세스되는 문서를 연속된 청크로 그룹화합니다.
샤드 간에 활동을 효과적으로 분산할 수 있습니다.

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

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

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

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

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

컬렉션을 샤딩합니다.

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

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

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

팁

밸런싱 기간 예약

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

자세히 알아보기

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

돌아가기

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

해시 샤드 키 인덱스 삭제

이 작업에 관한 정보

서버 아키텍처

중요

시작하기 전에

단계

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

2. config 서버 복제본 세트 배포

Config 서버 구성

구성 서버 시작

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

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

중요

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

4. 보안 구성 서버 복제본 세트

구성 서버 재구성

경고

MongoDB 다시 시작

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

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

mongos를 배포합니다.

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

참고

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

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

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

경고

세컨더리에 연결합니다.

세컨더리를 종료합니다.

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

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

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

세컨더리에 연결합니다.

세컨더리를 종료합니다.

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

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

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

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

경고

프라이머리에 연결합니다.

프라이머리을 내려놓습니다.

강등이 완료되었는지 확인합니다.

이전 프라이머리를 종료합니다.

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

프라이머리를 샤드 서버로 다시 시작합니다.

프라이머리에 연결합니다.

프라이머리을 내려놓습니다.

강등이 완료되었는지 확인합니다.

이전 프라이머리를 종료합니다.

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

프라이머리를 샤드 서버로 다시 시작합니다.

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

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

샤드를 추가합니다.

경고

8. 애플리케이션 연결 문자열 업데이트

9. 두 번째 복제본 세트 배포

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

참고

복제본 세트의 다른 두 멤버에 대해 이전 단계를 rs1 반복합니다.

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

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

중요

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

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

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

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

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

mongosh 을 에 mongos 연결합니다.

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

11. 컬렉션 샤드

샤드 키를 결정합니다.

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

컬렉션을 샤딩합니다.

팁

밸런싱 기간 예약

자세히 알아보기

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

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

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

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

복제본 세트의 다른 두 멤버에 대해 이전 단계를 `rs1` 반복합니다.

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