자체 관리형 mongot 배포서버 문제 해결

이 페이지에서는 단계별 복구 절차와 함께 Linux에서 또는 Docker 컨테이너에서 직접 실행하는 자체 관리형 mongot 배포에서 가장 일반적인 문제를 다룩니다. 각 시나리오에서는 이미 실패 모드를 식별했으며 이를 해결하기 위한 절차가 필요하다고 가정합니다.

참고

배포 범위

이 페이지는 Linux tarball 설치 또는 Docker 컨테이너와 같이 직접 실행하는 mongot 배포에 적용됩니다. MongoDB Controllers for Kubernetes 연산자로 mongot 를 배포하는 경우 Kubernetes 특정 문제 해결에 대한 자세한 내용은 MongoDB Controllers for Kubernetes 연산자 도서 를 참조하세요.

시작하기 전에

시나리오를 실행하기 전에 배포서버의 상태를 확인합니다.

지표 이상이 있지만 아직 무엇이 문제인지 모르는 경우 mongot의 지표 참조 의 지표 정의와 mongot의 권장 경고의 임계값으로 시작합니다.
최근에 배포서버 또는 구성 변경을 완료했다면 mongot 연결 확인으로 시작합니다.

증상이 어떤 시나리오와도 일치하지 않는 경우 지원을 위한 진단 캡처 에 설명된 대로 아티팩트를 캡처하고 지원 사례를 열어주세요.

`mongot` 시작되지 않음

mongot 프로세스는 시작한 후에 실행되지 않습니다.

증상

프로세스는 스타트업 후 수초 내에 종료됩니다.
컨테이너에서 프로세스가 루프로 다시 시작됩니다.
"ready" 로그 메시지가 표시되지 않습니다.

일반적인 원인

우선 순위:

설정 파일이 잘못되었거나 필요한 필드가 없습니다.
스타트업 시 mongod 에 대한 인증이 실패합니다.
mongot 구성된 주소에서 mongod 에 연결할 수 없습니다.
TLS 구성 오류가 발생합니다.
구성된 포트가 이미 사용 중입니다.
데이터 경로를 쓸 수 없습니다.

진단

최근 스타트업 로그 행을 검토합니다. 오류 메시지는 실패한 하위 시스템을 식별합니다.

docker logs --tail 100 <container-id>

journalctl -u mongot --no-pager | tail -n 200

tail -n 200 /var/log/mongot/mongot.log

다음 패턴을 찾습니다:

Failed to parse config file 유효하지 않은 YAML을 나타냅니다.
Authentication failed 또는 Unauthorized 은 자격 증명 또는 x.509 신뢰 문제를 나타냅니다.
Connection refused 또는 unable to connect to host 이(가) 호스팅이나 포트가 잘못되었음을 나타내거나 mongod 이(가) 실행중이 아닙음을 나타냅니다.
SSL handshake failed CA 신뢰 또는 인증서 SAN 불일치를 나타냅니다.
Address already in use 다른 프로세스가 동일한 포트에 바인딩되어 있음을 나타냅니다.
Cannot write to <dataPath> 권한 또는 경로 문제를 나타냅니다.

해결

구성: YAML을 수정합니다. 유효한 설정에 대해 알아보려면 mongot 구성을 참조하세요.
인증: 필요한 역할을 가진 사용자가 mongod 에 있는지 확인합니다. mongot에 대한 인증 및 권한 부여 구성을 참조하세요.
도달성: mongot 호스트에서 nc -zv <mongod-host> <mongod-port> 을 실행합니다. 방화벽, DNS 및 mongod bindIp 설정을 확인합니다.
TLS: mongot 와 mongod 모두 동일한 CA(인증서 발급 기관)를 신뢰하여 각 측의 인증서 체인이 신뢰할 수 있는 CA로 연결되도록 확인하세요. 또한 인증서 SAN이 mongot 가 사용하는 호스트 이름과 일치하는지도 확인하세요. mongot에 대한 TLS 암호화 구성을 참조하세요.
사용 중인 포트: ss -lntp 또는 lsof -i :<port>로 충돌되는 프로세스를 식별합니다. mongot 포트를 변경하거나 다른 프로세스를 중지합니다.
데이터 경로: 디렉토리가 존재하고 mongot 프로세스 사용자가 쓰기 가능한지 확인합니다. 필요에 따라 소유권 및 권한을 업데이트합니다.

