자체 관리형 샤드 클러스터 복원

이 페이지의 내용

고려 사항

A. (선택 사항) 복제본 세트 구성 검토하기
B. 복원을 위한 대상 호스트 준비
C. 구성 서버 복제본 세트 복원
D. 각 샤드 복제본 세트 복원
E. 각각 다시 시작 mongos
F. 클러스터 접근성 검증

이 절차는 LVM 스냅샷 과 같은 기존 백업 스냅샷에서 샤드 클러스터를 복원합니다. 소스 및 대상 샤드 클러스터에는 동일한 수의 샤드가 있어야 합니다. 샤드 클러스터의 모든 구성 요소에 대한 LVM 스냅샷을 만드는 방법에 대한 자세한 내용 은 파일 시스템 스냅샷으로 자체 관리형 샤드 클러스터 백업을 참조하세요.

참고

mongodump 및 mongorestore 를 샤드 클러스터의 백업 전략으로 사용하려면 데이터베이스 덤프를 사용하여 자체 관리형 샤드 클러스터 백업을 참조하세요.

또한 샤딩된 클러스터는 샤드 간 트랜잭션의 원자성 보장을 유지하는 다음과 같은 조정된 백업 및 복원 프로세스 중 하나를 사용할 수 있습니다.

고려 사항

AES256-GCM 암호화 모드를 사용하는 암호화된 스토리지 엔진의 경우 AES256-GCM은 모든 프로세스가 키와 함께 고유한 카운터 블록 값을 사용하도록 요구합니다.

2} 암호로 구성된 암호화된 스토리지 엔진의 경우: AES256-GCM

핫 백업에서 복원
4.2부터 "hot" 백업을 통해 가져온 파일에서 복원하는 경우(즉, mongod가 실행 중일 때), MongoDB는 시작 시 "더티" 키를 감지하고 데이터베이스 키를 자동으로 롤오버하여 IV(초기화 벡터) 재사용을 방지할 수 있습니다.
콜드 백업에서 복원
그러나 "cold" 백업을 통해 가져온 파일에서 복원하는 경우(즉, mongod가 실행 중이 아닌 경우), MongoDB는 시작 시 "더티" 키를 감지할 수 없으며, IV를 재사용하면 기밀성 및 무결성 보증이 무효화됩니다.
4.2부터 콜드 파일 시스템 스냅샷에서 복원한 후 키 재사용을 방지하기 위해 MongoDB는 새로운 명령줄 옵션 --eseDatabaseKeyRollover를 추가합니다. --eseDatabaseKeyRollover 옵션으로 시작하면 mongod 인스턴스는 AES256-GCM 암호로 구성된 데이터베이스 키를 롤오버하고 종료합니다.

팁

일반적으로 MongoDB Enterprise에 파일 시스템 기반 백업을 사용하는 경우 가능하면 핫 백업 기능을 사용하세요.

A. (선택 사항) 복제본 세트 구성 검토하기

이 절차는 기본 구성을 사용하여 구성 서버 복제본 세트(CSRS) 및 각 샤드 복제본 세트에 대한 새 복제본 세트를 시작합니다. 복원된 CSRS 및 샤드에 대해 다른 복제본 세트 구성을 사용하려면 복제본 세트를 재구성해야 합니다.

소스 클러스터가 정상이고 액세스할 수 있는 경우 mongo 셸을 각 복제본 세트의 프라이머리 복제본 세트 멤버에 연결하고 rs.conf()를 실행하여 복제 구성 문서를 봅니다.

소스 샤드 클러스터의 구성 요소 하나 이상에 액세스할 수 없는 경우 기존 내부 문서를 참조하여 각 샤드 복제본 세트 및 구성 서버 복제본 세트에 대한 구성 요건을 재구성합니다.

B. 복원을 위한 대상 호스트 준비

저장 공간 요구 사항

