파일 내보내기 프로젝트 마이그레이션 문제 해결

migrating projects using file exports에 문제가 있는 경우, 아래 가능한 해결책을 참조하십시오.

문제 해결 명령어

JID를 사용하여 가져오기 상태 및 추가 로그에 대한 정보를 찾으려면 Rails console를 사용하십시오:

Project.find_by_full_path('group/project').import_state.slice(:jid, :status, :last_error)
> {"jid"=>"414dec93f941a593ea1a6894", "status"=>"finished", "last_error"=>nil}
# 로그
grep JID /var/log/gitlab/sidekiq/current
grep "Import/Export error" /var/log/gitlab/sidekiq/current
grep "Import/Export backtrace" /var/log/gitlab/sidekiq/current
tail /var/log/gitlab/gitlab-rails/importer.log

불일치로 인해 프로젝트 가져오기 실패

instance runners enablement가 내보낸 프로젝트와 프로젝트 가져오기간의 일치하지 않음으로 프로젝트 가져오기가 실패합니다. 이슈 276930를 확인하고 다음 중 하나를 수행하십시오:

  • 소스 및 대상 프로젝트에서 인스턴스 러너가 활성화되어 있는지 확인합니다.
  • 프로젝트를 가져올 때 부모 그룹에서 인스턴스 러너를 비활성화합니다.

가져온 프로젝트에 누락된 사용자

수입된 프로젝트에 사용자가 함께 가져오지 않은 경우 사용자 기여 보존 요구사항을 확인하십시오.

누락된 사용자의 일반적인 이유는 사용자의 public email setting이 구성되어 있지 않은 것입니다. 이 문제를 해결하려면 사용자들에게 GitLab UI를 사용하여 이 설정을 구성하도록 요청하십시오.

수동 구성이 너무 많은 사용자의 경우, Rails console를 사용하여 모든 사용자 프로필을 공개 이메일 주소를 사용하도록 설정할 수 있습니다:

User.where("public_email IS NULL OR public_email = '' ").find_each do |u|
  next if u.bot?

  puts "#{u.username}의 현재 비어있는 공개 이메일을 #{u.email}로 설정 중..."
  u.public_email = u.email
  u.save!
end

대규모 리포지토리 가져오기 우회 방법

최대 가져오기 크기 제한으로 가져오기가 성공적으로 완료되지 못할 수 있습니다. 가져오기 제한을 변경할 수 없는 경우 여기 나열된 우회 방법 중 하나를 시도할 수 있습니다.

우회 옵션 1

임시로 저장소 크기를 줄이기 위한 다음 로컬 워크플로우를 사용할 수 있습니다.

  1. 내보낸 파일에서 임시 작업 디렉토리를 만듭니다:

    EXPORT=<확장자 없는 파일명>
    
    mkdir "$EXPORT"
    tar -xf "$EXPORT".tar.gz --directory="$EXPORT"/
    cd "$EXPORT"/
    git clone project.bundle
    
    # 나중에 가져오기 가능한 파일을 재생성하는 데 방해하지 않도록
    mv project.bundle ../"$EXPORT"-original.bundle
    mv ../"$EXPORT".tar.gz ../"$EXPORT"-original.tar.gz
    
    git switch --create smaller-tmp-main
    
  2. 저장소 크기를 줄이기 위해 smaller-tmp-main 브랜치에서 작업합니다: 큰 파일 식별 및 삭제하거나 대화식 리베이스 및 fixup을 사용하여 커밋 수를 줄입니다.

    # .git/objects/pack/ 파일 크기 줄이기
    cd project
    git reflog expire --expire=now --all
    git gc --prune=now --aggressive
    
    # 가져오기 가능한 파일을 재생성 준비
    git bundle create ../project.bundle <default-branch-name>
    cd ..
    mv project/ ../"$EXPORT"-project
    cd ..
    
    # 가져오기 가능한 파일 재생성
    tar -czf "$EXPORT"-smaller.tar.gz --directory="$EXPORT"/ .
    
  3. 이 새로운, 작은 파일을 GitLab에 가져옵니다.
  4. 원본 리포지토리의 완전한 복제에서 git remote set-url origin <new-url> && git push --force --all을 사용하여 가져오기를 완료합니다.
  5. 가져온 리포지토리의 브랜치 보호 규칙기본 브랜치를 업데이트하고, 임시 smaller-tmp-main 브랜치와 로컬 임시 데이터를 삭제하십시오.