연결 오류로 인해 쿼리 실패

mongod 이(가) mongot에 도달할 수 없어 쿼리가 실패했습니다.

증상

$search, $searchMeta 또는 $vectorSearch 쿼리는 Error connecting to <host>:<port> :: Connection refused 등의 연결 오류를 반환합니다.
또는 쿼리가 Error connecting to Search Index Management service을 반환합니다.

일반적인 원인

mongot mongod 이(가) 연결하려는 호스팅에서 실행되지 않습니다.
mongot 의 mongod 호스팅하 또는 포트 설정이 잘못되어 mongot 수신기와 일치하지 않습니다.
mongot 실행 중이지만 충돌했거나 다시 시작되는 중입니다.
TLS가 일치하지 않습니다. mongod 이(가) TLS용으로 구성되어 있지만 mongot 이(가) 구성되어 있지 않거나 그 반대입니다.

진단

mongod 호스팅하는 노드에서 mongot에 대한 연결을 테스트합니다.

nc -zv <mongot-host> <mongot-port>

mongot 호스트에서 프로세스가 실행 중이고 수신 중인지 확인합니다.

ps aux | grep '[m]ongot'
ss -lntp | grep <mongot-port>

mongod 로그에서 일치하는 오류와 구성된 mongot 호스트를 확인합니다.

grep -E 'mongotHost|searchIndexManagementHostAndPort' \
  /var/log/mongodb/mongod.log

해결

mongot 이(가) 실행되지 않은 경우 다시 실행합니다. 실행되지 않는 경우 mongot이 시작되지 않음을 참조하세요.
mongot 호스팅 설정이 잘못된 경우 mongod 매개변수를 수정하고 mongod를 다시 시작합니다.
TLS가 일치하지 않으면 양측의 TLS 구성을 일치시킵니다. mongot에 대한 TLS 암호화 구성을 참조하십시오.

`mongot` 계속 동기화

인덱스가 반복적으로 정상 상태에서 제거되고 초기 동기화를 시작합니다.

증상

로그는 Initial sync starting 이 반복된 후 예외를 표시합니다.
정상 상태에서 로그에는 Exception requiring resync occurred during steady state replication이 표시됩니다.
인덱스 관리자 상태는 INITIAL_SYNC로 다시 전환됩니다.
재동기화 창 동안 검색이 오래된 결과를 반환합니다.

일반적인 원인

mongod oplog가 mongot 이(가) 따라잡기 전에 롤오버되었습니다. 일반적으로 mongot 가 너무 느리거나 중단되었기 때문이거나 또는 oplog가 너무 작기 때문입니다.
네트워크 중단 또는 단기간의 mongod 재시작과 같은 일시적인 문제로 인해 정상 상태 예외가 발생했습니다. 단일 발생은 복구할 수 있지만 반복되는 발생은 복구할 수 없습니다.
문서 매핑 폭발이 mongot 힙을 겹치어 채우고 메모리 부족 오류를 트리거하고 다시 동기화합니다.
인덱스 데이터가 손상되었습니다.
매우 많은 수의 인덱스, 동적 매핑 또는 비용이 많이 드는 필드 선택은 지속적인 복제 지연을 유발합니다.

진단

다음 지표를 검토합니다.

mongot_replication_mongodb_indexManagerState INITIAL_SYNC 와 STEADY_STATE 사이의 순환입니다.
mongot_index_stats_numLuceneMaxDocs 순환이거나 고착되어 있습니다.
mongot_index_stats_indexing_replicationLagMs 계속 증가합니다.
mongot_jvm_memory_used_bytes 메모리 부하에서 mongot_jvm_gc_pause_seconds_sum 이(가) 증가합니다.

동기화 전에 발생한 오류를 확인하려면 mongot 로그를 찾아보세요. 그리고 oplog window와 힙을 확인합니다.

grep -E 'SteadyStateException|CappedPositionLost|OutOfMemoryError' \
  mongot.log

mongosh에서 mongod oplog 크기를 db.getReplicationInfo()로 확인합니다.

해결

