Docs Menu
Docs Home
/
MongoDB 매뉴얼
/ / / /

키 파일 인증을 사용하여 자체 관리형 샤드 클러스터 배포

이 페이지의 내용

  • 개요
  • 고려 사항
  • 키 파일 액세스 제어가 포함된 샤딩된 클러스터 배포
  • 다음 단계
  • x.509 내부 인증

샤딩된 클러스터 에 대한 액세스 제어를 적용하려면 다음을 구성해야 합니다.

  • 내부 인증을 사용하는 클러스터 구성 요소 간 보안

  • 사용자 액세스 제어를 사용하는 연결 클라이언트와 클러스터 간의 보안

이 튜토리얼에서는 샤딩된 클러스터의 각 멤버가 반드시 동일한 내부 인증 메커니즘과 설정을 사용해야 합니다. 즉, 클러스터의 mongosmongod 각각에 내부 인증을 시행해야 합니다.

다음 튜토리얼에서는 키 파일을 사용하여 내부 인증을 활성화합니다.

내부 인증을 설정하면 사용자 액세스 제어도 강화됩니다. 복제본 세트에 연결하려면 mongosh 와 같은 클라이언트는 사용자 계정 을 사용해야 합니다. 액세스 제어를 참조하세요.

Cloud Manager 또는 Ops Manager를 사용하여 배포를 관리하는 경우, 인증을 시행하려면 해당 Cloud Manager 매뉴얼 또는 Ops Manager 매뉴얼을 확인하세요.

중요

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

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

2} 및mongod mongos MongoDB localhost 바이너리는 기본적으로 에 바인딩됩니다.

키 파일은 최소한의 보안 형태이며, 테스트 또는 개발 환경에 가장 적합합니다. 프로덕션 환경에서는 x.509 인증서를 사용하는 것이 좋습니다.

이 자습서는 admin 데이터베이스에 최소한의 관리 사용자를 만드는 방법만 다룹니다. 사용자 인증에는 기본 SCRAM 인증 메커니즘을 사용합니다. 시도-응답 보안 메커니즘은 테스트 또는 개발 환경에 가장 적합합니다. 프로덕션 환경의 경우 x.509 인증서 또는 자체 관리형 LDAP 프록시 인증(MongoDB Enterprise에서만 사용 가능) 또는 자체 관리형 배포에서 Kerberos 인증(MongoDB Enterprise에서만 사용 가능)을 사용하는 것이 좋습니다.

특정 인증 메커니즘에 대한 사용자 생성에 대한 자세한 내용은 특정 인증 메커니즘 페이지를 참조하세요.

사용자 생성 및 관리에 대한 권장사항은 ➤ 역할 기반 액세스 제어 구성을 참조하세요.

일반적으로 샤딩된 클러스터에 대한 사용자를 생성하려면 mongos에 연결하여 샤딩된 클러스터 사용자를 추가합니다.

그러나 일부 유지 관리 작업에는 샤딩된 클러스터의 특정 샤드에 대한 직접 연결이 필요합니다. 이러한 작업을 수행하려면 샤드에 직접 연결하고 샤드 로컬 관리 사용자로 인증해야 합니다.

샤드 로컬 사용자는 특정 샤드에만 존재하며 샤드별 유지 관리 및 구성에만 사용해야 합니다. 샤드 로컬 사용자로는 mongos에 연결할 수 없습니다.

이 튜토리얼에서는 샤딩된 클러스터 사용자를 생성해야 하지만, 샤드 로컬 사용자를 추가하는 선택적 단계도 포함되어 있습니다.

자세한 내용은 자체 관리 배포서버의 사용자 보안 문서를 참조하세요.

이 튜토리얼에서는 mongodmongos 프로그램을 사용합니다. Windows 사용자는 대신 mongod.exemongos.exe 프로그램을 사용해야 합니다.

다음 절차에서는 mongos, config 서버 및 2개의 샤드로 구성된 새 샤딩된 클러스터를 생성합니다.

