Geo 동기화 문제 해결

Tier: Premium, Ultimate Offering: Self-managed

모든 업로드 다시 확인하기 (또는 확인된 SSF 데이터 유형)

  1. 기본 Geo 사이트의 GitLab Rails 노드에 SSH로 접속합니다.
  2. Rails 콘솔을 엽니다.
  3. 모든 업로드를 “대기 중 확인”으로 표시합니다:
caution
데이터를 변경하는 명령은 올바른 조건에서 실행되지 않으면 손상을 초래할 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복원할 준비가 된 백업 인스턴스를 확보하십시오.

모든 업로드 다시 확인하기 

Upload.verification_state_table_class.each_batch do |relation|  
  relation.update_all(verification_state: 0)  
end

실패한 업로드만 다시 확인하기 

Upload.verification_state_table_class.where(verification_state: 3).each_batch do |relation|  
  relation.update_all(verification_state: 0)  
end

재확인 프로세스의 작동 방식

모든 업로드 다시 확인하기 또는 실패한 업로드만 다시 확인하기를 수행할 때:

  1. 기본이 업로드를 체크섬할 수 있도록 하는 명령을 실행하게 됩니다.
  2. 기본이 레코드의 체크섬을 성공적으로 생성하면 모든 보조도 체크섬을 다시 계산하고 값을 비교합니다.

Geo Self-Service Framework에서 확인이 구현된 다른 모델로 유사한 작업을 수행할 수 있습니다:

  • LfsObject
  • MergeRequestDiff
  • Packages::PackageFile
  • Terraform::StateVersion
  • SnippetRepository
  • Ci::PipelineArtifact
  • PagesDeployment
  • Upload
  • Ci::JobArtifact
  • Ci::SecureFile
note
GroupWikiRepository는 확인이 구현되지 않았으므로 이전 목록에 포함되지 않습니다. 관리자 영역 UI에서 이 기능을 구현하기 위한 문제가 있습니다.

메시지: 동기화 실패 - 저장소 동기화 오류

caution
대형 저장소가 이 문제의 영향을 받으면, 재동기화가 오랜 시간이 걸리고 귀하의 Geo 사이트, 저장소 및 네트워크 시스템에 상당한 부하를 유발할 수 있습니다.

다음 오류 메시지는 저장소 동기화 시 일관성 검사 오류를 나타냅니다:

동기화 실패 - 저장소 동기화 오류 [..] fatal: fsck error in packed object

여러 가지 문제로 이 오류가 발생할 수 있습니다. 예를 들어, 이메일 주소에 관련된 문제:

저장소 동기화 오류: 13:fetch remote: "error: object <SHA>: badEmail: 유효하지 않은 작성자/커밋터 줄 - 잘못된 이메일  
   fatal: fsck error in packed object  
   fatal: fetch-pack: invalid index-pack output

이 오류를 유발할 수 있는 또 다른 문제는 object <SHA>: hasDotgit: '.git'이 포함되어 있습니다입니다. 모든 저장소에 걸쳐 여러 문제가 있을 수 있으므로 특정 오류를 확인하십시오.

두 번째 동기화 오류는 저장소 검사 문제로 인해 발생할 수도 있습니다:

저장소 동기화 오류: 13:Received RST_STREAM with error code 2.

이러한 오류는 즉시 모든 실패한 저장소 동기화를 수행하여 관찰할 수 있습니다.

일관성 오류를 유발하는 잘못된 객체를 제거하려면 일반적으로 저장소 기록을 다시 작성해야 하며, 이는 일반적으로 옵션이 아닙니다.

이 일관성 검사를 무시하려면 보조 Geo 사이트에서 Gitaly 구성을 다시 설정하여 이러한 git fsck 문제를 무시하도록 설정합니다. 다음은 구성 예시입니다:

Gitaly 문서에는 다른 Git 검사 실패 및 GitLab의 이전 버전에 대한 자세한 내용이 있습니다.

gitaly['configuration'] = {  
  git: {  
    config: [  
      { key: "fsck.duplicateEntries", value: "ignore" },  
      { key: "fsck.badFilemode", value: "ignore" },  
      { key: "fsck.missingEmail", value: "ignore" },  
      { key: "fsck.badEmail", value: "ignore" },  
      { key: "fsck.hasDotgit", value: "ignore" },  
      { key: "fetch.fsck.duplicateEntries", value: "ignore" },  
      { key: "fetch.fsck.badFilemode", value: "ignore" },  
      { key: "fetch.fsck.missingEmail", value: "ignore" },  
      { key: "fetch.fsck.badEmail", value: "ignore" },  
      { key: "fetch.fsck.hasDotgit", value: "ignore" },  
      { key: "receive.fsck.duplicateEntries", value: "ignore" },  
      { key: "receive.fsck.badFilemode", value: "ignore" },  
      { key: "receive.fsck.missingEmail", value: "ignore" },  
      { key: "receive.fsck.badEmail", value: "ignore" },  
      { key: "receive.fsck.hasDotgit", value: "ignore" },  
    ],  
  },  
}

