Elasticsearch 마이그레이션을 사용할 때 다음과 같은 문제가 발생할 수 있습니다.

elasticsearch.log에 오류가 포함되어 있고 실패한 마이그레이션을 다시 시도해도 작동하지 않으면 GitLab 지원에 문의하세요. 자세한 내용은 고급 검색 마이그레이션을 참조하세요.

오류: Elasticsearch::Transport::Transport::Errors::BadRequest#

유사한 예외가 발생하면 올바른 Elasticsearch 버전을 사용하고 시스템 요구 사항을 충족하는지 확인하세요. sudo gitlab-rake gitlab:check 명령을 사용하여 버전을 자동으로 확인할 수도 있습니다.

오류: Faraday::TimeoutError (execution expired)#

프록시를 사용하는 경우 Elasticsearch 호스트의 IP 주소로 no_proxy라는 사용자 정의 gitlab_rails['env'] 환경 변수를 설정합니다.

단일 노드 Elasticsearch 클러스터 상태가 yellow에서 green으로 변경되지 않음#

단일 노드 Elasticsearch 클러스터의 경우 기능적 클러스터 상태는 yellow입니다(green이 아님). 그 이유는 기본 샤드가 할당되지만 Elasticsearch가 레플리카를 할당할 수 있는 다른 노드가 없기 때문에 레플리카를 만들 수 없기 때문입니다. 이는 Amazon OpenSearch 서비스를 사용하는 경우에도 적용됩니다.

단일 노드 Elasticsearch 클러스터에서 green 상태를 원한다면 위험을 이해하고 다음 쿼리를 실행하여 레플리카 수를 0으로 설정합니다. 클러스터는 더 이상 샤드 레플리카를 만들려고 시도하지 않습니다.

curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
     --data '{
       "index" : {
         "number_of_replicas" : 0
       }
     }'

오류: health check timeout: no Elasticsearch node available#

인덱싱 프로세스 중 Sidekiq에서 health check timeout: no Elasticsearch node available 오류가 발생하는 경우:

Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="health check timeout: no Elasticsearch node available"

Elasticsearch 통합 메뉴의 "URL" 필드 값에 http:// 또는 https://를 사용하지 않았을 가능성이 높습니다. Go용 Elasticsearch 클라이언트가 URL 접두사를 유효한 형식으로 허용하기 위해 필요하므로 이 필드의 URL 형식을 확인합니다. URL 형식을 수정한 후 인덱스를 삭제하고 인스턴스 콘텐츠를 다시 인덱싱합니다.

Elasticsearch가 일부 타사 플러그인과 작동하지 않음#

특정 타사 플러그인은 클러스터에 버그를 도입하거나 통합과 호환되지 않을 수 있습니다.

Elasticsearch 클러스터에 타사 플러그인이 있고 통합이 작동하지 않으면 플러그인을 비활성화해 보세요.

Elasticsearch 워커가 Sidekiq를 과부하#

경우에 따라 다음과 같은 이유로 Elasticsearch가 더 이상 GitLab에 연결할 수 없습니다:

• 한쪽에서만 Elasticsearch 비밀번호가 업데이트된 경우(Unauthorized [401] ... unable to authenticate user 오류).

• 방화벽 또는 네트워크 문제로 연결이 손상된 경우(Failed to open TCP connection to <ip>:9200 오류).

이 오류는 gitlab-rails/elasticsearch.log에 기록됩니다. 오류를 검색하려면 jq를 사용합니다:

$ jq --raw-output 'select(.severity == "ERROR") | [.error_class, .error_message] | @tsv' \
    gitlab-rails/elasticsearch.log |
  sort | uniq -c

이전 job이 실패하면 Elasticsearch가 자주 재인덱싱을 시도하기 때문에 Elastic 워커와 Sidekiq job이 훨씬 더 자주 나타날 수도 있습니다. fast-stats 또는 jq를 사용하여 Sidekiq 로그에서 워커를 집계할 수 있습니다:

$ fast-stats --print-fields=count,score sidekiq/current
WORKER                            COUNT   SCORE
Search::Elastic::IndexBulkCronWorker  234  123456
ElasticIndexInitialBulkCronWorker     345   12345
Some::OtherWorker                      12     123
...

$ jq '.class' sidekiq/current | sort | uniq -c | sort -nr
 234 "ElasticIndexInitialBulkCronWorker"
 345 "Search::Elastic::IndexBulkCronWorker"
  12 "Some::OtherWorker"
...

이 경우 과부하된 GitLab 노드에서 free -m을 실행하면 예상외로 높은 buff/cache 사용량도 표시됩니다.