자체 관리형 샤딩된 클러스터 복원
이 페이지의 내용
이 절차는 LVM (Logical Volume 관리자 ) 스냅샷과 같은 기존 백업 스냅샷 에서 샤딩된 클러스터 를 복원합니다. 소스 및 대상 샤딩된 클러스터 에는 동일한 수의 샤드가 있어야 합니다. 샤드 클러스터의 모든 구성 요소에 대한 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 8.0 부터는 directShardOperations
역할 을 사용하여 샤드 에 대해 직접 명령을 실행해야 하는 유지 관리 작업을 수행할 수 있습니다.
경고
directShardOperations
역할 을 사용하여 명령을 실행하면 클러스터 가 올바르게 작동하지 않고 데이터가 손상될 수 있습니다. directShardOperations
역할 은 유지 관리 목적으로만 사용하거나 MongoDB 지원 의 지침 에 따라 사용하세요. 유지 관리 작업 수행이 완료되면 directShardOperations
역할 사용을 중지합니다.
A. (선택 사항) 복제본 세트 구성 검토하기
이 절차는 기본 구성을 사용하여 구성 서버 복제본 세트(CSRS) 및 각 샤드 복제본 세트에 대한 새 복제본 세트를 시작합니다. 복원된 CSRS 및 샤드에 대해 다른 복제본 세트 구성을 사용하려면 복제본 세트를 재구성해야 합니다.
소스 클러스터 가 올바르게 실행 액세스할 수 있는 경우 셸 mongo
shell 을 각 복제본 세트 의 프라이머리 복제본 세트 멤버에 연결합니다. 그런 다음 를 실행 rs.conf()
하여 복제본 구성 문서 를 확인합니다.
소스 샤딩된 클러스터의 구성 요소 하나 이상에 액세스할 수 없는 경우 기존 내부 문서를 참조하여 각 샤드 복제본 세트 및 구성 서버 복제본 세트에 대한 구성 요건을 재구성합니다.
B. 복원을 위한 대상 호스트 준비
- 저장 공간 요구 사항
- 대상 호스트 하드웨어에 복원된 데이터를 위한 충분한 사용 가능한 스토리지 공간이 있는지 확인합니다. 대상 호스트에 보관하려는 기존 샤딩된 클러스터의 데이터가 포함되어 있는 경우 기존 데이터와 복원된 데이터 모두를 위한 스토리지 공간이 충분한지 확인합니다.
- LVM 요구 사항
- LVM 스냅샷의 경우, 하나 이상의 LVM managed 볼륨 그룹 과 추출된 스냅샷 데이터를 위한 충분한 여유 공간이 있는 논리 볼륨이 있어야 합니다.
- 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 네임스페이스 필터링된 스냅샷에서 복원하는 경우
--restore
옵션을 지정합니다.mongod --config /path/to/mongod/mongod.conf --restore mongod
를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
선택한 백업 미디어에 저장된 데이터 파일을 호스팅하다 에서 액세스할 수 있도록 합니다. 이를 위해서는 백업 볼륨을 마운트하거나, 소프트웨어 유틸리티에서 백업 을 열거나, 다른 도구를 사용하여 데이터를 디스크에 추출해야 할 수 있습니다. 백업 에 포함된 데이터에 액세스하는 방법에 대한 지침은 선호하는 백업 도구의 설명서를 참조하세요.
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 네임스페이스 필터링된 스냅샷 에서 복원하는 경우
--restore
옵션도 지정합니다.mongod --config /path/to/mongod/mongod.conf --restore 참고
Cloud Manager 또는 MongoDB Ops Manager 전용
Cloud Manager 또는 MongoDB Ops Manager 백업 의 수동 복원을 수행하는 경우 스타트업 하기 전에
disableLogicalSessionCacheRefresh
서버 매개 변수를 지정해야 합니다.mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true mongod
를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
데이터베이스를 local
제거합니다.
db.dropDatabase()
를 사용하여 local
데이터베이스를 제거합니다.
use local db.dropDatabase()
필터링된 파일 목록을 로컬 데이터베이스에 삽입합니다.
이 단계는 네임스페이스로 필터링된 스냅샷에서 복원하는 경우에만 필요합니다.
각 샤드에 대해 다음 이름 형식의 필터링된 파일 목록을 찾습니다: <shardRsID>-filteredFileList.txt
. 이 파일에는 다음 형식의 JSON 객체 목록이 포함되어 있습니다.
{ "filename":"file1", "ns":"sampleDb1.sampleCollection1", "uuid": "3b241101-e2bb-4255-8caf-4136c566a962" }
각 샤드 파일의 각 JSON 객체를 local
데이터베이스의 새 db.systems.collections_to_restore
컬렉션에 추가합니다. ns
또는 uuid
필드가 비어 있는 항목은 무시할 수 있습니다. 항목을 삽입할 때 uuid
필드는 UUID()
유형으로 삽입해야 합니다.
계획되거나 완료된 샤드 호스트 이름 또는 복제본 세트 이름 변경의 경우 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" } } )
모든 샤드 메타데이터가 클러스터의 각 샤드에 대해 계획된 복제본 세트 이름과 호스트 이름 목록을 정확하게 반영할 때까지 이 과정을 반복합니다.
를 mongod
새 단일 노드 복제본 세트 로 다시 시작합니다.
mongod
를 종료합니다. 다음 구성 파일 옵션의 주석을 제거하거나 추가합니다.
replication: replSetName: myNewCSRSName sharding: clusterRole: configsvr
복제본 세트 이름을 변경하려면 계속 진행하기 전에 replSetName
필드를 새 이름으로 업데이트해야 합니다.
업데이트된 구성 파일로 mongod
를 시작합니다.
mongod --config /path/to/mongodb/mongod.conf
mongod
를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
새 복제본 세트를 시작합니다.
기본 설정 및 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 네임스페이스 필터가 있는 스냅샷에서 복원 중이라면
--restore
옵션을 지정하세요.mongod --config /path/to/mongod/mongod.conf --restore mongod
를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
선택한 백업 미디어에 저장된 데이터 파일을 호스팅하다 에서 액세스할 수 있도록 합니다. 이를 위해서는 백업 볼륨을 마운트하거나, 소프트웨어 유틸리티에서 백업 을 열거나, 다른 도구를 사용하여 데이터를 디스크에 추출해야 할 수 있습니다. 백업 에 포함된 데이터에 액세스하는 방법에 대한 지침은 선호하는 백업 도구의 설명서를 참조하세요.
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 또는 MongoDB Ops Manager 전용
Cloud Manager 또는 MongoDB Ops Manager 백업 의 수동 복원을 수행하는 경우 스타트업 하기 전에
disableLogicalSessionCacheRefresh
서버 매개 변수를 지정해야 합니다.mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true mongod
를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
역할 __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
를 시스템 서비스로 실행하도록 구성한 경우 시스템 서비스 관리자에게 권장되는 프로세스를 사용하여 시작하세요.
새 복제본 세트를 시작합니다.
기본 설정 및 rs.initiate()
를 사용하여 복제본 세트를 시작합니다.
rs.initiate()
작업이 완료되면 rs.status()
를 사용하여 멤버가 프라이머리가 되었는지 확인합니다.
복제본 세트 멤버를 추가합니다.
샤드 복제본 세트의 각 복제본 세트 멤버에 대해 해당 호스트 시스템에서 mongod
를 시작합니다. 클러스터의 나머지 멤버를 모두 성공적으로 시작했다면 mongo
셸을 프라이머리 복제본 세트 멤버에 연결합니다. 프라이머리에서 rs.add()
메서드를 사용하여 복제본 세트의 각 멤버를 추가합니다. 접두사로 복제본 세트 이름을 포함하고, 그 뒤에 멤버의 mongod
프로세스의 호스트 이름과 포트를 포함합니다:
rs.add("repl2.example.net:27018") rs.add("repl3.example.net:27018")
특정 복제본 member
구성 설정이 있는 멤버를 추가하려면 멤버 호스트 이름과 배포에 필요한 members
설정을 정의하는 문서를 rs.add()
에 전달하면 됩니다.
rs.add( { "host" : "repl2.example.net:27018", priority: <int>, votes: <int>, tags: <int> } )
각각의 새 멤버는 프라이머리를 따라잡기 위해 초기 동기화를 수행합니다. 동기화할 데이터의 양, 네트워크 토폴로지 및 상태, 각 호스트 시스템의 전원 등의 요인에 따라 초기 동기화를 완료하는 데 시간이 오래 걸릴 수 있습니다.
멤버를 추가하는 동안 복제본 세트가 새 프라이머리를 선출할 수 있습니다. rs.status()
를 사용하여 현재 프라이머리인 멤버를 식별합니다. 프라이머리에서는 rs.add()
만 실행할 수 있습니다.
필요한 추가 복제 설정을 구성합니다.
rs.reconfig()
메서드는 매개 변수로 전달된 구성 문서를 기반으로 복제본 세트 구성을 업데이트합니다. 복제본 세트의 프라이머리 멤버에 대해 reconfig()
를 실행해야 합니다.
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 6.0.3부터는 밸런싱 정책의 개선으로 인해 자동 청크 분할이 수행되지 않습니다. 자동 분할 명령은 여전히 존재하지만 작업을 수행하지는 않습니다. MongoDB 6.0.3 이전 버전에서 sh.startBalancer() 는 샤딩된 클러스터에 대한 자동 분할도 활성화합니다. |