GitLab 16.1 및 이후 버전에는 일부 문제를 해결할 수 있는 개선 사항이 포함됩니다.

Gitaly 문제 5625는 원본 저장소에 문제가 있는 커밋이 포함되어 있더라도 Geo가 저장소를 복제하도록 보장하는 것을 제안합니다.

관련 오류 git 저장소가 아닌 것처럼 보입니다

다음 로그 메시지와 함께 동기화 실패 - 저장소 동기화 오류라는 오류 메시지를 받을 수도 있습니다.

이 오류는 예상되는 Geo 원격이 보조 Geo 사이트의 파일 시스템에 있는 .git/config 파일에 없음을 나타냅니다:

{
  "created": "@1603481145.084348757",
  "description": "Error received from peer unix:/var/opt/gitlab/gitaly/gitaly.socket",
  …
  "grpc_message": "exit status 128",
  "grpc_status": 13
}
{  …
  "grpc.request.fullMethod": "/gitaly.RemoteService/FindRemoteRootRef",
  "grpc.request.glProjectPath": "<namespace>/<project>",
  …
  "level": "error",
  "msg": "fatal: 'geo' does not appear to be a git repository
          fatal: Could not read from remote repository. …",
}

이 문제를 해결하려면:

  1. 보조 Geo 사이트의 웹 인터페이스에 로그인합니다.

  2. .git 폴더를 백업하십시오.

  3. 선택 사항. Spot-check
    이러한 ID 중 몇 개가 실제로 알려진 Geo 복제 실패가 있는 프로젝트와 일치하는지 확인합니다.
    fatal: 'geo'를 grep 용어로 사용하고 다음 API 호출을 수행하십시오:

    curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/<first_failed_geo_sync_ID>"

  4. Rails 콘솔에 들어가서 다음을 실행합니다:

    failed_project_registries = Geo::ProjectRepositoryRegistry.failed

if failed_project_registries.any?
  puts "Found #{failed_project_registries.count} failed project repository registry entries:"

  failed_project_registries.each do |registry|
    puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Last Sync Failure: '#{registry.last_sync_failure}'"
  end
else
  puts "No failed project repository registry entries found."
end

  5. 각 프로젝트에 대해 새로운 동기화를 실행하는 다음 명령을 실행합니다:

    failed_project_registries.each do |registry|
  registry.replicator.sync
  puts "Sync initiated for registry ID: #{registry.id}, Project ID: #{registry.project_id}"
end

백필 중의 실패

백필 동안, 실패는 백필 대기열 끝에서 재시도하도록 예약됩니다. 따라서 이러한 실패는 백필이 완료된 후에 해소됩니다.

메시지: 사이드밴드 패킷을 읽는 중 예기치 않은 연결 끊김

불안정한 네트워킹 조건은 Gitaly가 기본 사이트에서 대규모 저장소 데이터를 가져오려고 할 때 실패하도록 만들 수 있습니다. 이러한 조건은 다음과 같은 오류를 초래할 수 있습니다:

curl 18 transfer closed with outstanding read data remaining & fetch-pack:
unexpected disconnect while reading sideband packet

이 오류는 저장소가 사이트 간에 처음부터 복제되어야 할 경우 발생할 가능성이 더 높습니다.

Geo는 여러 번 재시도하지만, 네트워크 문제로 전송이 지속적으로 중단되면 git을 우회하고 Geo로 복제하는 데 실패한 모든 저장소의 초기 복사본을 만들기 위해 rsync와 같은 대체 방법을 사용할 수 있습니다.

각 실패하는 저장소를 개별적으로 전송하고 각 전송 후 일관성을 검사하는 것이 좋습니다. 영향을 받는 각 저장소를 기본 사이트에서 보조 사이트로 전송하기 위해 단일 대상 rsync 지침을 따르십시오.

프로젝트 또는 프로젝트 위키 저장소

모든 Geo 복제 가능 객체의 재동기화

UI에서 모든 Geo 복제 가능 객체에 대한 전체 재동기화 또는 재검증을 예약할 수 있습니다:

  1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
  2. Geo > Sites를 선택합니다.
  3. Replication details 아래에서 원하는 객체를 선택합니다.
  4. Resync all 또는 Reverify all을 선택합니다.

또는 Rails 콘솔 세션 시작하기 보조 Geo 사이트에서 추가 정보를 수집하거나 아래의 코드 조각을 사용하여 이러한 작업을 수동으로 실행할 수 있습니다.

경고:

데이터를 변경하는 명령은 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않을 경우 손상을 초래할 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복원할 수 있는 백업 인스턴스를 준비하십시오.

리포지토리 검증 실패 찾기

검증 실패 리포지토리 수 가져오기 

Geo::ProjectRepositoryRegistry.verification_failed.count

검증 실패 리포지토리 찾기 

Geo::ProjectRepositoryRegistry.verification_failed

동기화에 실패한 리포지토리 찾기 

Geo::ProjectRepositoryRegistry.failed

모든 리포지토리를 재검증 대상으로 표시하기

