클러스터 유지 관리 준비
이 페이지의 내용
- Cloud Manager 에 대한 프로그래밍 방식의 액세스 를 위한 OAuth 2.0 인증 은 Preview 기능 으로 제공됩니다.
- 기능 및 해당 설명서는 미리 보기 기간에 언제든지 변경될 수 있습니다. OAuth 2.0 인증 을 사용하려면 Cloud Manager 공개 API 에 대한 요청에 사용할서비스 계정을 만듭니다.
Cloud Manager는 클러스터의 노드에서 유지 관리를 수행 할 때 롤링 재시작 을 수행합니다. 자동화는 유지 관리 기간 동안 클러스터 가용성을 유지하기 위해 모든 노드가 업데이트될 때까지 클러스터의 노드를 하나씩 업데이트합니다.
클러스터에서 유지 관리를 수행하기 전에 다음 고려 사항을 검토하고 필요한 경우 조치를 취하여 클러스터 가용성을 유지하세요.
참고
Automation이 cluster에서 유지 관리를 수행하는 방법에 대해 알아보려면 Cloud Manager는 cluster에서 유지 관리를 어떻게 수행하나요?를 참조하세요.
oplog size
클러스터의 각 노드는 유지 관리가 시작되기 전에 독립형 모드로 다시 시작됩니다. 노드는 유지 관리가 완료된 후 클러스터에 다시 추가될 때 다른 노드를 따라잡기 위해 oplog 에 쓰기를 재생합니다.
클러스터의 oplog가 유지 관리 기간 동안 애플리케이션에서 수행할 수 있는 모든 쓰기를 저장할 수 있을 만큼 충분히 커야 합니다. replication.oplogSizeMB 고급 배포 옵션을 사용하여 oplog 크기를 조정합니다.
우선 순위
해당 노드에서 유지 관리가 시작되면 기본 노드에 대한 모든 클라이언트 연결이 끊어집니다. 새로 선출된 프라이머리 노드에 대한 연결이 다시 설정됩니다.
특정 데이터 센터의 노드를 새 프라이머리 노드로 선호할 수 있습니다. 클러스터의 구성을 편집하고 각 노드의 우선 순위를 조정하여 원하는 프라이머리 노드를 표시합니다.
내결함성
유지 관리 중인 노드는 cluster에 대한 페일오버 지원을 제공하지 않습니다. 3노드 replica sets의 경우, 한 노드가 유지 관리를 진행하는 동안 추가 노드를 사용할 수 없게 되면 cluster의 노드 대부분이 손실됩니다. 프라이머리 노드는 이 상태를 벗어나 세컨더리 노드로 강등됩니다. 클러스터 노드의 과반수 이상을 사용할 수 있을 때까지는 새로운 프라이머리 노드를 선출할 수 없습니다.
가동 시간이 필요한 미션 크리티컬 애플리케이션의 경우 유지 관리를 수행하기 전에 3개 멤버가 있는 replica set를 5개 멤버로 구성된 replica set로 변환하여 유지 관리 기간 동안 추가 cluster 노드를 사용할 수 없게 되는 경우에 대비하여 cluster 과반수를 유지하는 것이 좋습니다.
참고
멤버가 5명 이상인 복제본 세트는 복원력이 더 뛰어나고 유지 관리 기간 동안 과반수가 손실될 가능성이 낮습니다.
다중 내결함성을 높이는 간단하지만 탄력성이 떨어지는 옵션은 유지 관리를 수행하기 전에 세 멤버로 구성된 복제본 세트 에 임시 중재자를 추가하는 것입니다.
고유 인덱스 빌드
자동화는 동일하지만 독립적인 명령을 사용하여 클러스터 노드에 인덱스를 한 번에 하나씩 빌드합니다. 쓰기가 고유 인덱스 에서 인덱싱된 필드의 unique 품질을 준수하도록 하려면 인덱스를 빌드하기 전에 클러스터의 컬렉션에 대한 모든 쓰기를 중지해야 합니다.
이러한 메서드는 cluster에 대한 쓰기를 중지하지 않으므로 데이터 탐색기 또는 Cloud Manager의 자동화 구성 리소스 를 사용하여 롤링 방식으로 고유 인덱스를 생성할 수 없습니다.
사용 사례에서 새로운 고유 인덱스를 빌드해야 하는 경우:
영향을 받는 컬렉션에 대한 모든 쓰기를 중지합니다. 자세한 내용은 다음을 참조하세요. MongoDB 매뉴얼의 db.fsyncLock() 을 참조하세요.
롤링 방식으로 고유 인덱스를 빌드하려면 MongoDB 매뉴얼의 복제본 세트에 인덱스 빌드를 참조하세요.