AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu

mongot 배포 문제 해결

Kubernetes 연산자용 MongoDB 컨트롤러는 mongot 를 별도의 Pod에 별도 프로세스로 배포하며, MongoDBSearch 리소스로 정의됩니다. 클라이언트는 mongot 에 직접 연결하지 않습니다. MongoDB Search 및 벡터 검색 쿼리는 mongod에서 실행되며, 은 쿼리를 mongot로 프록시합니다. mongotmongod 에 다시 연결하여 변경 이벤트를 스트리밍하고 전용 영구 볼륨에 인덱스를 빌드합니다.

이 페이지에서는 mongot 배포에서 발생하는 일반적인 런타임 문제를 진단하고 해결하는 방법을 설명합니다. 초기 설정 동안 인덱스 생성에 관한 트러블슈팅은 MongoDB Search 및 벡터 검색 사용을 참조하십시오. 조사하기 전에 지표와 로깅을 설정하려면 배포서버 모니터를 참조하십시오.

이 페이지의 절차에서는 배포서버에 맞게 다음 환경 변수를 설정했다고 가정합니다.

export MDB_NS="<your-namespace>"
export K8S_CTX="<your-kubectl-context>"
export MDB_RESOURCE_NAME="<your-mongodbsearch-resource-name>"

특정 시나리오를 실행하기 전에 mongot 팝의 현재 상태, 로그 및 최근 Kubernetes 이벤트를 수집합니다.

# Check the status and restart count of the mongot pod
kubectl get pods -n ${MDB_NS} --context ${K8S_CTX} | grep search
# Review the most recent mongot logs
kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \
-n ${MDB_NS} --context ${K8S_CTX} --tail=100
# Inspect the MongoDBSearch resource status and conditions
kubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \
-n ${MDB_NS} --context ${K8S_CTX}
# List recent events in the namespace
kubectl get events -n ${MDB_NS} --context ${K8S_CTX} \
--sort-by='.lastTimestamp'

포드가 루프에서 다시 시작되면 이전 컨테이너 인스턴스의 로그를 보아 재시작의 원인이 된 오류를 확인합니다.

kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \
-n ${MDB_NS} --context ${K8S_CTX} --previous

증상: mongot 팝이 Pending, ContainerCreating 또는 Error 에 머물러 Running에 도달하지 않거나 MongoDBSearch 리소스가 Running 상태에 도달하지 않습니다.

진단: 진단 정보 수집 에서 명령을 실행하고 팟 이벤트와 MongoDBSearch 상태를 검토합니다. 일반적인 지표에는 스케줄링 실패, 볼륨 마운트 오류 및 이미지 풀 오류가 포함됩니다.

해결:

  • 팝을 스케줄할 수 없는 경우 충분한 CPU 및 메모리가 있는 노드 가 사용 가능하고 StorageClass 가 요청된 영구 볼륨 요청을 바인딩할 수 있는지 확인합니다. mongot 사이징에 대한 자세한 내용은 검색 및 벡터 검색 리소스 계획 및 사이징을 참조하세요.

  • search-sync-source 사용자에 대한 비밀번호 시크릿이 없는 경우 생성합니다. MongoDBSearch 리소스에서는 ${MDB_RESOURCE_NAME}-search-sync-source-password라는 이름의 시크릿이 필요합니다.

  • mongot 컨테이너 이미지를 가져올 수 없는 경우 이미지 이름과 레지스트리 자격 증명을 확인합니다. kubectl get events -n ${MDB_NS} | grep -i pull의 이미지 가져오기 오류를 확인합니다.

  • 소스 mongod 복제본 세트가 Running 상태가 아니면 먼저 해결합니다. Kubernetes 연산자용 MongoDB 컨트롤러는 mongot를 배포하기 전에 소스 리소스를 기다립니다.

증상: $search, $searchMeta, 또는 $vectorSearch 쿼리가 mongod 가 검색 서비스에 연결할 수 없음을 나타내는 오류로 실패합니다.

진단: mongot 팟이 Running 인지 확인하고 서비스 가 존재하는지 확인합니다.

kubectl get pods,svc -n ${MDB_NS} --context ${K8S_CTX} \
| grep search

연결 또는 인증 오류에 대해 mongot 로그를 검토하고, 검색 호스트를 참조하는 오류에 대해 mongod 로그를 검토합니다.

해결:

증상: mongot 팝에 재시작 횟수가 높거나 CrashLoopBackOff이(가) 보고됩니다.

진단: 이전 컨테이너 인스턴스의 로그를 보아 재시작을 트리거한 오류를 캡처합니다.

kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \
-n ${MDB_NS} --context ${K8S_CTX} --previous

포드의 마지막 상태와 종료 이유를 확인합니다.

kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \
-n ${MDB_NS} --context ${K8S_CTX}

해결:

  • 종료 이유가 OOMKilled인 경우 mongot의 메모리 리소스를 늘립니다. mongot 메모리 부족을 참조하세요.

  • 로그에 구성 또는 인증 오류가 표시되면 설정을 수정하고 Kubernetes 연산자용 MongoDB 컨트롤러가 변경사항을 조정하도록 합니다.

  • 로그에 mongot 이 인덱스 데이터를 읽거나 쓸 수 없다고 표시되면 영구 볼륨 요청 이 바인딩되어 있고 쓰기 가능한지 확인하세요. mongot 팟이 시작되지 않습니다.를 참조하세요.