대상 호스트 하드웨어에 복원된 데이터를 위한 충분한 사용 가능한 스토리지 공간이 있는지 확인합니다. 대상 호스트에 보관하려는 기존 샤드 클러스터의 데이터가 포함되어 있는 경우 기존 데이터와 복원된 데이터 모두를 위한 스토리지 공간이 충분한지 확인합니다.

LVM 요구 사항

LVM 스냅샷의 경우, 추출된 스냅샷 데이터를 저장할 수 있는 충분한 여유 공간이 있는 논리 볼륨과 LVM 관리 볼륨 그룹이 하나 이상 있어야 합니다.

MongoDB 버전 요건

대상 호스트와 소스 호스트의 MongoDB 서버 버전이 동일한지 확인합니다. 호스트 시스템에서 사용할 수 있는 MongoDB의 버전을 확인하려면 터미널 또는 셸에서 mongod --version을 실행합니다.

설치에 대한 전체 문서는 MongoDB 설치를 참조하세요.

실행 중인 MongoDB 프로세스 종료

기존 클러스터로 복원하는 경우 대상 호스트에서 mongod 또는 mongos 프로세스를 종료합니다.

mongos를 실행하는 호스트의 경우 mongo 셸을 mongos에 연결하고 admin 데이터베이스에서 db.shutdownServer()를 실행합니다:

use admin
db.shutdownServer()

mongod를 실행하는 호스트의 경우 mongo 셸을 mongod에 연결하고 db.hello()를 실행합니다:

isWritablePrimary가 false인 경우 mongod는 복제본 세트의 세컨더리 멤버입니다. admin 데이터베이스에서 db.shutdownServer()를 실행하여 종료할 수 있습니다.
isWritablePrimary가 true인 경우, mongod는 복제본 세트의 프라이머리 멤버입니다. 먼저 복제본 세트의 세컨더리 멤버를 종료합니다. rs.status()를 사용하여 복제본 세트의 다른 멤버를 식별합니다.
프라이머리는 대부분의 멤버가 오프라인 상태임을 감지하면 자동으로 작동을 중단합니다. 프라이머리가 작동을 중단한 후에는(db.hello()가 isWritablePrimary: false를 반환) mongod를 안전하게 종료할 수 있습니다.

데이터 디렉토리 준비

복원된 데이터베이스 파일에 대해 대상 호스트에 디렉토리를 만듭니다. mongod를 실행하는 사용자에게 해당 디렉토리의 모든 파일 및 하위 폴더에 대한 읽기, 쓰기 및 실행 권한이 있는지 확인합니다:

sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb

/path/to/mongodb를 생성한 데이터 디렉토리의 경로로 대체합니다. RHEL/CentOS, Amazon Linux 및 SUSE에서 기본 사용자 이름은 mongod입니다.

로그 디렉토리 준비

대상 호스트에 mongod 로그 파일의 디렉토리를 생성합니다. mongod를 실행하는 사용자에게 해당 디렉토리의 모든 파일 및 하위 폴더에 대한 읽기, 쓰기 및 실행 권한이 있는지 확인합니다.

sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs

/path/to/mongodb/logs를 사용자가 만든 로그 디렉토리 경로로 대체합니다. RHEL/CentOS, Amazon Linux 및 SUSE에서 기본 사용자 이름은 mongod입니다.

구성 파일 만들기

이 절차에서는 구성 파일로 mongod를 시작한다고 가정합니다.

원하는 위치에 구성 파일을 만듭니다. mongod를 실행하는 사용자에게 구성 파일에 대한 읽기 및 쓰기 권한이 있는지 확인합니다:

sudo touch /path/to/mongod.conf
sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf
sudo chmod 644 /path/to/mongodb/mongod.conf

RHEL/CentOS, Amazon Linux 및 SUSE에서 기본 사용자 이름은 mongod입니다.

원하는 텍스트 편집기에서 구성 파일을 열고 배포에 필요한 대로 수정합니다. 또는 mongod의 원본 구성 파일에 액세스할 수 있는 경우 해당 파일을 대상 호스트의 원하는 위치에 복사합니다.

