InfoGrab DocsInfoGrab Docs

자동 백그라운드 검증

요약

자동 백그라운드 검증은 전송된 데이터가 계산된 체크섬과 일치하는지 확인합니다. 기본 사이트에서 검증이 실패하면 Geo가 손상된 오브젝트를 복제하고 있다는 뜻입니다. 기본 사이트에서는 검증이 성공했으나 보조 사이트에서 실패하면 복제 과정에서 오브젝트가 손상된 것입니다.

자동 백그라운드 검증은 전송된 데이터가 계산된 체크섬과 일치하는지 확인합니다. 기본 사이트 데이터의 체크섬이 보조 사이트 데이터의 체크섬과 일치하면 데이터가 정상적으로 전송된 것입니다. 계획된 장애 조치 이후에는 손상 정도에 따라 손상된 데이터가 손실될 수 있습니다.

기본 사이트에서 검증이 실패하면 Geo가 손상된 오브젝트를 복제하고 있다는 뜻입니다. 백업에서 복원하거나 기본 사이트에서 제거하여 문제를 해결할 수 있습니다.

기본 사이트에서는 검증이 성공했으나 보조 사이트에서 실패하면 복제 과정에서 오브젝트가 손상된 것입니다. Geo는 검증 실패를 바로잡기 위해 해당 리포지터리를 백오프 기간을 두고 재동기화하도록 표시합니다. 이러한 실패에 대해 검증을 재설정하려면 이 지침을 따릅니다.

검증이 복제보다 크게 뒤처져 있다면 계획된 장애 조치를 예정하기 전에 해당 사이트에 시간을 더 주는 방안을 고려합니다.

리포지터리 검증#

사전 요구 사항:

  • 관리자 액세스 권한.

기본 사이트에서 수행합니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.

  2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.

  3. 해당 사이트의 Verification information 탭을 확장하여 리포지터리와 위키의 자동 체크섬 계산 상태를 확인합니다. 성공은 녹색, 대기 중인 작업은 회색, 실패는 빨간색으로 표시됩니다.

    Verification information tab with an overview of a healthy primary Geo instance.

보조 사이트에서 수행합니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.

  2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.

  3. 해당 사이트의 Verification information 탭을 확장하여 리포지터리와 위키의 자동 체크섬 계산 상태를 확인합니다. 성공은 녹색, 대기 중인 작업은 회색, 실패는 빨간색으로 표시됩니다.

    Verification information tab with an overview of a healthy secondary Geo instance.

체크섬을 사용한 Geo 사이트 비교#

Geo 보조 사이트의 상태를 확인할 때는 Git 레퍼런스 목록과 그 값에 대한 체크섬을 사용합니다. 이 체크섬에는 HEAD, heads, tags, notes, GitLab 전용 레퍼런스가 포함되어 진정한 일관성을 보장합니다. 두 사이트의 체크섬이 같다면 두 사이트는 확실히 동일한 레퍼런스를 보유하고 있습니다. GitLab은 모든 사이트가 동기화 상태를 유지하도록 업데이트가 발생할 때마다 각 사이트의 체크섬을 계산합니다.

리포지터리 재검증#

버그나 일시적인 인프라 장애로 인해 Git 리포지터리가 검증 대상으로 표시되지 않은 채 예기치 않게 변경될 수 있습니다. Geo는 데이터 무결성을 보장하기 위해 리포지터리를 지속적으로 재검증합니다. 기본 재검증 주기는 90일이며, 최소 1일까지 짧게 설정할 수 있습니다. 주기가 짧을수록 위험은 줄어들지만 부하는 늘어나며, 그 반대도 마찬가지입니다.

기본 사이트에서 수행합니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.
  3. 최소 재검증 주기를 조정하려면 기본 사이트의 Edit을 선택합니다.

검증이 실패한 프로젝트의 검증 재설정#

Geo는 검증 실패를 바로잡기 위해 해당 리포지터리를 백오프 기간을 두고 재동기화하도록 표시합니다. UI 또는 Rails 콘솔에서 개별 구성 요소를 수동으로 재동기화하고 재검증할 수도 있습니다.