oplog가 mongot 적용 속도에 비해 너무 작으면 mongod oplog 크기를 늘리거나 더 많은 mongot 용량이나 더 적은 동시 인덱스로 갑을 메우세요.
상태 유지 예외가 반복되면 FTDC를 캡처하고 지원 사례를 열어주세요.
문서 매핑 폭주를 위해 문제가 되는 인덱스를 찾습니다. 인덱스는 일반적으로 임의 키로 문서를 수집하는 dynamic: true 매핑을 가진 인덱스입니다. 정적 매핑 으로 전환하거나 필드 세트를 제한한 다음 mongot 를 다시 시작하여 힙 상태를 지우십시오.
드물게 발생하는 인덱스 손상의 경우 FTDC를 캡처한 후 해당 인덱스를 제거하고 다시 만듭합니다. 데이터 경로 및트에 있는 파일을 수동으로 삭제하지 마십시오.

OutOfMemory 오류 또는 OS에 의해 `mongot` 종료됨

mongot 메모리 부족으로 종료됩니다.

증상

mongot 예상치 못한 종료되고 컨테이너 재시작 횟수가 증가합니다.
로그는 JVM 측 메모리 부족 오류인 OutOfMemoryError: Java heap space으로 끝납니다.
dmesg 또는 journalctl 의 시스템 로그에서 OOM killer가 프로세스를 종료했음을 보여주는 호스트 측의 메모리 부족 오류입니다.

일반적인 원인

힙이 워크로드에 비해 너무 작습니다. 특히 초기 동기화 또는 병합이 큰 경우에 그렇습니다.
문서 매핑 폭발은 힙을 소비합니다. mongot 이(가) 계속 다시 동기화됩니다.를 참조하십시오.
컨테이너 메모리 제한이 너무 낮습니다. 힙 크기가 정확하더라도 JVM 비힙 오버헤드는 제한을 초과할 수 있습니다.
인덱스가 너무 많거나 비용이 많은 정의와 같은 인덱스 정의는 메모리 부하를 증가시킵니다.
메모리 누수가 발생합니다. 이는 드물지만 미리 보기 빌드에서는 가능합니다.

진단

다음 지표를 검토합니다.

mongot_jvm_memory_used_bytes 메모리 집중적인 쿼리와 인덱스 정의에 따라 증가합니다.
mongot_jvm_gc_pause_seconds_sum 가버리지 컬렉션 일시 중지에 소요된 누적 시간을 표시합니다.
machine_swap_bytes 건전한 배포서버에서는 거의 0에 가까운 수준을 유지합니다. 스와프 사용량은 심각한 메모리 부하를 나타냅니다.

mongot 로그에서 메모리 부족 스택 추적 및 구성된 힙 크기를 확인하십시오:

grep -E 'OutOfMemoryError|Java heap space' mongot.log
ps -ef | grep '[m]ongot' | grep -oE '\-Xmx[0-9a-zA-Z]+'

컨테이너의 경우 구성된 메모리 제한을 확인하세요.

docker inspect <container> | grep -i memory

해결

호스팅에 메모리 여유가 있는 경우 -Xmx 를 늘리세요.
컨테이너에서는 힙 오버헤드가 없도록 메모리 제한을 -Xmx 보다 훔씬 더 넣습니다. 시작점으로 컨테이너 제한을 최소한 -Xmx 값에 30% 를 더한 값으로 설정합니다.
힙이 충분히 클 경우에도 메모리가 부족하면 폭주하는 인덱싱 패턴을 찾아봅니다. mongot 로그에서 인덱스를 확인할 수 있습니다.
메모리 부하의 원인이면 인덱스 수를 줄이거나 비용이 많이 드는 인덱스 정의를 간단화합니다.
메모리 누수가 의심되는 경우 FTDC와 힙 덤프를 캡처하여 지원합니다.

초기 동기화가 느리거나 중단됨

새 인덱스가 초기 동기화를 완료하는 데 오래 걸립니다.

증상

인덱스 상태가 INITIAL_SYNC 에 오래 남아 있습니다.
복제 관리자가 초기 동기화를 다시 시도하기 전에 INITIAL_SYNC_BACKOFF 에 진입하는 경우가 있습니다.
mongot_index_stats_numLuceneMaxDocs 느리게만 증가합니다.
초기 동기화가 실행되는 동안에는 인덱스를 조회할 수 없습니다.

일반적인 원인

mongod 소스 호스트는 프로비전되지 않아 초기 동기화를 충분히 제공할 수 없습니다.
다른 곳의 디스크, CPU 또는 메모리 부하로 빌드가 느려집니다.
초기 백필이 많은 경우 현재 hardware 용량을 초과합니다.

