자체 관리형 샤드 클러스터를 다른 하드웨어로 마이그레이션

이 페이지의 내용

시작하기 전에

밸런서 비활성화
각 config MongoDB Server를 별도로 마이그레이션
mongos 인스턴스 다시 시작
샤드 마이그레이션
밸런서 다시 활성화

이 튜토리얼은 MongoDB 8.0 에만 해당됩니다. 이전 버전의 MongoDB에 대해서는 해당 버전의 MongoDB 매뉴얼을 참조하세요.

샤딩된 클러스터의 config 서버는 복제본 세트 로 배포됩니다. 복제본 세트 구성 서버는 WiredTiger 스토리지 엔진을 실행 해야 합니다.

이 절차는 읽기 및 쓰기를 위한 다운타임 없이 샤딩된 클러스터 의 컴포넌트를 새 하드웨어 시스템으로 이동합니다.

중요

마이그레이션이 진행되는 동안에는 샤드 클러스터 메타데이터 로 변경하려고 하지 마세요. 어떤 방식 으로든 클러스터 메타데이터 를 수정 하는 작업 을 사용 하지 마세요 . 예를 들어 데이터베이스를 생성 또는 삭제하거나, 컬렉션을 생성 또는 삭제하거나, 샤딩 명령을 사용하지 않아야 합니다.

시작하기 전에

MongoDB 8.0 부터 directShardOperations 역할을 사용하여 샤드에 대해 직접 명령을 실행해야 하는 유지 관리 작업을 수행할 수 있습니다.

경고

directShardOperations 역할 을 사용하여 명령을 실행하면 클러스터 가 올바르게 작동하지 않고 데이터가 손상될 수 있습니다. directShardOperations 역할 은 유지 관리 목적으로만 사용하거나 MongoDB 지원 의 지침 에 따라 사용하세요. 유지 관리 작업 수행이 완료되면 directShardOperations 역할 사용을 중지합니다.

밸런서 비활성화

밸런서를 비활성화하여 청크 마이그레이션을 중지하고 프로세스가 완료될 때까지 메타데이터 쓰기 작업을 수행하지 마세요. 진행 중인 마이그레이션이 있다면, 밸런서는 정지하기 전에 진행 중인 마이그레이션을 완료합니다.

밸런서를 비활성화하려면 클러스터의 mongos 인스턴스 중 하나에 연결하고 다음 메서드를 실행합니다: [1]

sh.stopBalancer()

밸런서 상태를 확인하려면 sh.getBalancerState() 메서드를 실행합니다.

자세한 내용은 밸런서 비활성화를 참조하세요.

[1]	MongoDB에서 시작하기 6.0.3부터 자동 청크 분할이 수행되지 않습니다. 이는 밸런싱 정책 개선 때문입니다. 자동 분할 명령은 여전히 존재하지만 작업을 수행하지 않습니다. MongoDB 6.0.3 이전 버전에서 `sh.stopBalancer()`는 샤딩된 클러스터에 대한 자동 분할도 비활성화합니다.

각 config MongoDB Server를 별도로 마이그레이션

샤딩된 클러스터의 구성 서버는 복제본 세트(CSRS)로 배포될 수 있습니다. 구성 서버에 복제본 세트를 사용하면 구성 데이터에 대한 표준 복제본 세트 읽기 및 쓰기 프로토콜을 활용할 수 있으므로 구성 서버 전체에서 일관성이 향상됩니다. 또한, 구성 서버에 복제본 세트를 사용하면 복제본 세트에 최대 50명의 구성원이 있을 수 있으므로 샤딩된 클러스터에 3개 이상의 구성 서버를 보유할 수 있습니다. 구성 서버를 복제본 세트로 배포하려면 구성 서버에서 WiredTiger 스토리지 엔진을실행해야 합니다.

config 서버에 사용할 경우 복제본 세트 구성에 다음과 같은 제한이 적용됩니다.

중재자가 없어야 합니다.
지연된 멤버가 없어야 합니다.
인덱스를 작성해야 합니다(예: members[n].buildIndexes 설정이 false로 설정된 노드가 없어야 합니다).