검증 재설정에 이전에 문서화되었던 Geo Rake 태스크는 GitLab 16.5 이상에서 더 이상 사용할 수 없습니다. 대신 UI 기반 일괄 작업이나 Geo 데이터 재동기화 및 재검증의 Rails 콘솔 절차를 사용합니다.

체크섬 불일치로 인한 차이 조정#

기본 사이트와 보조 사이트의 체크섬 검증 결과가 일치하지 않는 경우 그 원인이 분명하지 않을 수 있습니다. 체크섬 불일치의 원인을 찾으려면 다음을 수행합니다.

  1. 기본 사이트에서 수행합니다.

    1. 오른쪽 위 모서리에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Overview > Projects를 선택합니다.
    3. 체크섬 차이를 확인하려는 프로젝트를 찾아 이름을 선택합니다.
    4. 프로젝트 관리 페이지에서 Storage name 및 Relative path 필드의 값을 확인합니다.

  2. 기본 사이트의 Gitaly 노드와 보조 사이트의 Gitaly 노드에서 프로젝트의 리포지터리 디렉터리로 이동합니다. Gitaly Cluster (Praefect)를 사용한다면 클러스터가 정상 상태인지 확인한 뒤 다음 명령을 실행합니다.

    기본 경로는 /var/opt/gitlab/git-data/repositories 입니다. 리포지터리 스토리지를 변경한 경우에는 서버의 디렉터리 구성을 확인합니다.

    cd /var/opt/gitlab/git-data/repositories

    1. 기본 사이트에서 다음 명령을 실행하고 출력을 파일로 리디렉션합니다.

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-site-refs

    2. 보조 사이트에서 다음 명령을 실행하고 출력을 파일로 리디렉션합니다.

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-site-refs

    3. 앞 단계에서 만든 파일을 같은 시스템으로 복사한 뒤 내용을 diff로 비교합니다.

      diff primary-site-refs secondary-site-refs

현재 제한 사항#

지원되는 복제 및 검증 방식에 대한 자세한 내용은 지원되는 Geo 데이터 유형을 참고합니다.

자동 백그라운드 검증

GitLab v19.5
Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

자동 백그라운드 검증은 전송된 데이터가 계산된 체크섬과 일치하는지 확인합니다. 기본 사이트에서 검증이 실패하면 Geo가 손상된 오브젝트를 복제하고 있다는 뜻입니다. 기본 사이트에서는 검증이 성공했으나 보조 사이트에서 실패하면 복제 과정에서 오브젝트가 손상된 것입니다.

자동 백그라운드 검증은 전송된 데이터가 계산된 체크섬과 일치하는지 확인합니다. 기본 사이트 데이터의 체크섬이 보조 사이트 데이터의 체크섬과 일치하면 데이터가 정상적으로 전송된 것입니다. 계획된 장애 조치 이후에는 손상 정도에 따라 손상된 데이터가 손실될 수 있습니다.

기본 사이트에서 검증이 실패하면 Geo가 손상된 오브젝트를 복제하고 있다는 뜻입니다. 백업에서 복원하거나 기본 사이트에서 제거하여 문제를 해결할 수 있습니다.

기본 사이트에서는 검증이 성공했으나 보조 사이트에서 실패하면 복제 과정에서 오브젝트가 손상된 것입니다. Geo는 검증 실패를 바로잡기 위해 해당 리포지터리를 백오프 기간을 두고 재동기화하도록 표시합니다. 이러한 실패에 대해 검증을 재설정하려면 이 지침을 따릅니다.

검증이 복제보다 크게 뒤처져 있다면 계획된 장애 조치를 예정하기 전에 해당 사이트에 시간을 더 주는 방안을 고려합니다.

리포지터리 검증#

사전 요구 사항:

  • 관리자 액세스 권한.

기본 사이트에서 수행합니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.

  2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.

  3. 해당 사이트의 Verification information 탭을 확장하여 리포지터리와 위키의 자동 체크섬 계산 상태를 확인합니다. 성공은 녹색, 대기 중인 작업은 회색, 실패는 빨간색으로 표시됩니다.

    Verification information tab with an overview of a healthy primary Geo instance.