진단

문서 증가를 위해 mongot_replication_mongodb_indexManagerState 과 mongot_index_stats_numLuceneMaxDocs 을 주시합니다.

초기 동기화 동안 mongot_index_stats_indexing_replicationLagMs 를 권한적으로 간주하지 마십시오. 이 지표는 초기 동기화 동안 의미 있게 채워지지 않습니다. 대신 시스템 헬스 지표를 검토하여 시스템에 충분한 리소스가 있는지 확인합니다.

해결

병목이면 mongod 소스 호스트를 확장합니다.
시스템 리소스가 제한된 곳에 CPU 또는 메모리를 추가합니다.
초기 빌드를 다시 시도하기 전에 디스크 여유 공간을 다시 확인하세요.

대기 중 또는 빌드 중 상태에 고정된 인덱스

인덱스가 PENDING 또는 BUILDING 상태를 넘어 진행되지 않습니다.

증상

인덱스가 크지 않은 컬렉션에서 PENDING 또는 BUILDING 에 수분 이상 유지됩니다.
mongot 로그에는 실패가 없고 진행 상황이 없을 뿐입니다.

일반적인 원인

mongot 동기화 진행이 이루어지지 않습니다. 복제 지연을 참조하세요.
자동 임베딩 인덱스에서 임베딩 엔드포인트가 실패하고 있습니다.
인덱싱 실행자 푸른 다른 인덱스가 동시에 구축되어 포화됩니다.
mongot 최근 다시 시작되었으며 인덱스가 동기화되고 있습니다.
정의가 허용되었으면도 디스크 부하로 인해 새 빌드 또는 리빌드가 일시 중지되었습니다.

진단

진행 사항은 mongot_replication_mongodb_indexManagerState 및 mongot_index_stats_numLuceneMaxDocs 을 검토하세요.

mongosh에서 인덱스 상태 및 오류 필드를 확인합니다.

db.<collection>.getSearchIndexes()

인덱싱 처리량이 증가하고 있는지 확인합니다.

rate(mongot_index_stats_indexing_insert_total[5m])

자동 임베딩 인덱스의 경우 임베딩 재시도 카운터가 0보다 큰지 확인합니다.

rate(mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total[5m])
rate(mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total[5m])

해결

인덱싱 처리량이 일정하게 유지되면 mongot 로그에서 인덱스 이름과 예외사항을 검토합니다.
임베딩 재시도가 0보다 큰 경우 임베딩 경로를 수정합니다. MongoDB 벡터 검색 자동 임베딩을 위한 mongot 구성을 참조하세요.
실행자 푸이가 포화되면 동시 인덱스 생성을 줄이거나 mongot을 확장합니다.
디스크가 불록이면 여유 공간을 추가하거나 빌드를 더 큰 노드로 이동합니다.

쿼리가 빈 결과를 반환합니다

일치하는 문서가 존재하지만 쿼리에서 결과가 반환되지 않습니다.

증상

검색 인덱스에서 찾을 것으로 예상되는 문서에서 findOne() 을 실행할 수 있습니다.
동일한 필드에 대한 $search 쿼리는 아무 것도 반환하지 않거나 예상보다 적은 결과를 반환합니다.

일반적인 원인

인덱스가 일치할 것으로 예상되는 문서에 대한 인덱스 구축이 완료되지 않았습니다.
복제 지연은 mongot 이 아직 문서를 받지 못했음을 의미합니다.
인덱스 정의가 검색하는 필드를 포함하지 않습니다.
쿼리 표현식이 잘못되었습니다. 예를 들어 string으로 인덱스된 필드에 대한 숫자 표현식입니다.
특정 문서에 대한 인덱싱이 실패했습니다.

진단

mongosh에서 인덱스 상태를 확인하고 인덱스가 문서를 보았는지 확인합니다.

db.<collection>.getSearchIndexes()

그러한 다음 복제 지연이 있는지 확인하려면 mongot_index_stats_indexing_replicationLagMs 을 검토하십시오.

해결

인덱스가 준비 상태에 도달할 때까지 기다립니다.
복제 지연이 해제될 때까지 기다리세요.
인덱스 정의 또는 쿼리를 조정합니다.
특정 문서에 대한 인덱싱이 실패하면 mongot 로그에서 실패 원인을 확인할 수 있습니다. 해당 문서를 수정하거나 필터링합니다.