우회 옵션 2

참고: 이 우회 방법은 LFS(Large File Storage) 객체를 고려하지 않습니다.

이 방법은 모든 변경 사항을 한꺼번에 푸시하려는 대신:

  • 프로젝트 가져오기와 Git 리포지토리 가져오기를 분리합니다.
  • 리포지토리를 점진적으로 GitLab에 푸시합니다.
  1. 마이그레이션할 리포지토리의 로컬 복제본을 만듭니다. 나중에 이 복제본을 프로젝트 내보내기 밖에서 푸시합니다.
  2. 내보내기를 다운로드하고 project.bundle (Git 리포지토리를 포함하는)를 제거합니다:

    tar -czvf new_export.tar.gz --exclude='project.bundle' @old_export.tar.gz
    
  3. Git 리포지토리 없이 내보내기를 가져옵니다. 리포지토리 없이 가져오기를 확인하도록 요청합니다.
  4. 해당 origin을 추가한 후 이 bash 스크립트를 파일로 저장하고 실행하십시오.

    #!/bin/sh
    
    # 가정사항:
    # - GitLab 위치가 "origin"임
    # - 기본 브랜치가 "main"임
    # - 전체 크기를 500MB(총 크기를 500MB로 나눔)로 나누어 푸시하려는 경우
    #   여전히 타임아웃을 받으면 더 작은 크기로 해서 푸시하도록 크기를 줄이십시오.
    
    git gc
    SIZE=$(git count-objects -v 2> /dev/null | grep size-pack | awk '{print $2}')
    
    # 보수적으로... 모든 커밋이 같은 크기라고 가정하고 2GB씩 푸시하려고합니다
    # (각 커밋이 같은 크기라고 가정하는 것으로 잘못됐음)
    BATCHES=$(($SIZE / 500000))
    TOTAL_COMMITS=$(git rev-list --count HEAD)
    if (( BATCHES > TOTAL_COMMITS )); then
        BATCHES=$TOTAL_COMMITS
    fi
    
    INCREMENTS=$(( ($TOTAL_COMMITS / $BATCHES) - 1 ))
    
    for (( BATCH=BATCHES; BATCH>=1; BATCH-- ))
    do
      COMMIT_NUM=$(( $BATCH - $INCREMENTS ))
      COMMIT_SHA=$(git log -n $COMMIT_NUM --format=format:%H | tail -1)
      git push -u origin ${COMMIT_SHA}:refs/heads/main
    done
    git push -u origin main
    git push -u origin --all
    git push -u origin --tags
    

수동으로 내보내기 단계 실행

보통 웹 인터페이스API를 통해 프로젝트를 내보냅니다. 이 방법으로 내보내기를 할 때 가끔은 충분한 정보를 제공하지 않아 실패할 수 있습니다. 이럴 때는 Rails 콘솔 세션을 열고 정의된 모든 내보내기 도구를 순회하며 각 줄을 개별적으로 실행하여 각 명령이 반환하는 오류를 볼 수 있도록 합니다.

# 사용자는 내보내기 권한이 있어야 함
u = User.find_by_username('someuser')
p = Project.find_by_full_path('some/project')
e = Projects::ImportExport::ExportService.new(p,u)