중요

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

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

키 파일 인증을 사용하면 샤딩된 클러스터의 각 mongod 또는 mongos 인스턴스는 배포에서 다른 멤버를 인증하기 위한 공유 암호로 키 파일의 내용을 사용합니다. 올바른 키 파일을 가진 mongod 또는 mongos 인스턴스만 샤딩된 클러스터에 참여할 수 있습니다.

참고

내부 멤버십 인증을 위한 키파일은 YAML 형식을 사용해 키파일에 여러 키를 허용합니다. YAML 형식은 다음 중 하나를 허용합니다.

  • 단일 키 문자열(이전 버전과 동일)

  • 키 문자열의 순서

YAML 형식은 텍스트 파일 형식을 사용하는 기존의 단일 키 키파일과 호환됩니다.

키 길이는 6~1024자 사이여야 하며 base64 세트의 문자만 포함할 수 있습니다. 샤딩된 클러스터의 모든 멤버는 하나 이상의 공통 키를 공유해야 합니다.

참고

UNIX 시스템에서는 키 파일에 그룹 또는 월드 권한이 없어야 합니다. Windows 시스템에서는 키 파일 권한이 확인되지 않습니다.

원하는 방법을 사용하여 키 파일을 생성할 수 있습니다. 예를 들어 다음 작업에서는 openssl 사용하여 공유 암호로 사용할 복잡한 의사 난수 1024자 문자열을 생성합니다. 그런 다음 chmod 사용하여 파일 소유자에게만 읽기 권한을 제공하도록 파일 권한을 변경합니다.

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

키파일 사용에 대한 추가 세부 정보 및 요구 사항은 키파일을 참조하세요.

샤딩된 클러스터 멤버를 호스팅하는 각 서버에 키 파일을 복사합니다. mongod 또는 mongos 인스턴스를 실행하는 사용자가 파일의 소유자이며 키 파일에 액세스할 수 있도록 합니다.

USB 드라이브 또는 네트워크 연결 저장 장치와 같이 mongod 또는 mongos인스턴스를 호스팅하는 하드웨어에서 쉽게 분리될 수 있는 저장 매체에 키 파일을 저장하지 마세요.

다음 단계는 config 서버 복제본 세트를 배포하는 단계입니다.

프로덕션 배포의 경우 멤버가 세 개 이상 포함된 config 서버 복제본 세트를 배포합니다. 테스트를 위해서 단일 멤버 복제본 세트를 생성할 수 있습니다.

1

config 서버 복제본 세트 에서 mongod 를 시작합니다. keyFile 설정을 포함합니다. keyFile 설정은 자체 관리 배포서버에서 자체 관리 내부/멤버십 인증역할 기반 액세스 제어를 모두 적용합니다.

구성 파일이나 명령줄을 통해 mongod 설정을 지정할 수 있습니다.

구성 파일

구성 파일을 사용하는 경우 security.keyFile을 키 파일의 경로로, sharding.clusterRoleconfigsvr로, replication.replSetName을 원하는 config 서버 복제본 세트의 이름으로 설정합니다.

security:
keyFile: <path-to-keyfile>
sharding:
clusterRole: configsvr
replication:
replSetName: <setname>

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트가 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 net.bindIp 설정을 지정하세요.

--config 옵션과 구성 파일 경로를 지정하여 mongod를 시작합니다.

mongod --config <path-to-config-file>

명령줄

명령줄 매개 변수를 사용하는 경우 --keyFile, --configsvr--replSet 매개 변수로 mongod를 시작합니다.

mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트를 배포에 연결하거나 배포 구성원이 다른 호스트에서 실행되도록 하려면 --bind_ip 를 지정합니다.

2

localhost 인터페이스를 통해 mongoshmongod 인스턴스 중 하나에 연결합니다. mongod 인스턴스와 동일한 물리적 컴퓨터에서 mongosh를 실행해야 합니다.