config 서버 복제본 세트의 각 멤버에 대해 다음을 수행합니다.

중요

프라이머리를 교체하기 전에 세컨더리 멤버를 교체합니다.

교체 config 서버를 시작합니다.

--configsvr, --replSet, --bind_ip 옵션 및 배포서버에 적합한 기타 옵션을 지정하여 mongod 인스턴트를 시작합니다.

경고

인스턴스를 공개적으로 접근 가능한 IP 주소에 바인딩하기 전에 무단 접근으로부터 클러스터를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버에 대한 보안 검사 목록을 참조하세요. 최소한 인증을 활성화하고 네트워크 인프라를 강화하는 것을 고려합니다.

mongod --configsvr --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

새 config 서버를 복제본 세트에 추가합니다.

mongosh 를 config 서버 복제본 세트의 프라이머리에 연결하고 rs.add() 를 사용하여 새 멤버를 추가합니다.

경고

MongoDB 5.0 이전에는 데이터가 일관될 때까지 새로 추가된 보조 서버가 읽기 작업을 수행하거나 기본 서버가 될 수 없더라도 여전히 투표 멤버로 간주됩니다. 5.0 이전 버전의 MongoDB를 실행 중이고 votes 및 priority 설정이 0보다 큰 보조를 추가하는 경우, 투표 회원의 과반수가 온라인 상태이지만 기본 회원을 선출할 수 없는 경우가 발생할 수 있습니다. 이러한 상황을 방지하려면 priority :0 및 votes :0로 새 보조를 처음에 추가하는 것이 좋습니다. 그런 다음 rs.status()를 실행하여 멤버가 SECONDARY 상태로 전환되었는지 확인합니다. 마지막으로 rs.reconfig() 를 사용하여 우선 순위와 투표를 업데이트하세요.

rs.add( { host: "<hostnameNew>:<portNew>", priority: 0, votes: 0 } )

초기 동기화 프로세스는 다시 시작하지 않고도 config 서버 복제본 세트의 한 노드에 있는 모든 데이터를 새 노드로 복사합니다.

mongos 인스턴스는 다시 시작하지 않고도 config 서버 복제본 세트 멤버의 변경 사항을 자동으로 인식합니다.

새로 추가된 설정 서버의 투표 및 우선순위 설정을 업데이트합니다.

새 멤버가 SECONDARY 상태에 도달했는지 확인합니다. 복제본 세트 멤버의 상태를 확인하려면 rs.status()를 실행합니다.
```
rs.status()
```

복제본 세트를 재구성하여 새 멤버의 투표와 우선 순위를 업데이트합니다.

var cfg = rs.conf();
cfg.members[n].priority = 1;  // Substitute the correct array index for the new member
cfg.members[n].votes = 1;     // Substitute the correct array index for the new member
rs.reconfig(cfg)

여기서 n는 members 배열에 있는 새 노드의 배열 인덱스입니다.

경고

rs.reconfig() 2} 셸 메서드는 현재 기본값이 강제로 물러나도록 하여 선거를 실시할 수 있습니다. 기본 연결이 종료되면 mongod 모든 클라이언트 연결을 닫습니다. 일반적으로 10~20초 정도 소요되지만 예약된 유지 관리 기간 동안 이러한 변경을 수행해 보세요.
유효성 검사 규칙은 MongoDB 버전마다 다를 수 있으므로 다른 MongoDB 버전의 멤버를 포함하는 복제본 세트를 다시 구성하지 마십시오.

교체할 노드를 종료합니다.

프라이머리 멤버를 교체하는 경우 종료하기 전에 먼저 프라이머리 멤버의 단계를 낮춥니다.

config 서버 복제본 세트에서 교체할 노드를 제거합니다.

교체 config 서버의 초기 동기화가 완료되면 프라이머리에 연결된 mongosh 세션에서 rs.remove()를 사용하여 이전 멤버를 제거합니다.

rs.remove("<hostnameOld>:<portOld>")

mongos 인스턴스는 다시 시작하지 않고도 config 서버 복제본 세트 멤버의 변경 사항을 자동으로 인식합니다.

인스턴스 다시 `mongos` 시작