다음 코드 조각은 모든 프로젝트 리포지토리를 재검증 대상으로 표시합니다. 일 분 또는 두 분 후에 시스템은 동시성 한도에 따라 Sidekiq 작업을 예약하기 시작합니다:

Geo::ProjectRepositoryRegistry.update_all(verification_state: 0)

재검증할 리포지토리가 매우 많은 경우 이 단일 업데이트 쿼리가 시간 초과될 수 있습니다. 이러한 경우, 관리 영역의 Reverify all 기능과 동일한 코드를 사용하여 행 단위로 업데이트 쿼리를 실행해야 합니다:

::Geo::RegistryBulkUpdateService.new(:reverify_all, Geo::ProjectRepositoryRegistry).execute

프로젝트 및 프로젝트 위키 리포지토리 재동기화

모든 리포지토리를 재동기화 대기열에 추가하기

다음 코드 조각은 모든 프로젝트 리포지토리를 재검증 대상으로 표시합니다. 일 분 또는 두 분 후에 시스템은 동시성 한도에 따라 Sidekiq 작업을 예약하기 시작합니다:

Geo::ProjectRepositoryRegistry.update_all(state: 0, last_synced_at: nil)

재검증할 리포지토리가 매우 많은 경우 이 단일 업데이트 쿼리가 시간 초과될 수 있습니다. 이러한 경우, 관리 영역의 Reverify all 기능과 동일한 코드를 사용하여 행 단위로 업데이트 쿼리를 실행해야 합니다:

::Geo::RegistryBulkUpdateService.new(:resync_all, Geo::ProjectRepositoryRegistry).execute

개별 리포지토리 지금 동기화하기 

project = Project.find_by_full_path('<group/project>')

project.replicator.sync

지금 모든 실패한 리포지토리 동기화하기

다음 스크립트는:

  • 모든 실패한 리포지토리를 반복합니다.
  • 프로젝트 세부사항과 마지막 실패 이유를 표시합니다.
  • 리포지토리의 재동기화를 시도합니다.
  • 실패가 발생하면 결과를 보고하고 이유를 설명합니다.
  • 완료되는 데 시간이 걸릴 수 있습니다. 각 리포지토리 검사는 결과를 보고하기 전에 완료되어야 합니다. 세션이 시간이 초과되면 screen 세션을 시작하거나 Rails runner 사용하기 및 nohup을 사용하여 프로세스가 계속 실행될 수 있도록 조치를 취하십시오.
Geo::ProjectRepositoryRegistry.failed.find_each do |registry|
   begin
     puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Last Sync Failure: '#{registry.last_sync_failure}'"
     registry.replicator.sync
     puts "Sync initiated for registry ID: #{registry.id}"
   rescue => e
     puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Failed: '#{e}'", e.backtrace.join("\n")
   end
end ; nil

Geo 보조 사이트에서 리포지토리 체크 실패 찾기

note
모든 리포지토리 데이터 유형은 GitLab 16.3에서 Geo Self-Service Framework로 마이그레이션되었습니다. Geo Self-Service Framework에서 이 기능을 다시 구현하기 위한 문제가 있습니다.

GitLab 16.2 및 이전 버전:

모든 프로젝트에 대해 활성화된 경우, 리포지토리 체크는 Geo 보조 사이트에서도 수행됩니다. 메타데이터는 Geo 추적 데이터베이스에 저장됩니다.

Geo 보조 사이트에서의 리포지토리 체크 실패는 반드시 복제 문제를 의미하지 않습니다. 이러한 실패를 해결하기 위한 일반적인 접근 방법은 다음과 같습니다.

  1. 아래에 언급된 영향을 받는 리포지토리와 그들의 기록된 오류를 찾습니다.

  2. 특정 git fsck 오류를 진단하려고 시도합니다. 가능한 오류의 범위는 넓으므로, 검색 엔진에 입력해 보세요.

  3. 영향을 받는 리포지토리의 일반적인 기능을 테스트합니다. 보조 사이트에서 풀하고, 파일을 확인합니다.

  4. 기본 사이트의 리포지토리에 동일한 git fsck 오류가 있는지 확인합니다. 장애 조치를 계획하고 있는 경우, 보조 사이트가 기본 사이트와 동일한 정보를 가지도록 우선 순위를 정하세요. 기본의 백업을 확보하고, 계획된 장애 조치 지침을 따르세요.

  5. 기본 사이트에 푸시하고, 변경 사항이 보조 사이트에 복제되는지 확인합니다.

  6. 복제가 자동으로 작동하지 않는 경우, 리포지토리를 수동으로 동기화해 보세요.

Rails 콘솔 세션 시작
다음과 같은 기본 문제 해결 단계를 시행합니다.

caution
데이터를 변경하는 명령은 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않으면 손상을 초래할 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복원할 백업 인스턴스가 준비되어 있어야 합니다.

리포지토리 체크에 실패한 리포지토리 수 가져오기 

Geo::ProjectRegistry.where(last_repository_check_failed: true).count

리포지토리 체크에 실패한 리포지토리 찾기 

Geo::ProjectRegistry.where(last_repository_check_failed: true)