배포를 위해 생성된 사용자가 없기 때문에 로컬 호스트 인터페이스를 사용할 수 있습니다. 첫 번째 사용자 생성 후 localhost 인터페이스는 닫힙니다.

3

rs.initiate() 메서드는 복제본 세트를 시작하며 선택 사항인 복제본 세트 구성 문서를 받을 수 있습니다. 복제본 세트 구성 문서에는 다음을 포함합니다.

  • _id입니다. _id반드시 mongod으로 전달된 --replSet 매개 변수와 일치해야 합니다.

  • members 필드입니다. members 필드는 배열이며 복제본 세트의 각 멤버당 문서가 필요합니다.

  • configsvr 필드입니다. configsvr 필드는 반드시 config 서버 복제본 세트에 대해 true로 설정해야 합니다.

복제본 세트 구성 문서에 대한 자세한 내용은 자체 관리형 복제본 세트 구성 을 참조하세요.

rs.initiate() 메서드와 구성 문서를 사용하여 복제본 세트를 시작합니다.

rs.initiate(
{
_id: "myReplSet",
configsvr: true,
members: [
{ _id : 0, host : "cfg1.example.net:27019" },
{ _id : 1, host : "cfg2.example.net:27019" },
{ _id : 2, host : "cfg3.example.net:27019" }
]
}
)

참고

이 절차에서 config 서버 복제본 세트(CSRS)를 사용하려면 먼저 초기화가 완료될 때까지 기다려야 합니다. CSRS가 초기화되지 않은 경우 NotYetInitialized 오류가 발생합니다.

config 서버 복제본 세트(CSRS)가 시작되고 작동되면 샤드 복제본 세트 생성을 진행합니다.

프로덕션 배포에서는 멤버가 세 개 이상 포함된 복제본 세트를 사용하세요. 테스트를 위해서는 단일 멤버 복제본 세트를 생성할 수 있습니다.

이 단계에는 샤드 로컬 사용자를 추가하기 위한 선택적 절차가 포함되어 있습니다. 이제 이를 실행하면 각 샤드에 대해 샤드 수준 유지 관리를 수행할 수 있는 사용자가 확보됩니다.

1

keyFile 매개 변수와 함께 mongod 를 실행하면 자체 관리 배포서버에서 자체 관리 내부/멤버십 인증역할 기반 액세스 제어가 모두 적용됩니다.

구성 파일 또는 명령줄을 사용하여 복제본 세트의 mongod를 시작합니다.

구성 파일

구성 파일을 사용하는 경우 security.keyFile 옵션을 키 파일 경로로 설정하고, replication.replSetName 옵션을 원하는 복제본 세트 이름으로 설정하고, sharding.clusterRole 옵션을 shardsvr로 설정합니다.

security:
keyFile: <path-to-keyfile>
sharding:
clusterRole: shardsvr
replication:
replSetName: <replSetName>
storage:
dbPath: <path>

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트가 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 net.bindIp 설정을 지정하세요.

--config 옵션과 구성 파일 경로를 지정하여 mongod를 시작합니다.

mongod --config <path-to-config-file>

명령줄

명령줄 옵션을 사용하는 경우 해당 요소를 시작할 때 다음 예시와 같이 --keyFile, replSet--shardsvr 매개 변수를 지정합니다.

mongod --keyFile <path-to-keyfile> --shardsvr --replSet <replSetName> --dbpath <path>

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트를 배포에 연결하거나 배포 구성원이 다른 호스트에서 실행되도록 하려면 --bind_ip 를 지정합니다.

2

localhost 인터페이스를 통해 mongoshmongod 인스턴스 중 하나에 연결합니다. mongod 인스턴스와 동일한 물리적 컴퓨터에서 mongosh를 실행해야 합니다.

배포를 위해 생성된 사용자가 없기 때문에 로컬 호스트 인터페이스를 사용할 수 있습니다. 첫 번째 사용자 생성 후 localhost 인터페이스는 닫힙니다.

3

mongosh에서 rs.initiate() 메서드를 실행합니다.