보조 사이트에서 수행합니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.

  2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.

  3. 해당 사이트의 Verification information 탭을 확장하여 리포지터리와 위키의 자동 체크섬 계산 상태를 확인합니다. 성공은 녹색, 대기 중인 작업은 회색, 실패는 빨간색으로 표시됩니다.

    Verification information tab with an overview of a healthy secondary Geo instance.

체크섬을 사용한 Geo 사이트 비교#

Geo 보조 사이트의 상태를 확인할 때는 Git 레퍼런스 목록과 그 값에 대한 체크섬을 사용합니다. 이 체크섬에는 HEAD, heads, tags, notes, GitLab 전용 레퍼런스가 포함되어 진정한 일관성을 보장합니다. 두 사이트의 체크섬이 같다면 두 사이트는 확실히 동일한 레퍼런스를 보유하고 있습니다. GitLab은 모든 사이트가 동기화 상태를 유지하도록 업데이트가 발생할 때마다 각 사이트의 체크섬을 계산합니다.

리포지터리 재검증#

버그나 일시적인 인프라 장애로 인해 Git 리포지터리가 검증 대상으로 표시되지 않은 채 예기치 않게 변경될 수 있습니다. Geo는 데이터 무결성을 보장하기 위해 리포지터리를 지속적으로 재검증합니다. 기본 재검증 주기는 90일이며, 최소 1일까지 짧게 설정할 수 있습니다. 주기가 짧을수록 위험은 줄어들지만 부하는 늘어나며, 그 반대도 마찬가지입니다.

기본 사이트에서 수행합니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.
  3. 최소 재검증 주기를 조정하려면 기본 사이트의 Edit을 선택합니다.

검증이 실패한 프로젝트의 검증 재설정#

Geo는 검증 실패를 바로잡기 위해 해당 리포지터리를 백오프 기간을 두고 재동기화하도록 표시합니다. UI 또는 Rails 콘솔에서 개별 구성 요소를 수동으로 재동기화하고 재검증할 수도 있습니다.

검증 재설정에 이전에 문서화되었던 Geo Rake 태스크는 GitLab 16.5 이상에서 더 이상 사용할 수 없습니다. 대신 UI 기반 일괄 작업이나 Geo 데이터 재동기화 및 재검증의 Rails 콘솔 절차를 사용합니다.

체크섬 불일치로 인한 차이 조정#

기본 사이트와 보조 사이트의 체크섬 검증 결과가 일치하지 않는 경우 그 원인이 분명하지 않을 수 있습니다. 체크섬 불일치의 원인을 찾으려면 다음을 수행합니다.

  1. 기본 사이트에서 수행합니다.

    1. 오른쪽 위 모서리에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Overview > Projects를 선택합니다.
    3. 체크섬 차이를 확인하려는 프로젝트를 찾아 이름을 선택합니다.
    4. 프로젝트 관리 페이지에서 Storage name 및 Relative path 필드의 값을 확인합니다.

  2. 기본 사이트의 Gitaly 노드와 보조 사이트의 Gitaly 노드에서 프로젝트의 리포지터리 디렉터리로 이동합니다. Gitaly Cluster (Praefect)를 사용한다면 클러스터가 정상 상태인지 확인한 뒤 다음 명령을 실행합니다.

    기본 경로는 /var/opt/gitlab/git-data/repositories 입니다. 리포지터리 스토리지를 변경한 경우에는 서버의 디렉터리 구성을 확인합니다.

    cd /var/opt/gitlab/git-data/repositories

    1. 기본 사이트에서 다음 명령을 실행하고 출력을 파일로 리디렉션합니다.

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-site-refs

    2. 보조 사이트에서 다음 명령을 실행하고 출력을 파일로 리디렉션합니다.

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-site-refs

    3. 앞 단계에서 만든 파일을 같은 시스템으로 복사한 뒤 내용을 diff로 비교합니다.

      diff primary-site-refs secondary-site-refs

현재 제한 사항#

지원되는 복제 및 검증 방식에 대한 자세한 내용은 지원되는 Geo 데이터 유형을 참고합니다.