복제본 세트 구성 서버의 경우 mongos 인스턴스는 --configdb 또는 sharding.configDB 설정에서 구성 서버 복제본 세트 이름과 복제본 세트 멤버 중 하나 이상을 지정합니다. 샤드 클러스터의 mongos 인스턴스는 동일한 config 서버 복제본 세트 이름을 지정해야 하지만 복제본 세트의 다른 멤버를 지정할 수 있습니다.

mongos 인스턴스가 --configdb 또는 sharding.configDB 설정에서 마이그레이션된 복제본 세트 멤버를 지정하는 경우 다음에 mongos 인스턴스를 다시 시작할 때를 위해 config 서버 설정을 업데이트합니다.

자세한 내용 은 샤드 클러스터에 대해 mongos 시작을 참조하세요.

샤드 마이그레이션

샤드를 한 번에 하나씩 마이그레이션합니다. 각 샤드에 대해 이 섹션에서 적절한 절차를 따르세요.

복제본 세트 샤드 마이그레이션

샤드 클러스터를 마이그레이션하려면 각 멤버를 별도로 마이그레이션합니다. 먼저 비프라이머리 멤버를 마이그레이션한 다음 프라이 머리 멤버를 마지막으로 마이그레이션합니다.

복제본 세트에 두 명의 투표 멤버가 있는 경우 복제본 세트에 중재자 를 추가하여 마이그레이션 중에 세트가 투표의 과반수를 사용할 수 있도록 합니다. 마이그레이션을 완료한 후 중재자를 제거할 수 있습니다.

복제본 세트 샤드의 노드 마이그레이션

mongod 프로세스를 종료합니다. 정상적으로 종료하려면 shutdown 명령을 사용합니다.
데이터 디렉토리(예: dbPath)를 새 컴퓨터로 이동합니다.
새 위치에서 mongod 프로세스를 다시 시작합니다.
복제본 세트의 현재 프라이머리에 연결합니다.
멤버의 호스트 이름이 변경된 경우 rs.reconfig() 를 사용하여 복제본 세트 구성 문서 를 새 호스트 이름으로 업데이트합니다.
예를 들어, 다음 명령 시퀀스는 members 배열의 2 위치에 있는 인스턴스의 호스트 이름을 업데이트합니다.
```
cfg = rs.conf()
cfg.members[2].host = "pocatello.example.net:27018"
rs.reconfig(cfg)
```
구성 문서 업데이트에 대한 자세한 내용은 예시를 참조하세요.
새 구성을 확인하려면 rs.conf() 실행합니다.
멤버가 복구될 때까지 기다립니다. 멤버의 상태를 확인하려면 rs.status() 를 실행합니다.

복제본 세트 샤드에서 프라이머리 마이그레이션

복제본 세트의 프라이머리를 마이그레이션하는 동안 세트는 새 프라이머리를 선택해야 합니다. 이 페일오버 프로세스는 투표 기간 동안 복제본 세트를 사용하여 읽기 또는 쓰기 허용을 불가능하게 하며, 일반적으로 빠르게 완료됩니다. 가능하면 유지 관리 기간 동안 마이그레이션을 계획하세요.

정상적인 페일오버 프로세스를 허용하려면 프라이머리를 단계적으로 낮춥니다. 프라이머리를 단계적으로 낮추려면 프라이머리에 연결하여 replSetStepDown 명령 또는 rs.stepDown() 메서드를 실행합니다. 다음 예는 rs.stepDown() 메서드를 보여줍니다.
```
rs.stepDown()
```
프라이머리가 물러나고 다른 멤버가 PRIMARY 상태가 된 경우. 물러난 프라이머리를 마이그레이션하려면 복제본 세트 샤드의 구성원 마이그레이션 절차를 따르세요.
rs.status() 출력을 확인하여 상태 변경을 확인할 수 있습니다.

밸런서 다시 활성화

마이그레이션을 완료하려면 밸런서를 다시 활성화하여 청크 마이그레이션을 재개합니다.

클러스터의 mongos 인스턴스 중 하나에 연결하고 true 을 sh.startBalancer() 메서드에 전달합니다: [2]

sh.startBalancer()