rs.initiate()는 선택 사항으로 복제본 세트 구성 문서를 가져올 수 있습니다. 복제본 세트 구성 문서에 다음을 포함합니다.

  • _id 필드는 replication.replSetName 또는 --replSet 옵션에 지정된 복제본 세트 이름으로 설정됩니다.

  • 복제본 세트의 각 멤버에 대한 문서가 있는 members 배열.

다음 예는 멤버가 3명인 복제본 세트를 초기화하는 예시입니다.

rs.initiate(
{
_id : "myReplSet",
members: [
{ _id : 0, host : "s1-mongo1.example.net:27018" },
{ _id : 1, host : "s1-mongo2.example.net:27018" },
{ _id : 2, host : "s1-mongo3.example.net:27018" }
]
}
)

rs.initiate()투표를 트리거하고 멤버 중 하나를 프라이머리로 선출합니다.

계속하기 전에 프라이머리에 연결합니다. 프라이머리 멤버를 찾으려면 rs.status()를 사용하세요.

4

중요

첫 번째 사용자를 만든 후에는 로컬 호스트 예외를 더 이상 사용할 수 없습니다.

첫 번째 사용자는 userAdminAnyDatabase와 같은 다른 사용자를 만들 수 있는 권한이 있어야 합니다. 이렇게 하면 자체 관리형 배포의 Localhost 예외가 종료된 후 추가 사용자를 생성할 수 있습니다.

적어도 한 명의 사용자에게 사용자를 만들 수 있는 권한이 없는 경우 로컬 호스트 예외가 종료되면 새 권한으로 사용자를 만들거나 수정할 수 없으므로 필요한 작업에 액세스하지 못할 수 있습니다.

db.createUser() 메서드를 사용하여 사용자를 추가합니다. 사용자는 admin 데이터베이스에서 최소한 userAdminAnyDatabase 역할을 갖고 있어야 합니다.

사용자를 생성하려면 프라이머리에 연결되어 있어야 합니다.

다음 예에서는 admin 데이터베이스에 userAdminAnyDatabase 역할을 가진 fred 사용자를 만듭니다.

중요

시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.

메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell 에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

메시지가 표시되면 비밀번호를 입력합니다. 데이터베이스 관리 작업과 관련된 기본 제공 역할의 전체 목록은 데이터베이스 사용자 역할에서 확인하세요.

5

admin 데이터베이스에 인증합니다.

mongosh에서는 db.auth()를 사용하여 인증합니다. 예를 들어, 다음은 사용자 관리자 fred를 인증하는 방법입니다.

메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell 에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

또는 -u <username>, -p <password>--authenticationDatabase 매개 변수를 사용해 새로운 mongosh 인스턴스를 프라이머리 복제본 세트 구성원에 연결합니다.

mongosh -u "fred" -p --authenticationDatabase "admin"

-p 명령줄 옵션에 비밀번호를 지정하지 않으면 mongosh(이)가 비밀번호를 묻는 메시지를 표시합니다.

6

샤드 로컬 클러스터 관리자 사용자는 복제 작업에 액세스할 수 있는 권한을 제공하는 clusterAdmin 역할을 가집니다.

복제본 세트 작업과 관련된 전체 역할 목록은 클러스터 관리 역할에서 확인하세요.

클러스터 관리자 사용자를 만들고 admin 데이터베이스에서 clusterAdmin 역할을 할당합니다.

메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell 에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