CPU Saturation or Throttling

지속적인 CPU 부하는 쿼리 및 복제 성능을 저하시킵니다.

증상

지속된 CPU 부하에서는 쿼리 지연 시간이 증가합니다.
쿼리 작업과 인덱싱 작업이 CPU를 경쟁하므로 복제 지연이 증가합니다.
심각한 경우 상태 확인이 실패하고 프로세스가 다시 시작됩니다.

일반적인 원인

mongot 호스트는 현재 쿼리 및 인덱싱 작업 혼합에 대해 자원이 부족합니다.
너무 많은 동시 인덱싱 작업이 쿼리 실행과 경쟁합니다.
워크로드는 부하 조절 또는 용량 확장이 필요합니다.

진단

다음 지표를 검토합니다.

mongot_command_searchCommandTotalLatency_seconds_max
mongot_index_stats_indexing_replicationLagMs
호스팅 CPU 및 부하 지표는 포화 시 급증합니다.

호스트가 CPU 제한되었음을 나타내는 명시적인 로그 메시지는 없습니다.

해결

mongot 호스트에서 CPU를 확장합니다.
가능한 경우 부하 제거 프락티스를 통해 부하를 줄이십시오.
복제 작업이 쿼리와 경쟁하는 경우 인덱싱 작업을 간소화합니다.

디스크 압력 또는 데이터 경로가 거의 가득 차있음

mongot 데이터 경로의 자유 공간이 부족합니다.

증상

mongot 데이터 경로의 자유 공간이 0에 가까워집니다.
디스크 사용량이 높으면 기존 인덱스에 복제 지연이 누적됩니다.
디스크 부하가 심한 경우 새 인덱스 또는 재구축된 인덱스가 INITIAL_SYNC 에 계속 남아 있을 수 있습니다.
디스크 보호를 위해 복제가 일시 중지되는 동안에도 쿼리가 계속해서 성공합니다.

일반적인 원인

호스트에는 일반적인 인덱싱 성장을 위한 출분한 자유 공간이 없습니다.
새 인덱스 또는 다시 빌드된 인덱스에는 현재 디스크가 제공할 수 있는 것보다 더 많은 임시 여유 공간이 필요합니다.

진단

다음 지표를 검토합니다.

mongot_system_disk_space_data_path_free_bytes 데이터 디렉토리의 자유 바이트를 보고합니다.
mongot_system_disk_space_data_path_total_bytes 데이터 디렉토리의 총 바이트를 보고합니다.

디스크 임계값에 연결된 복제 일시 중지 동작을 주시합시오. 디스크 사용량이 대략 90% 초과하면 복제가 중지되고 사용량이 대략 85% 미만으로 내려가면 다시 시작됩니다. 새 인덱스 또는 다시 빌드의 경우, 디스크 압력이 이미 보호 임계값을 초과하는 경우 정의는 허용되지만 빌드는 계속 고착될 것입니다.

해결

호스트 또는 볼륨을 안전하게 확장할 수 있는 경우 디스크 용량을 추가합니다.
작업상 허용되는 경우 불필요한 인덱스를 삭제하여 공간을 확보합니다.
대규모 인덱스를 빌드하거나 다시 빌드하기 전에 예비 여유 공간을 확보합니다. 다시 빌드 시 예상되는 정상 상태 발자국의 약 125% 을 계획합니다.
로컬 인스턴스 저장 NVMe에서는 제자리에서 크기를 조정할 수 있다고 가정하지 마십시오. 로컬 인스턴스 저장 용량이 초과하면 일반적으로 더 큰 머신 클래스와 인덱스 재생성이 필요합니다.
EBS 기반 저장을 사용하는 경우 라이브 크기 조정이 더 쉽지만 NVMe는 mongot 성능에 대한 지침으로 계속 선호됩니다. mongot에 대한 저장 클래스 권장 사항을 참조하세요.

16 MB BSON 제한으로 인한 복제 지연

변경 스트림 이벤트가 16 MB BSON 제한을 초과하여 복제가 중단됩니다.

증상

인덱스는 안정상태 복제 오류 발생 후 오래되거나 다시 빌드되기 시작됩니다.
getMore 동안 mongot 로그에 change stream payload exceeding 16MB BSON limit, BSONObjectTooLarge 또는 오류 코드 10334 이 표시됩니다.
저장된 문서가 16 MB보다 작아 보일 수 있지만 장애는 여전히 발생합니다.