e.send(:version_saver).send(:save)
e.send(:repo_saver).send(:save)
e.send(:avatar_saver).send(:save)
e.send(:project_tree_saver).send(:save)
e.send(:uploads_saver).send(:save)
e.send(:wiki_repo_saver).send(:save)
e.send(:lfs_saver).send(:save)
e.send(:snippets_repo_saver).send(:save)
e.send(:design_repo_saver).send(:save)
## `e.send(:exporter_name).send(:save)`를 통해 목록의 모든 내보내기 도구를 실행해주세요

# 다음 줄은 /var/opt/gitlab/gitlab-rails/shared/tmp/gitlab_exports/@hashed/49/94/4994....
s = Gitlab::ImportExport::Saver.new(exportable: p, shared:p.import_export_shared)

# 업로드를 시도하려면:
s.send(:compress_and_save)
s.send(:save_upload)

프로젝트가 성공적으로 업로드된 후, 내보낸 프로젝트는 /var/opt/gitlab/gitlab-rails/uploads/-/system/import_export_upload/export_file/ 내부의 .tar.gz 파일에 위치합니다.

REST API를 사용한 가져오기가 그룹 액세스 토큰 사용 시 실패하는 경우

그룹 액세스 토큰은 프로젝트나 그룹 가져오기 작업에 대해 작동하지 않습니다. 그룹 액세스 토큰으로 가져오기를 시작하면 다음 메시지와 함께 가져오기가 실패합니다.

Error adding importer user to Project members.
Validation failed: User project bots cannot be added to other groups / projects

Import REST API를 사용하려면 개인 엑세스 토큰과 같은 일반 사용자 계정 자격 증명을 전달하세요.

성능 문제 해결

아래의 가져오기/내보내기를 통해 현재 성능 문제를 읽어보세요.

OOM 에러

OOM(Out of memory) 에러는 보통 Sidekiq Memory Killer에 의해 발생합니다:

SIDEKIQ_MEMORY_KILLER_MAX_RSS = 2000000
SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000
SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900

가져오기 상태가 started이며 다음의 Sidekiq 로그에서 메모리 문제가 신호를 보냅니다:

WARN: Work still in progress <struct with JID>

타임아웃

타임아웃 에러는 Gitlab::Import::StuckProjectImportJobsWorker가 프로세스를 실패로 표시할 때 발생합니다:

module Gitlab
  module Import
    class StuckProjectImportJobsWorker
      include Gitlab::Import::StuckImportJob
      # ...
    end
  end
end

module Gitlab
  module Import
    module StuckImportJob
      # ...
      IMPORT_JOBS_EXPIRATION = 15.hours.to_i
      # ...
      def perform
        stuck_imports_without_jid_count = mark_imports_without_jid_as_failed!
        stuck_imports_with_jid_count = mark_imports_with_jid_as_failed!

        track_metrics(stuck_imports_with_jid_count, stuck_imports_without_jid_count)
      end
      # ...
    end
  end
end
Marked stuck import jobs as failed. JIDs: xyz
  +-----------+    +-----------------------------------+
  |Export Job |--->| Calls ActiveRecord 'as_json' and   |
  +-----------+    | 'to_json' on all project models    |
                   +-----------------------------------+

  +-----------+    +-----------------------------------+
  |Import Job |--->| Loads all JSON in memory, then    |
  +-----------+    | inserts into the DB in batches    |
                   +-----------------------------------+

문제 및 해결책

문제 가능한 해결책
데이터베이스에서 모델을 느리게 로드/덤프하는 Slow JSON 워커 분할
  일괄 내보내기
  SQL 최적화
  ActiveRecord 콜백 변경 (어려움)
높은 메모리 사용 (일부 분석도 참조) 덜 메모리를 사용하는 DB Commit sweet spot
  Netflix Fast JSON API가 도움이 될 수 있음
  디스크 및 SQL에 일괄적인 읽기/쓰기

임시 해결책

성능 문제를 해결하지 못하는 동안 대형 프로젝트를 가져오는 프로세스가 있습니다. 이를 위해 고객을 위한 foreground import가 사용됩니다:

고객을 위한 Foreground import (인프라 트래커의 가져오기 템플릿 사용)