중요

구성 파일에 다음 설정이 포함되어 있는지 확인합니다.

storage.dbPath 를 원하는 데이터 디렉토리 경로로 설정해야 합니다.
systemLog.path 를 원하는 로그 디렉터리 경로로 설정해야 합니다.
net.bindIp 에는 호스트 시스템의 IP 주소가 포함되어야 합니다.
replication.replSetName 은 주어진 복제본 세트의 각 멤버에서 동일한 값을 갖습니다.
sharding.clusterRole 은 주어진 복제본 세트의 각 멤버에서 동일한 값을 갖습니다.
또한 스냅샷에 지정된 것과 동일한 시작 옵션을 새 배포서버에 지정해야 합니다.

C. 구성 서버 복제본 세트 복원

CSRS 프라이머리 `mongod` 데이터 파일을 복원합니다.

원하는 백업 방법에 해당하는 탭을 선택합니다.

대상 호스트 머신에 LVM 스냅샷을 마운트합니다. LVM 스냅샷을 마운트하는 구체적인 단계는 LVM 구성에 따라 다릅니다.
다음 예제에서는 파일 시스템 스냅샷을 사용하여 자체 관리 배포서버 백업 및 복원 절차 의 스냅 샷 생성 단계를 사용하여 LVM 스냅샷을 생성했다고 가정합니다.
```
lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb
```
이 예제는 가능한 모든 LVM 구성에 적용되지 않을 수 있습니다. LVM 복원에 관한 자세한 지침은 해당 시스템의 LVM 설명서에서 확인하세요.
스냅샷 마운트의 mongod 데이터 파일을 B. Prepare the Target Host for Restoration 에서 생성된 데이터 디렉토리로 복사합니다.
```
cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb
```
-a 옵션은 폴더 및 파일 권한을 유지하면서 소스 경로의 내용을 대상 경로에 재귀적으로 복사합니다.
다음 구성 파일 설정을 주석 처리하거나 생략합니다.
```
#replication
#  replSetName: myCSRSName
#sharding
#  clusterRole: configsvr
```
구성 파일을 사용하여 mongod을(를) 시작하려면 명령줄에 구성 파일의 전체 경로를 지정하는 --config 옵션을 지정합니다.
```
mongod --config /path/to/mongodb/mongod.conf
```
mongod를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
mongod가 시작되면 mongo 셸을 사용하여 연결합니다.

선택한 백업 미디어에 저장된 데이터 파일을 호스트에서 액세스할 수 있도록 합니다. 이를 위해서는 백업 볼륨을 마운트하거나, 소프트웨어 유틸리티에서 백업을 열거나, 다른 도구를 사용하여 데이터를 디스크에서 추출해야 할 수 있습니다. 백업에 포함된 데이터에 액세스하는 방법에 대한 지침은 선호하는 백업 도구의 설명서를 참조하세요.
백업 데이터 위치의 mongod 데이터 파일을 B. Prepare the Target Host for Restoration 에서 생성된 데이터 디렉토리로 복사합니다.
```
cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb
```
-a 옵션은 폴더 및 파일 권한을 유지하면서 소스 경로의 내용을 대상 경로에 재귀적으로 복사합니다.

다음 구성 파일 설정을 주석 처리하거나 생략합니다.

#replication
#  replSetName: myCSRSName
#sharding
#  clusterRole: configsvr

구성 파일을 사용하여 mongod을(를) 시작하려면 명령줄에 구성 파일의 전체 경로를 지정하는 --config 옵션을 지정합니다.
```
mongod --config /path/to/mongodb/mongod.conf
```
참고
Cloud Manager 또는 Ops Manager 전용
Cloud Manager 또는 Ops Manager 백업의 수동 복원을 수행하는 경우 시작하기 전에 disableLogicalSessionCacheRefresh 서버 매개 변수를 지정해야 합니다.
mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true
mongod를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
mongod가 시작되면 mongo 셸을 사용하여 연결합니다.