일반적인 원인

변경 스트림 이벤트에 문서와 추가 변경 스트림 메타데이터가 모두 포함되어 16 MB를 초과합니다.
이미 크게 저장된 문서에 대한 대규모 업데이트는 변경 스트림 페이로드를 저장된 문서 크기만으로 제시되는 것보다 크게 만듭니다.

진단

다음 지표를 검토합니다.

mongot_changestream_numSplitEvents_total 16 MB 페이로드 크기를 초과한 이벤트를 계수합니다.
mongot_index_stats_indexing_replicationLagMs 특정 인덱스의 복제 지연을 보고합니다.

mongot 로그에서 다음 문자열을 검색합니다.

change stream payload exceeding 16MB BSON limit
BSONObjectTooLarge
Executor error during getMore
code 10334

문서 크기 검사에서 가장 큰 문서가 16 MB 미만인 경우에는 이 시나리오를 배제하지 마세요. 변경 이벤트에는 문서 자체 외에 메타데이터가 포함됩니다.

해결

문서 크기를 줄이고 가능한 경우 이미 큰 문서에 대한 큰 업데이트를 피합니다.
가능한 경우 기존의 큰 문서에 큰 업데이트를 적용핕는 대신 문서를 대체합니다.
대부분의 쓰기 작업이 업데이트인 경우 업데이트 쿼리를 검토하여 변경 스트림 이벤트 메타데이터 크기를 줄이십시오.
워크로드를 수정한 후 다시 빌드가 완료될 때까지 기다립니다. 워크로드 패턴이 변경되지 않으면 인덱스에서 동일한 실패가 다시 발생할 수 있습니다.
워크로드를 조정한 후에도 문제가 반복되면 로그를 캡처하고 사고 세부 정보를 포함하여 에스칼레이트합니다.

복제 지연이 큼게 발생

복제 지연은 시간이 지남에 따라 계속적으로 증가합니다.

증상

복제 지연이 꾸준히 증가하여 수 시간 또는 수 일에 이를 수 있습니다.
mongot 메모리가 제한되거나 지속적으로 메모리가 부족하여 유지하려고 할 때 반복적으로 메모리가 고갈됩니다.
호스트는 여전히 쿼리를 제공할 수 있지만 복제 작업과 큰 인덱스 프린트로 인해 쿼리 성능이 저하될 수 있습니다.

일반적인 원인

인덱스 수가 매우 많으면 복제 및 인덱싱 오버헤드가 증가합니다.
dynamic: true 을 널리 사용하면 필드 수와 인덱스 크기가 증가하여 메모리 부하가 높아집니다.
반복되는 메모리 부족 이벤트는 지연을 악화시키고 지표를 불규칙하거나 부완적이게 보이게 합니다.
병목 현상은 원본 데이터베이스에 있습니다. CPU 및 캐시 압력이 높은 mongod 세컨더리가 부족하게 프로비저닝되면 변경 스트림 이벤트가 충분히 빠르게 발생하지 않을 수 있습니다.

진단

다음 지표를 검토합니다.

mongot_index_stats_indexing_replicationLagMs 특정 인덱스의 복제 지연을 보고합니다.
mongot_indexing_steadyStateChangeStream_getMoresScheduled 예정된 getMore 작업을 보고합니다.
mongot_replication_mongodb_indexManagerState 진행되지 않는 인덱스를 식별합니다.
mongot_jvm_memory_used_bytes 호스팅 CPU 및 로드 지표에서 리소스 부하가 나타납니다.

인덱스의 총 개수를 세고 인덱스의 많은 부분이 dynamic: true 에 의지하거나 불필요한 고카디널리티 필드를 인덱스하는지 검토합니다.

해결

노드에 메모리가 부족하거나 메모리가 제한된 경우 mongot CPU 및 메모리를 먼저 확장합니다.
총 인덱스 수를 줄이십시오. 인덱스 수가 매우 많은 경우 먼저 변경 스트림 부하를 제어하지 않으면 검색 노드를 추가하면 부하 패턴이 악화될 수 있습니다.
필요하지 않은 경우 동적 스키마 매핑을 꺼십니다. dynamic: false 을(를) 선택하고 쿼리에 필요한 하위 필드만 명시적으로 매핑합니다.
인덱스된 필드, 특히 타임스탬프 또는 사용자 ID와 같은 카디날리티가 높은 필드의 수를 줄이고, 패싯에 사용되지 않는 깊은 패싯 매핑을 제거합니다.
mongod 세컨더리가 병목이면 코어 데이터베이스를 확장하여 변경 스트림 처리량을 개선합니다.