증상: mongot 팟이 OOMKilled 이유로 종료되고 재시작 횟수가 증가합니다.

진단: 팝의 종료 이유를 확인합니다.

kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \
-n ${MDB_NS} --context ${K8S_CTX}

mongot Lucene 기반의 메모리 매핑된 워크로드입니다. 메모리 부하는 인덱스 크기와 쿼리 로드에 비해 메모리 제한이 작을 때 자주 발생합니다.

해결:

  • MongoDBSearch 리소스의 mongot 에 할당된 메모리 리소스를 늘립니다. mongot 가 다시 시작되면 변경사항이 적용됩니다.

  • 검색 및 벡터 검색 리소스 계획 및 사이징의 사이징 지침에 대해 인덱스 크기와 쿼리 부하를 검토하세요.

증상: 새로 생성된 인덱스가 오래 동안 빌드 상태에 머물거나 쿼리 결과가 mongod에 대한 최근 쓰기(write)보다 늦어집니다.

진단: 복제 진행 및 오류에 대한 mongot 로그를 검토합니다. 배포서버 모니터 에서 구성한 지표를 사용하여 인덱스 생성 진행 및 복제 지연을 시간에 따라 추적합니다.

해결:

  • 초기 동기화가 완료되도록 허용합니다. 인덱스 빌드 시간은 소스 데이터 크기에 따라 확장됩니다.

  • 일정한 부하에서 지연이 계속되면 mongot 인스턴스에 쓰기 (write) 볼륨에 충분한 리소스가 없을 수 있습니다. 검색 및 벡터 검색 리소스 계획 및 사이징을 검토.

  • 저장 성능이 무작위 읽기 중심의 Lucene 워크로드에 대한 권장 사항을 충족하는지 확인하세요. 느린 저장은 지속적인 지연의 일반적인 원인입니다.

증상: mongot 로그에 TLS 핸드쉐이크 또는 인증서 유효성 검사 오류가 표시되고 mongodmongot에 대한 연결을 수립할 수 없습니다.

진단: mongot 로그에서 인증서 오류를 검토하고 MongoDBSearch 리소스에서 참조하는 TLS 시크릿이 존재하는지 확인합니다.

kubectl get secrets -n ${MDB_NS} --context ${K8S_CTX} \
| grep -i tls

해결:

  • mongodmongot 이 동일한 CA를 신뢰하는지 확인합니다.

  • 인증서를 대체하거나 로테이션한 후에는 mongot 을 다시 시작하여 새 인증서를 읽도록 합니다. mongot 은 시작 시 인증서를 읽지만 실행 중에는 다시 로드하지 않습니다.

  • 자세한 학습은 MongoDB에서 검색으로의 연결 보안을 참조하세요.

참고

자동 임베딩은 미리 보기 기능이며 Voyage AI 모델에만 통합됩니다.

증상: 자동 임베딩을 사용하는 인덱스가 빌드되지 않거나 mongot 로그에서 임베딩 요청이 오류를 반환합니다.

진단: 인증 실패 또는 요청 타임아웃과 같이 임베딩 제공자를 참조하는 오류가 있는지 mongot 로그를 검토합니다.

해결:

  • Voyage AI API 키가 유효하고 키를 보관하는 Secret이 네임스페이스에 존재하는지 확인합니다.

  • Kubernetes 클러스터에서 mongot 가 임베딩 제공자 엔드포인트에 액세스할 수 있는지 확인합니다.

MongoDB 지원에 문의하는 경우 mongot 로그, MongoDBSearch 리소스 설명 및 최근 네임스페이스 이벤트를 포함하세요.

kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \
-n ${MDB_NS} --context ${K8S_CTX} > mongot.log
kubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \
-n ${MDB_NS} --context ${K8S_CTX} > mongodbsearch-describe.txt
kubectl get events -n ${MDB_NS} --context ${K8S_CTX} \
--sort-by='.lastTimestamp' > events.txt

영향을 받은 각 검색 팝에서 FTDC 파일을 포함할 수도 있습니다. mongot 는 팝 내부의 /mongot/data/diagnostic.data/ 에 FTDC 파일을 쓰기합니다.

/mongot/data 경로는 Kubernetes Operator가 검색 StatefulSet에 volumeClaimTemplate 를 통해 팝에 마운트하는 PersistentVolumeClaim 이므로 진단 데이터가 팝 재시작에서도 유지됩니다. 팝이 대체되면 StatefulSet은 동일한 PersistentVolumeClaim를 다시 연결하므로 진단 데이터가 유지됩니다.

검색 팝에서 로컬 마신으로 FTDC 데이터를 복사합니다. 샤딩된 클러스터의 경우, 각 샤드별 검색 팝에서 로컬 마신으로 FTDC 데이터를 복사합니다. 모든 샤드에 대해 반복합니다.

kubectl cp -n ${MDB_NS} --context ${K8S_CTX} \
${MDB_SEARCH_RESOURCE_NAME}-search-0-${MDB_EXTERNAL_SHARD_0_NAME}-0:/mongot/data/diagnostic.data \
./mongot-diagnostic.data-${MDB_EXTERNAL_SHARD_0_NAME}