데이터베이스를 `local` 삭제합니다.

db.dropDatabase()를 사용하여 local 데이터베이스를 삭제합니다.

use local
db.dropDatabase()

계획되거나 완료된 샤드 호스트 이름 또는 복제본 세트 이름 변경의 경우 에서 메타데이터를 `config.shards` 업데이트합니다.

다음 사항이 모두 해당되는 경우 이 단계를 건너뛸 수 있습니다:

이 절차 중에는 샤드 구성원 호스트 시스템 호스트 이름이 변경되지 않습니다.
이 절차 중에는 샤드 복제본 세트 이름이 변경되지 않습니다.

구성 데이터베이스의 shards 컬렉션에서 다음 find() 메서드를 실행합니다. <shardName>을 샤드 이름으로 바꿉니다. 기본적으로 샤드 이름은 해당 복제본 세트의 이름입니다. addShard 명령을 사용하여 샤드를 추가하고 동시에 사용자 지정 name을 지정한 경우, <shardName>에서 해당 name을 지정해야 합니다.

use config
db.shards.find( { "_id" : "<shardName>" } )

이 작업은 다음과 유사한 문서를 반환합니다.

{
   "_id" : "shard1",
   "host" : "myShardName/alpha.example.net:27018,beta.example.net:27018,charlie.example.net:27018",
   "state" : 1
}

중요

_id 값은 해당 샤드에 있는 _id : "shardIdentity" 문서의 shardName 값과 일치해야 합니다. 이 절차의 후반부에서 샤드를 복원할 때 shards의 _id 필드가 샤드의 shardName 값과 일치하는지 확인합니다.

updateOne() 메서드를 사용하여 hosts 문자열을 업데이트하여 샤드의 계획된 복제본 세트 이름 및 호스트 이름 목록을 반영합니다. 예를 들어 다음 작업은 샤드의 host 연결 문자열을 "_id" : "shard1"로 업데이트합니다.

db.shards.updateOne(
  { "_id" : "shard1" },
  { $set : { "host" : "myNewShardName/repl1.example.net:27018,repl2.example.net:27018,repl3.example.net:27018" } }
)

모든 샤드 메타데이터가 클러스터의 각 샤드에 대해 계획된 복제본 세트 이름과 호스트 이름 목록을 정확하게 반영할 때까지 이 과정을 반복합니다.

참고

샤드 이름을 모르는 경우, 빈 필터 문서 {}를 사용하여 shards 컬렉션에서 find() 메서드를 실행합니다:

use config
db.shards.find({})

결과 세트의 각 문서는 클러스터의 샤드 하나를 나타냅니다. 각 문서에 대해 host 필드에서 해당 샤드와 일치하는 연결 문자열, 즉 일치하는 복제본 세트 이름과 멤버 호스트 이름 목록을 확인합니다. <shardName> 대신 해당 문서의 _id를 사용합니다.

를 `mongod` 새 단일 노드 복제본 세트로 다시 시작합니다.

mongod를 종료합니다. 다음 구성 파일 옵션의 주석을 제거하거나 추가합니다.

replication
  replSetName: myNewCSRSName
sharding
  clusterRole: configsvr

복제본 세트 이름을 변경하려면 계속 진행하기 전에 replSetName 필드를 새 이름으로 업데이트해야 합니다.

업데이트된 구성 파일로 mongod를 시작합니다.

mongod --config /path/to/mongodb/mongod.conf

mongod를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.

mongod가 시작되면 mongo 셸을 사용하여 연결합니다.

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

기본 설정 및 rs.initiate()를 사용하여 복제본 세트를 시작합니다.

rs.initiate()

작업이 완료되면 rs.status()를 사용하여 멤버가 프라이머리가 되었는지 확인합니다.

복제본 세트 멤버를 추가합니다.

