MongoDB 백업에서 자체 관리형 복제본 세트 복원하기
이 절차에서는 MongoDB 데이터를 가져와서 새 복제본 세트로 복원하는 프로세스를 간략하게 설명합니다. 프로덕션 백업에서 테스트 배포서버를 시딩하거나 재해 복구의 일환으로 이러한 방식을 사용합니다.
중요
또한 mongorestore를 사용해 mongodump로 생성한 데이터를 사용하는 데이터베이스 파일을 복원할 수도 있습니다. 자세한 내용은 MongoDB 도구를 사용하여 자체 관리형 배포 백업 및 복원을 참조하세요.
데이터베이스를 단일 노드 복제본 세트로 복원하기
백업 MongoDB 데이터베이스 파일을 가져옵니다.
백업 파일은 파일 시스템 스냅샷에서 가져올 수 있습니다. MongoDB Cloud Manager는 저장된 스냅샷과 특정 시점 스냅샷에 대한 MongoDB database 파일을 생성합니다. MongoDB Enterprise Advanced에서 사용할 수 있는 온프레미스 솔루션 Ops Manager의 경우 Ops Manager 백업 개요도 참조하세요.
- 암호화된 스토리지 엔진에 대한 고려 사항
AES256-GCM암호화 모드를 사용하는 암호화 스토리지 엔진의 경우AES256-GCM이 모든 프로세스가 키와 함께 고유한 카운터 블록 값을 사용하도록 요구합니다.AES256-GCM암호로 구성된 암호화 스토리지 엔진 encrypted 스토리지 엔진의 경우- 핫 백업에서 복원
- 4.2부터 "hot" 백업을 통해 가져온 파일에서 복원하는 경우(즉,
mongod가 실행 중일 때), MongoDB는 시작 시 "더티" 키를 감지하고 데이터베이스 키를 자동으로 롤오버하여 IV(초기화 벡터) 재사용을 방지할 수 있습니다.
- 콜드 백업에서 복원
그러나 "cold" 백업을 통해 가져온 파일에서 복원하는 경우(즉,
mongod가 실행 중이 아닌 경우), MongoDB는 시작 시 "더티" 키를 감지할 수 없으며, IV를 재사용하면 기밀성 및 무결성 보증이 무효화됩니다.4.2부터 콜드 파일 시스템 스냅샷에서 복원한 후 키 재사용을 방지하기 위해 MongoDB는 새로운 명령줄 옵션
--eseDatabaseKeyRollover를 추가합니다.--eseDatabaseKeyRollover옵션으로 시작하면mongod인스턴스는AES256-GCM암호로 구성된 데이터베이스 키를 롤오버하고 종료합니다.
백업에 local 데이터베이스가 있는 경우 제거합니다.
파일 시스템 백업(또는 local 데이터베이스가 포함된 백업)에서 복원하는 경우 local 데이터베이스를 제거합니다.
백업의 데이터 파일을 데이터 경로로 사용하여 독립형 mongod를 시작합니다.
또한 스냅샷을 만들 때 사용한 것과 동일한 시작 옵션을 지정해야 합니다.
mongod --dbpath /data/db <startup options>
local 데이터베이스를 제거합니다.
mongosh를 mongod 인스턴스에 연결하고 local 데이터베이스를 제거합니다.
use local db.dropDatabase()
독립형을 종료합니다.
새 단일 노드 복제본 세트를 시작합니다.
mongod 인스턴스를 새 단일 노드 복제본 세트로 시작합니다. --dbpath 옵션을 사용하여 백업 데이터 파일의 경로를 지정하고 --replSet을 사용하여 복제본 세트의 이름을 지정합니다. config 서버 복제본 세트(CSRS)의 경우 --configsvr 옵션을 포함합니다. 배포서버에 적합한 다른 옵션을 포함할 수 있습니다.
또한 스냅샷을 만들 때 사용한 것과 동일한 시작 옵션을 지정해야 합니다.
참고
복제본 세트 멤버가 다른 호스트에서 실행되거나 원격 클라이언트의 인스턴스 연결을 지원하려면 net.bindIp 설정(또는 --bind_ip)을 지정해야 합니다.
경고
로컬 호스트가 아닌 에 바인딩하기 전에(예: 공개적으로 액세스할 수 있는) IP 주소 인 경우 무단 액세스 로부터 클러스터 를 보호했는지 확인합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버를 위한 보안 체크리스트를 참조하세요. 최소한 인증 을 활성화 하고 네트워크 인프라를 강화하는 것을 고려하세요.
mongod --dbpath /data/db --replSet <replName> <startup options>
참고
모든 MongoDB 컬렉션에는 기본적으로 UUID가 포함되어 있습니다. MongoDB가 컬렉션을 복원할 때 복원된 컬렉션은 본래의 UUID를 유지합니다. UUID가 없는 컬렉션을 복원하는 경우, MongoDB는 복원된 컬렉션에 대한 UUID를 생성합니다.
컬렉션 UUID에 대한 자세한 내용은 컬렉션을 참조하세요.
새 복제본 세트를 시작합니다.
복제본 세트의 유일한 멤버에서 rs.initiate()를 사용합니다.
rs.initiate( { _id : <replName>, members: [ { _id : 0, host : <host:port> } ] })
MongoDB는 현재 멤버로 구성되며 기본 복제본 세트 구성을 이용하는 세트를 시작합니다.
복제본 세트에 멤버 추가
MongoDB에서는 두 가지 방법으로 복제본 세트의 세컨더리 멤버를 복원할 수 있습니다.
각 데이터 디렉토리에 데이터베이스 파일을 수동으로 복사합니다.
초기 동기화를 허용하여 데이터를 자동으로 배포합니다.
참고
데이터베이스가 큰 경우 초기 동기화를 완료하는 시간이 오래 걸릴 수 있습니다. 대규모 데이터베이스의 경우 데이터베이스 파일을 각 호스트에 복사하는 것이 바람직할 수 있습니다.
데이터베이스 파일 복사 및 mongod 인스턴스 다시 시작
다음 작업 순서를 사용하여 MongoDB 데이터 파일을 직접 복사하여 복제본 세트의 추가 멤버에 복원된 데이터를 '시딩'합니다.
복원한 mongod 인스턴스를 종료합니다.
--shutdown 또는 db.shutdownServer()를 사용하여 정상적으로 종료할 수 있습니다.
복원한 mongod 인스턴스를 시작합니다.
복제본 세트에 세컨더리를 추가합니다.
mongosh 세션에서 프라이머리에 연결된 상태로 세컨더리를 rs.add() 메소드를 사용하여 복제본 세트에 추가합니다. 복제본 세트를 배포하는 방법에 대한 자세한 내용은 자체 관리 복제본 세트 배포를 참조하세요.
초기 동기화를 사용하여 세컨더리 업데이트
다음의 작업 순서로 기본 초기 동기화 작업을 사용하여 복제본 세트의 추가 구성원에 복원된 데이터로를 '시딩'할 수 있습니다.