Geo 동기화 문제 해결

Tier: 프리미엄, 얼티메이트 Offering: 셀프 매니지드

모든 업로드 다시 확인(또는 확인된 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에서 이 기능을 구현하는 데 관한 이슈가 있습니다.

메시지: Synchronization failed - Error syncing repository

caution
이 문제에 영향을 받는 대형 저장소의 경우, 재동기화에 많은 시간이 걸릴 수 있으며 Geo 사이트, 저장 공간 및 네트워크 시스템에 중요한 부하를 일으킬 수 있습니다.

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

Synchronization failed - Error syncing repository [..] fatal: fsck error in packed object

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

Error syncing repository: 13:fetch remote: "error: object <SHA>: badEmail: invalid author/committer line - bad email
   fatal: fsck error in packed object
   fatal: fetch-pack: invalid index-pack output

이 오류를 유발할 수있는 다른 문제는 object <SHA>: hasDotgit: contains '.git'입니다. 특정 오류를 확인하십시오. 왜냐하면 모든 저장소 전체에서 하나 이상의 문제가 발생할 수 있기 때문입니다.

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

Error syncing repository: 13:Received RST_STREAM with error code 2.

이러한 오류는 모든 실패한 저장소를 즉시 동기화로 확인할 수 있습니다.

일관성 오류를 유발하는 손상된 객체를 제거하려면 일반적으로 선택할 수없는 저장소 히스토리를 다시 작성해야합니다.

Gitaly 보조 Geo 사이트에서 이러한 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가 저장소를 복제하도록 보장하도록합니다.

관련 오류 does not appear to be a git repository

필요에 따라 .git/config 파일에서 기대하는 Geo 원격이 저장소의 누락을 나타내는 다음 로그 메시지와 함께 오류 메시지 Synchronization failed - Error syncing repository를 받을 수도 있습니다: 

{
  "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. 몇 가지 ID를 검사하여이 코드 명령을 사용하여 알려진 Geo 복제 실패가 있는지 확인합니다. 

    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 "발견된 실패한 프로젝트 저장소 레지스트리 항목 수: #{failed_project_registries.count}"

  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 "실패한 프로젝트 저장소 레지스트리 항목을 찾을 수 없습니다."
end

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

    failed_project_registries.each do |registry|
  registry.replicator.sync
  puts "레지스트리 ID: #{registry.id}, 프로젝트 ID: #{registry.project_id}에 대한 동기화가 시작되었습니다."

백필 중 실패 사례

백필(backfill) 중에는 실패한 작업이 백필 큐의 끝에 다시 시도 대기 상태로 스케줄되기 때문에, 이러한 실패는 백필이 완료된 후에만 정리됩니다.

메시지: unexpected disconnect while reading sideband packet

불안정한 네트워크 환경은 기타 사이트로부터 대용량 저장소 데이터를 가져오려고 할 때 Gitaly가 실패할 수 있습니다. 이러한 조건은 다음과 같은 오류로 이어질 수 있습니다: 

curl 18 전송이 취소되었습니다. 미처 읽지 않은 데이터가 남아 있음 & fetch-pack: unexpected disconnect while reading sideband packet

이러한 오류는 저장소를 사이트 간에 처음부터 복제해야 하는 경우 더 가능성이 높습니다.

Geo는 여러 번 재시도하지만, 전송이 네트워크 문제로 인해 일관되게 중단될 경우 git을 우회하고 어떠한 저장소라도 복제에 실패한 경우 rsync와 같은 대안 방법을 사용할 수 있습니다.

각 실패한 저장소를 개별적으로 전송하고 각 전송 후에 일관성을 확인하는 것을 권장합니다. 다음과 같은 단일 대상 rsync 지침을 따라, 기본 사이트에서 보조 사이트로 영향을 받는 각 저장소를 전송합니다.

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

모든 Geo-복제 가능 개체 재동기화

UI에서 전체 동기화 또는 재확인을 예약할 수 있습니다:

  1. 왼쪽 사이드바에서 가장 아래에서 관리자를 선택합니다.
  2. Geo > 사이트를 선택합니다.
  3. 복제 세부정보 아래에서 원하는 개체를 선택합니다.
  4. 모두 동기화 또는 모두 재확인을 선택합니다.

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

경고: 데이터를 변경하는 명령은 올바르게 실행되지 않거나 올바른 조건에서 실행되지 않을 경우 손상을 일으킬 수 있습니다. 명령을 항상 먼저 테스트 환경에서 실행하고 복원할 수 있는 백업 인스턴스를 준비하세요.

Geo 보조 사이트에서 저장소 확인 실패 찾기

참고: 모든 저장소 데이터 유형이 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. 복제가 자동으로 작동하지 않는 경우, 저장소를 수동으로 동기화하려고 시도하세요.

라일즈 콘솔 세션을 시작하여 다음과 같은 기본적인 문제 해결 단계를 실시하세요.

경고: 데이터를 변경하는 명령은 올바르게 실행되지 않거나 올바른 조건에서 실행되지 않을 경우 손상을 일으킬 수 있습니다. 명령을 항상 테스트 환경에 먼저 실행하고 복원할 수 있는 백업 인스턴스를 준비하세요.

저장소 확인에 실패한 저장소 수 가져오기 

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

저장소 확인에 실패한 저장소 찾기 

Geo::ProjectRegistry.where(last_repository_check_failed: true)