CSRS의 각 복제본 세트 멤버에 대해 해당 호스트 시스템에서 mongod를 시작합니다. 클러스터의 나머지 멤버를 모두 성공적으로 시작했다면 mongo 셸을 프라이머리 복제본 세트 멤버에 연결합니다. 프라이머리에서 rs.add() 메서드를 사용하여 복제본 세트의 각 멤버를 추가합니다. 접두사로 복제본 세트 이름을 포함하고, 그 뒤에 멤버의 mongod 프로세스의 호스트 이름과 포트를 포함합니다:

rs.add("config2.example.net:27019")
rs.add("config3.example.net:27019")

특정 복제본 member 구성 설정이 있는 멤버를 추가하려면 멤버 호스트 이름과 배포에 필요한 members 설정을 정의하는 문서를 rs.add()에 전달하면 됩니다.

rs.add(
 {
   "host" : "config2.example.net:27019",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

각각의 새 멤버는 프라이머리를 따라잡기 위해 초기 동기화를 수행합니다. 동기화할 데이터의 양, 네트워크 토폴로지 및 상태, 각 호스트 시스템의 전원 등의 요인에 따라 초기 동기화를 완료하는 데 시간이 오래 걸릴 수 있습니다.

멤버를 추가하는 동안 복제본 세트가 새 프라이머리를 선출할 수 있습니다. rs.status()를 사용하여 현재 프라이머리인 멤버를 식별합니다. 프라이머리에서는 rs.add()만 실행할 수 있습니다.

필요한 추가 복제 설정을 구성합니다.

rs.reconfig() 메서드는 매개 변수로 전달된 구성 문서를 기반으로 복제본 세트 구성을 업데이트합니다. 복제본 세트의 프라이머리 멤버에 대해 reconfig()를 실행해야 합니다.

A. Review Replica Set Configurations 단계에서 식별한 대로 복제본 세트의 원래 구성 파일 출력을 참조하고 필요에 따라 설정을 적용합니다.

D. 각 샤드 복제본 세트 복원

샤드 프라이머리 `mongod` 데이터 파일을 복원합니다.

원하는 백업 방법에 해당하는 탭을 선택합니다.

대상 호스트 머신에 LVM 스냅샷을 마운트합니다. LVM 스냅샷을 마운트하는 구체적인 단계는 LVM 구성에 따라 다릅니다.
다음 예제에서는 파일 시스템 스냅샷을 사용하여 자체 관리 배포서버 백업 및 복원 절차 의 스냅 샷 생성 단계를 사용하여 LVM 스냅샷을 생성했다고 가정합니다.
```
lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb
```
이 예제는 가능한 모든 LVM 구성에 적용되지 않을 수 있습니다. LVM 복원에 관한 자세한 지침은 해당 시스템의 LVM 설명서에서 확인하세요.
mongod 데이터 파일을 스냅샷 마운트에서 B. Prepare the Target Host for Restoration에 생성한 데이터 디렉토리로 복사합니다.
```
cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb
```
-a 옵션은 폴더 및 파일 권한을 유지하면서 소스 경로의 내용을 대상 경로에 재귀적으로 복사합니다.
다음 구성 파일 설정을 주석 처리하거나 생략합니다.
```
#replication
#  replSetName: myShardName
#sharding
#  clusterRole: shardsvr
```
구성 파일을 사용하여 mongod을(를) 시작하려면 명령줄에 구성 파일의 전체 경로를 지정하는 --config 옵션을 지정합니다.
```
mongod --config /path/to/mongodb/mongod.conf
```
mongod를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
mongod가 시작되면 mongo 셸을 사용하여 연결합니다.

선택한 백업 미디어에 저장된 데이터 파일을 호스트에서 액세스할 수 있도록 합니다. 이를 위해서는 백업 볼륨을 마운트하거나, 소프트웨어 유틸리티에서 백업을 열거나, 다른 도구를 사용하여 데이터를 디스크에서 추출해야 할 수 있습니다. 백업에 포함된 데이터에 액세스하는 방법에 대한 지침은 선호하는 백업 도구의 설명서를 참조하세요.
백업 데이터 위치의 mongod 데이터 파일을 B. Prepare the Target Host for Restoration 에서 생성된 데이터 디렉토리로 복사합니다.
```
cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb
```
-a 옵션은 폴더 및 파일 권한을 유지하면서 소스 경로의 내용을 대상 경로에 재귀적으로 복사합니다.

다음 구성 파일 설정을 주석 처리하거나 생략합니다.

#replication
#  replSetName: myShardName
#sharding
#  clusterRole: shardsvr

구성 파일을 사용하여 mongod을(를) 시작하려면 명령줄에 구성 파일의 전체 경로를 지정하는 --config 옵션을 지정합니다.
```
mongod --config /path/to/mongodb/mongod.conf
```
참고
Cloud Manager 또는 Ops Manager 전용
Cloud Manager 또는 Ops Manager 백업의 수동 복원을 수행하는 경우 시작하기 전에 disableLogicalSessionCacheRefresh 서버 매개 변수를 지정해야 합니다.
mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true
mongod를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
mongod가 시작되면 mongo 셸을 사용하여 연결합니다.

역할을 가진 임시 `__system` 사용자를 만듭니다.

이 절차를 수행하는 동안 admin.system.version 컬렉션의 문서를 수정합니다. 인증을 적용하는 클러스터의 경우 __system 역할에만 이 컬렉션을 수정할 수 있는 권한이 부여됩니다. 클러스터에서 인증을 적용하지 않는 경우 이 단계를 건너뛸 수 있습니다.

경고

__system 역할은 소유자에게 데이터베이스의 모든 객체에 대해 모든 작업을 수행할 수 있는 권한을 부여합니다. 이 절차에는 이 단계에서 생성한 사용자를 제거하는 방법이 포함되어 있습니다. 이 절차의 범위를 초과하여 이 사용자를 활성 상태로 유지하지 마세요.

지정된 호스트만 권한 있는 사용자로 인증할 수 있도록 구성된 clientSource 인증 제한을 사용하여 이 사용자를 만드는 것을 고려합니다.

admin 데이터베이스에서 userAdmin 역할 또는 userAdminAnyDatabase 역할을 가진 사용자로 인증합니다:
```
use admin
db.auth("myUserAdmin","mySecurePassword")
```
__system 역할을 가진 사용자를 생성합니다.
```
db.createUser(
  {
    user: "mySystemUser",
    pwd: "<replaceMeWithAStrongPassword>",
    roles: [ "__system" ]
  }
)
```
시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.

권한이 있는 사용자로 인증합니다:

db.auth("mySystemUser","<replaceMeWithAStrongPassword>")

데이터베이스를 `local` 삭제합니다.

db.dropDatabase()를 사용하여 local 데이터베이스를 삭제합니다.

use local
db.dropDatabase()

컬렉션에서 `minOpTimeRecovery` 문서를 `admin.system.versions` 제거합니다.

샤드 내부를 업데이트하려면 admin 데이터베이스의 system.version 컬렉션에서 다음 deleteOne() 메서드를 실행합니다:

use admin
db.system.version.deleteOne( { _id: "minOpTimeRecovery" } )

참고

system.version 컬렉션은 내부 시스템 컬렉션입니다. 이와 같은 구체적인 지침이 있을 때만 수정해야 합니다.

선택 사항: CSRS 호스트 이름 또는 복제 세트 이름 변경의 경우 각 샤드의 ID 문서에서 샤드 메타데이터를 업데이트합니다.

다음 사항이 모두 해당되는 경우 이 단계를 건너뛸 수 있습니다:

이 절차 중에 CSRS 호스트의 호스트 이름이 변경되지 않았습니다.
이 절차 중에 CSRS 복제본 세트 이름이 변경되지 않았습니다.

admin 데이터베이스의 system.version 컬렉션에 CSRS 연결 문자열을 포함하여 샤드와 관련된 메타데이터가 포함되어 있습니다. CSRS를 복원하는 동안 CSRS 이름 또는 멤버 호스트 이름이 변경된 경우 이 메타데이터를 업데이트해야 합니다.

admin 데이터베이스의 system.version 컬렉션에서 다음 find() 메서드를 실행합니다:

use admin
db.system.version.find( {"_id" : "shardIdentity" } )

find() 메서드는 다음과 유사한 문서를 반환합니다:

{
  "_id" : "shardIdentity",
  "clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
  "shardName" : "shard1",
  "configsvrConnectionString" : "myCSRSName/alpha.example.net:27019,beta.example.net:27019,charlie.example.net:27019" }

다음 updateOne() 메서드는 host 문자열이 가장 최신 CSRS 연결 문자열을 나타내도록 문서를 업데이트합니다:

db.system.version.updateOne(
  { "_id" : "shardIdentity" },
  { $set :
    { "configsvrConnectionString" : "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"}
  }
)

중요

shardName 값은 CSRS의 shards 컬렉션에 있는 _id 값과 일치해야 합니다. CSRS의 메타데이터가 샤드의 메타데이터와 일치하는지 확인합니다. CSRS 메타데이터를 보는 방법에 대한 지침은 이 절차의 C. Restore Config Server Replica Set 부분에 있는 3 하위 단계를 참조하세요.

를 `mongod` 새 단일 노드 복제본 세트로 다시 시작합니다.

mongod를 종료합니다. 다음 구성 파일 옵션의 주석을 제거하거나 추가합니다.

replication
  replSetName: myNewShardName
sharding
  clusterRole: shardsvr

복제본 세트 이름을 변경하려면 계속 진행하기 전에 replSetName 필드를 새 이름으로 업데이트해야 합니다.

업데이트된 구성 파일로 mongod를 시작합니다.

mongod --config /path/to/mongodb/mongod.conf

mongod를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.

mongod가 시작되면 mongo 셸을 사용하여 연결합니다.

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

기본 설정 및 rs.initiate()를 사용하여 복제본 세트를 시작합니다.

rs.initiate()

작업이 완료되면 rs.status()를 사용하여 멤버가 프라이머리가 되었는지 확인합니다.

복제본 세트 멤버를 추가합니다.

샤드 복제본 세트의 각 복제본 세트 멤버에 대해 해당 호스트 시스템에서 mongod를 시작합니다. 클러스터의 나머지 멤버를 모두 성공적으로 시작했다면 mongo 셸을 프라이머리 복제본 세트 멤버에 연결합니다. 프라이머리에서 rs.add() 메서드를 사용하여 복제본 세트의 각 멤버를 추가합니다. 접두사로 복제본 세트 이름을 포함하고, 그 뒤에 멤버의 mongod 프로세스의 호스트 이름과 포트를 포함합니다:

rs.add("repl2.example.net:27018")
rs.add("repl3.example.net:27018")

rs.add(
 {
   "host" : "repl2.example.net:27018",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

필요한 추가 복제 설정을 구성합니다.

A. Review Replica Set Configurations 단계에서 식별한 대로 복제본 세트의 원래 구성 파일 출력을 참조하고 필요에 따라 설정을 적용합니다.

임시 권한 사용자를 제거합니다.

인증을 시행하는 클러스터의 경우 이 절차의 앞부분에서 생성된 권한 있는 사용자를 제거합니다.

admin 데이터베이스에서 userAdmin 역할 또는 userAdminAnyDatabase 역할을 가진 사용자로 인증합니다:
```
use admin
db.auth("myUserAdmin","mySecurePassword")
```
권한 있는 사용자를 삭제합니다:
```
db.removeUser("mySystemUser")
```

E. 각각 다시 시작 `mongos`

클러스터에서 각 mongos를 다시 시작합니다.

mongos --config /path/to/config/mongos.conf

배포에 필요한 다른 모든 명령줄 옵션을 포함합니다.

CSRS 복제본 세트 이름 또는 멤버 호스트 이름이 변경된 경우 mongos 구성 파일 설정 sharding.configDB를 업데이트된 구성 서버 연결 문자열로 업데이트합니다:

sharding:
  configDB: "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"

F. 클러스터 접근성 검증

mongo 셸을 클러스터의 mongos 프로세스 중 하나에 연결합니다. sh.status()를 사용하여 전체 클러스터 상태를 확인합니다. sh.status()가 밸런서가 실행되고 있지 않음을 나타내면 sh.startBalancer()를 사용하여 밸런서를 다시 시작합니다. [1]

모든 샤드에 액세스할 수 있고 통신할 수 있는지 확인하려면 임시 샤드 컬렉션에 테스트 데이터를 삽입합니다. 데이터가 클러스터의 각 샤드 간에 분할 및 마이그레이션되고 있는지 확인합니다. mongo 셸을 각 샤드 프라이머리에 연결하고 db.collection.find()를 사용하여 데이터가 예상대로 샤드되었는지 확인할 수 있습니다.

[1]	MongoDB 4.2부터 `sh.startBalancer()` 는 샤딩된 cluster에 대한 자동 분할도 활성화합니다.

돌아가기

백업 예약

독립형 복구

참고

고려 사항

팁

A. (선택 사항) 복제본 세트 구성 검토하기

B. 복원을 위한 대상 호스트 준비

중요

C. 구성 서버 복제본 세트 복원

CSRS 프라이머리 mongod 데이터 파일을 복원합니다.

참고

Cloud Manager 또는 Ops Manager 전용

데이터베이스를 local 삭제합니다.

계획되거나 완료된 샤드 호스트 이름 또는 복제본 세트 이름 변경의 경우 에서 메타데이터를 config.shards 업데이트합니다.

중요

참고

를 mongod 새 단일 노드 복제본 세트로 다시 시작합니다.

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

복제본 세트 멤버를 추가합니다.

필요한 추가 복제 설정을 구성합니다.

D. 각 샤드 복제본 세트 복원

샤드 프라이머리 mongod 데이터 파일을 복원합니다.

참고

Cloud Manager 또는 Ops Manager 전용

역할을 가진 임시 __system 사용자를 만듭니다.

경고

데이터베이스를 local 삭제합니다.

컬렉션에서 minOpTimeRecovery 문서를 admin.system.versions 제거합니다.

참고

선택 사항: CSRS 호스트 이름 또는 복제 세트 이름 변경의 경우 각 샤드의 ID 문서에서 샤드 메타데이터를 업데이트합니다.

중요

를 mongod 새 단일 노드 복제본 세트로 다시 시작합니다.

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

복제본 세트 멤버를 추가합니다.

필요한 추가 복제 설정을 구성합니다.

임시 권한 사용자를 제거합니다.

E. 각각 다시 시작 mongos

F. 클러스터 접근성 검증

CSRS 프라이머리 `mongod` 데이터 파일을 복원합니다.

데이터베이스를 `local` 삭제합니다.

계획되거나 완료된 샤드 호스트 이름 또는 복제본 세트 이름 변경의 경우 에서 메타데이터를 `config.shards` 업데이트합니다.

를 `mongod` 새 단일 노드 복제본 세트로 다시 시작합니다.

샤드 프라이머리 `mongod` 데이터 파일을 복원합니다.

역할을 가진 임시 `__system` 사용자를 만듭니다.

데이터베이스를 `local` 삭제합니다.

컬렉션에서 `minOpTimeRecovery` 문서를 `admin.system.versions` 제거합니다.

를 `mongod` 새 단일 노드 복제본 세트로 다시 시작합니다.

E. 각각 다시 시작 `mongos`