db.getSiblingDB("admin").createUser(
{
"user" : "ravi",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)

메시지가 표시되면 비밀번호를 입력합니다.

복제본 세트 및 샤딩된 클러스터 작업과 관련된 기본 제공 역할의 전체 목록은 클러스터 관리 역할을 참조하세요.

1

구성 파일 또는 명령줄 매개 변수를 사용하여 키 파일을 지정하는 mongos를 시작합니다.

구성 파일

구성 파일을 사용하는 경우 security.keyFile을 키 파일의 경로로, sharding.configDB를 복제본 세트 이름으로 설정하고, 하나 이상의 복제본 세트 멤버를 <replSetName>/<host:port> 형식으로 설정합니다.

security:
keyFile: <path-to-keyfile>
sharding:
configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트가 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 net.bindIp 설정을 지정하세요.

--config 옵션과 구성 파일 경로를 지정하여 mongos를 시작합니다.

mongos --config <path-to-config>

명령줄

명령줄 매개 변수를 사용하는 경우 mongos를 시작하고 --keyFile--configdb 매개 변수를 지정합니다.

mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트를 배포에 연결하거나 배포 구성원이 다른 호스트에서 실행되도록 하려면 --bind_ip 를 지정합니다.

2

localhost 인터페이스를 통해 mongoshmongos 인스턴스 중 하나에 연결합니다. mongos 인스턴스와 동일한 물리적 컴퓨터에서 mongosh를 실행해야 합니다.

배포를 위해 생성된 사용자가 없기 때문에 로컬 호스트 인터페이스를 사용할 수 있습니다. 첫 번째 사용자 생성 후 localhost 인터페이스는 닫힙니다.

3

중요

첫 번째 사용자를 만든 후에는 로컬 호스트 예외를 더 이상 사용할 수 없습니다.

첫 번째 사용자는 userAdminAnyDatabase와 같은 다른 사용자를 만들 수 있는 권한이 있어야 합니다. 이렇게 하면 자체 관리형 배포의 Localhost 예외가 종료된 후 추가 사용자를 생성할 수 있습니다.

사용자를 생성할 권한이 없는 사용자가 한 명 이상인 경우, 로컬 호스트 예외가 종료되면 사용자를 생성하거나 수정할 수 없으므로 필요한 작업을 수행하지 못할 수 있습니다.

db.createUser() 메서드를 사용하여 사용자를 추가합니다. 사용자는 admin 데이터베이스에서 최소한 userAdminAnyDatabase 역할을 갖고 있어야 합니다.

중요

시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.

다음 예시에서는 admin 데이터베이스에 사용자 fred를 생성합니다.

메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell 에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

기본 제공 역할 및 데이터베이스 관리 작업과 관련된 역할의 전체 목록은 데이터베이스 사용자 역할에서 확인하세요.

4

db.auth()를 사용하여 사용자 관리자로 인증해 추가 사용자를 생성합니다.

메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell 에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

메시지가 표시되면 비밀번호를 입력합니다.

또는 -u <username>, -p <password>--authenticationDatabase "admin" 매개변수를 사용하여 새 mongosh 세션을 대상 복제본 세트 멤버에 연결합니다. 에 연결하려면 자체 관리 배포서버에서 로컬 호스트 예외를 mongos 사용해야 합니다.

mongosh -u "fred" -p --authenticationDatabase "admin"

-p 명령줄 옵션에 비밀번호를 지정하지 않으면 mongosh(이)가 비밀번호를 묻는 메시지를 표시합니다.

5

클러스터 관리자 사용자에게는 복제 및 샤딩 작업에 대한 액세스 권한을 부여하는 clusterAdmin 역할이 있습니다.

admin 데이터베이스에 clusterAdmin 사용자를 생성합니다.

다음 예시에서는 admin 데이터베이스에 사용자 ravi를 생성합니다.

중요

시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.

메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell 에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

db.getSiblingDB("admin").createUser(
{
"user" : "ravi",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)

복제본 세트 및 샤딩된 클러스터 작업과 관련된 기본 제공 역할의 전체 목록은 클러스터 관리 역할을 참조하세요.

6

클라이언트가 샤딩된 클러스터 에 연결하고 액세스 할 수 있도록 사용자를 생성합니다. 및 와 read 같은 사용 가능한 내장 제공 readWrite 역할은 데이터베이스 사용자 역할 을 참조하세요. 추가 관리 사용자가 필요할 수도 있습니다. 사용자에 대한 자세한 내용 은 자체 관리 배포서버의 사용자를 참조하세요.

추가 사용자를 생성하려면 userAdminAnyDatabase 또는 userAdmin 역할을 가진 사용자로 인증해야 합니다.

계속 진행하려면 mongos에 연결되어야 하며, 샤딩된 클러스터에 대한 클러스터 관리자 사용자로 인증되어야 합니다.

참고

이는 샤딩된 클러스터의 클러스터 관리자이며, 샤드 로컬 클러스터 관리자가 아닙니다.

클러스터에 각 샤드를 추가하려면 sh.addShard() 메서드를 사용합니다. 샤드가 복제본 세트인 경우 복제본 세트의 이름을 지정하고 세트의 멤버를 지정합니다. 프로덕션 배포에서는 모든 샤드가 복제본 세트여야 합니다.

다음 작업은 클러스터에 단일 샤드 복제본 세트를 추가합니다.

sh.addShard( "<replSetName>/s1-mongo1.example.net:27017")

다음 작업은 클러스터에 독립형 mongod 샤드를 추가하는 예시입니다.

sh.addShard( "s1-mongo1.example.net:27017")

클러스터에 모든 샤드가 포함될 때까지 이 단계를 반복합니다. 이때 샤딩된 클러스터는 클러스터뿐만 아니라 각 샤딩된 클러스터 구성 요소 간의 내부 통신에 대한 액세스 제어를 적용합니다.

계속 진행하려면 mongos에 연결되어야 하며, 샤딩된 클러스터에 대한 클러스터 관리자 사용자로 인증되어야 합니다.

참고

이는 샤딩된 클러스터의 클러스터 관리자이며, 샤드 로컬 클러스터 관리자가 아닙니다.

데이터베이스에서 샤딩을 활성화하면 데이터베이스 내에서 컬렉션을 샤딩할 수 있습니다. sh.enableSharding() 메서드를 사용하여 대상 데이터베이스에서 샤딩을 활성화합니다.

sh.enableSharding("<database>")

계속 진행하려면 mongos에 연결되어야 하며, 샤딩된 클러스터에 대한 클러스터 관리자 사용자로 인증되어야 합니다.

참고

이는 샤딩된 클러스터의 클러스터 관리자이며, 샤드 로컬 클러스터 관리자가 아닙니다.

컬렉션을 샤딩하려면 sh.shardCollection() 메서드를 사용합니다. 컬렉션의 전체 네임스페이스와 샤드 키가 포함된 문서를 지정해야 합니다.

샤드 키 선택은 샤딩의 효율성뿐만 아니라 구역과 같은 특정 샤딩 기능을 활용하는 능력에 영향을 미칩니다. 샤드 키 선택에 나열된 선택 고려 사항을 참고하세요.

컬렉션에 이미 데이터가 포함되어 있는 경우, shardCollection()을 사용하기 전에 db.collection.createIndex() 메서드를 사용하여 샤드 키에 인덱스를 생성해야 합니다.

컬렉션이 비어 있으면 MongoDB는 sh.shardCollection()의 일부로 인덱스를 생성합니다.

다음은 sh.shardCollection() 메서드의 예입니다.

sh.shardCollection("<database>.<collection>", { <key> : <direction> } )

클라이언트가 샤딩된 클러스터에 연결하여 상호 작용을 할 수 있도록 사용자를 생성합니다.

읽기 전용 및 읽기/쓰기 사용자를 생성할 때 활용할 수 있는 기본 제공 역할은 데이터베이스 사용자 역할에서 확인하세요.

내부 인증에 x.509를 사용하는 방법에 대한 자세한 내용은 자체 관리형 MongoDB의 멤버십 인증에 x.509 인증서 사용을 참조하세요.

키 파일 내부 인증 에서 x로 업그레이드 합니다.509 내부 인증, 키 파일 인증에서 자체 관리형 MongoDB 를 x로 업그레이드를 참조하세요.509 인증.

다음도 참조하세요.

돌아가기

복제본 세트 업데이트(다운타임 없음)