TLS 핸드셔이크 실패

mongot 와 mongod 간의 TLS 핸드쉐이크가 실패합니다.

증상

mongot 로그에 SSL handshake failed, Certificate verification failed 또는 bad certificate이 표시됩니다.
mongod 로그에는 mongot에 연결하려고 할 때 유사한 오류가 표시됩니다.

일반적인 원인

CA 불일치: 양쪽 모두 동일한 CA를 신뢰하지 않습니다.
인증서 SAN에는 사용 중인 호스트 이름이 포함되지 않습니다.
인증서가 만료되었습니다.
TLS 모드 불일치: 한 측에서는 TLS가 필요하고 다른 측에서는 비활성화되었습니다.
암호 스위트 또는 TLS 버전이 일치하지 않는 경우(드물게 발생).

진단

각 측이 제공하는 인증서를 검사하고 CA에 대하여 체인을 확인합니다.

openssl s_client -connect <mongot-host>:<mongot-port> -showcerts
openssl s_client -connect <mongod-host>:<mongod-port> -showcerts
openssl verify -CAfile <ca-bundle> <cert-file>
openssl x509 -in <cert-file> -text -noout

해결

올바른 CA를 양쪽 엔드포인트에 배포합니다.
올바른 SAN 목록으로 인증서를 재발급합니다.
만료된 인증서를 갱신합니다.
양측의 TLS 모드를 일치시킵니다. mongot에 대한 TLS 암호화 구성을 참조하십시오.

인덱스가 Lucene 문서 제한에 도달합니다.

단일 인덱스가 Lucene 최대 문서 수를 초과합니다.

증상

매우 큰 인덱스는 Lucene 문서 개수 제한 값 과까지 앞으로 진행하지 않습니다.
로그에 java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519이(가) 표시됩니다.
mongot_index_stats_numLuceneMaxDocs 하드 제한에 도달하고 제한에 도달하면 개시가 중단될 수 있습니다.
인덱스 관리자 상태가 실패 상태로 변경됩니다.

일반적인 원인

단일 분할되지 않은 인덱스가 Lucene의 최대 문서 수 2147483519를 초과했습니다.
새 인덱스가 허용되고 빌드되기 시작되었지만 동일한 하드 제한에 도달하자 실패했습니다.

진단

이 실패 모드의 프라이머리 예방 신호로 mongot_index_stats_numLuceneMaxDocs 를 주시하고 로그에서 정확한 예외 string을 확인합니다.

java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519

해결

각 분할이 Lucene 문서 개수 제한을 초과하지 않도록 인덱스를 분할한 다음 numPartitions 을(를) 적절하게 설정하여 인덱스를 다시 빌드합니다. 트레이드오프하는 분할이 여러 분할에 걸쳐 쿼리 팬아웃을 요구할 수 있으며 검색 성능에 영향을 미칠 수 있으므로 이를 고려해야 합니다.

{
  "numPartitions": 4,
  "mappings": {
    "dynamic": true
  }
}

자동화된 임베딩 실패

자동 임베딩 인덱스는 임베딩 엔드포인트에 도달할 수 없습니다.

증상

자동 임베딩 인덱스는 PENDING 또는 BUILDING 상태에 있습니다.
mongot 로그에는 임베딩 엔드포인트에 대한 오류가 표시됩니다.
임베딩 재시도 카운터 mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total 또는 mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total 이 0보다 큽니다. 이 카운터를 간접 지표로 사용하고 임베딩 엔드포인트에서 실제 HTTP 오류를 로그에서 확인합니다.

일반적인 원인

모델 API 키가 유효하지 않거나 만료되었습니다.
네트워크가 임베딩 엔드포인트에 액세스할 수 없습니다.
임베딩 제공자가 요청의 전송 속도를 제한하고 있습니다.
임베딩 제공자에 장애가 발생했습니다.

진단

mongot 호스트에서 임베딩 엔드포인트로의 연결을 테스트한 후 로그를 확인합니다.

grep -E 'voyage|embedding' mongot.log

해결

모델 API 키를 바꾸고 mongot을 다시 시작합니다.
임베딩 엔드포인트에 대한 네트워크 유출을 열어야 합니다.
제공자가 요청을 제한하는 경우 제한을 높히거나 인덱싱 동시성을 줄입니다.
제공자에 장애가 발생하면 Voyage AI 상태 를 모니터링하고 엔드포인트 전환을 고려해야 합니다.

전체 임베딩 구성 모델에 대한 자세한 내용은 MongoDB 벡터 검색 자동 임베딩을 위한 mongot 구성을 참조하십시오.

유지되는 IOPS 또는 페이지 볼트와 같은 저장 신호

지속된 저장 IOPS 또는 페이지 오류는 저장 병목을 나타냅니다. 로컬 NVMe에서 실행하는 경우 먼저 메모리 여유 공간을 확인합니다. SAN, 일반 목적 클라우드 SSD 또는 SATA SSD와 같은 다른 저장 클래스에서 실행하는 경우 저장 클래스가 원인일 가능성이 높으며 마이그레이션이 필요합니다. mongot에 대한 저장 클래스 권장을 참조하십시오.

명백한 원인 없이 성능 저하

최근 배포 변경 없이 성능이 퇴화됩니다.

증상

배포서버 변경 사항이 명확하지 않은 상태에서 쿼리 지연 시간이 증가했습니다.
CPU 또는 메모리 사용량이 증가했습니다.

일반적인 원인

워크로드가 변경되어 쿼리가 더 많아지거나 더 커졌습니다.
새 인덱스가 이제 리소스를 소비합니다.
문서 매핑 폭발이 힙을 소비합니다.
소음 이웃, RAID 다시 빌드 또는 클라우드 공급자 문제 등의 저하된 저장.
JVM 업데이트 후 컬렉션 튜닝 퇴행이 발생했습니다.

진단

쿼리 지연 시간, 힙, 실행자 큐, 저장 IOPS 등 지표를 증상별로 피버팅합니다. 지표 정의 및 임계값에 대한 자세한 내용은 mongot의 지표 참조 및 mongot의 권장 경고를 참조하십시오.

해결

해결책은 원인에 따라 다릅니다. 옵션에는 확장, 용량 계획 또는 인덱스 검토(예: 사용하지 않는 인덱스 제거 및 매핑 정제) 등이 포함됩니다.

지원을 위한 진단 캡처

문제를 로컬에서 해결할 수 없는 경우 지원 사례를 열기 전에 다음 내용을 캡처하세요.

mongot 문제 발생 시간 이전 1시간을 포함하여 문제 시간을 다루는 로그입니다. 동일한 창에 대해 mongod 로그를 전송합니다.
영향을 받은 mongot 인스턴스에 대한 FTDC. mongot 로그 및 FTDC를 참조하십시오.
문제 시간 대역의 지표 대시보드 스냅샷입니다.
mongot 및 mongod의 버전.
변경된 내용(최근 배포서버, 구성 변경 또는 트래픽 패턴 등).
온디맨드로 문제를 재현할 수 있는 경우 문제 재현 단계입니다.

돌아가기

모니터링 도구 통합

제한 사항

자체 관리형 mongot 배포서버 문제 해결

참고

배포 범위

시작하기 전에

mongot 시작되지 않음

연결 오류로 인해 쿼리 실패

mongot 계속 동기화

OutOfMemory 오류 또는 OS에 의해 mongot 종료됨

초기 동기화가 느리거나 중단됨

대기 중 또는 빌드 중 상태에 고정된 인덱스

쿼리가 빈 결과를 반환합니다

CPU Saturation or Throttling

디스크 압력 또는 데이터 경로가 거의 가득 차있음

16 MB BSON 제한으로 인한 복제 지연

복제 지연이 큼게 발생

TLS 핸드셔이크 실패

인덱스가 Lucene 문서 제한에 도달합니다.

자동화된 임베딩 실패

유지되는 IOPS 또는 페이지 볼트와 같은 저장 신호

명백한 원인 없이 성능 저하

지원을 위한 진단 캡처

`mongot` 시작되지 않음

`mongot` 계속 동기화

OutOfMemory 오류 또는 OS에 의해 `mongot` 종료됨