자동 백그라운드 검증

Tier: Premium, Ultimate Offering: Self-managed

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

기본 사이트에서 검증에 실패하면, Geo가 훼손된 오브젝트를 복제하고 있음을 나타냅니다. 문제를 해결하려면 백업에서 복원하거나 기본 사이트에서 제거하세요.

기본 사이트에서 검증에 성공하고 보조 사이트에서 실패하면, 이것은 오브젝트가 복제 프로세스 중에 손상되었음을 나타냅니다. Geo는 실패한 검증을 정정하기 위해 리포지터리를 다시 동기화하도록 노력하며 백오프 기간을 표시합니다. 이러한 실패에 대해 검증을 재설정하려면 이 지침을 따르세요.

검증이 복제보다 크게 뒤처지면, 계획된 장애 조치를 예약하기 전에 사이트에 더 많은 시간을 부여하는 것을 고려하세요.

리포지터리 검증

기본 사이트에서:

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택하세요.
  2. Geo > 사이트를 선택하세요.

  3. 해당 사이트의 검증 정보 탭을 확장하여 리포지터리 및 위키의 자동 체크섬 상태를 확인하세요. 성공은 녹색으로, 대기 중인 작업은 회색으로, 실패는 빨강으로 표시됩니다.

    검증 상태

보조 사이트에서:

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택하세요.
  2. Geo > 사이트를 선택하세요.

  3. 해당 사이트의 검증 정보 탭을 확장하여 리포지터리 및 위키의 자동 체크섬 상태를 확인하세요. 성공은 녹색으로, 대기 중인 작업은 회색으로, 실패는 빨강으로 표시됩니다.

    검증 상태

체크섬을 사용하여 Geo 사이트 비교

Geo 보조 사이트의 건강 상태를 확인하기 위해 Git 참조 및 그 값에 대한 체크섬을 사용합니다. 체크섬에는 HEAD, heads, tags, notes, 그리고 GitLab 특정 참조가 포함되어 있어 진정한 일관성을 보장합니다. 두 사이트가 동일한 체크섬을 가지고 있다면, 그들은 확실히 동일한 참조를 보유하고 있습니다. 모든 사이트에 대해 갱신 후 매번 체크섬을 계산하여 동기화되었음을 확인합니다.

리포지터리 재검증

버그 또는 일시적인 인프라 문제로 인해 Git 리포지터리가 예기치 않게 변경되어 검증 대상으로 표시되지 않을 수 있습니다. Geo는 데이터의 무결성을 보장하기 위해 리포지터리를 지속적으로 재검증합니다. 기본 및 권장되는 재검증 간격은 7일이지만 1일과 같이 짧은 간격을 설정할 수도 있습니다. 간격을 줄이면 위험이 감소하지만 부하가 증가하고 그 반대로도 됩니다.

기본 사이트에서:

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택하세요.
  2. Geo > 사이트를 선택하세요.

  3. 최소 재검증 간격을 사용자 정의하기 위해 기본 사이트의 편집을 선택하세요:

    재검증 간격

검증이 실패한 프로젝트에 대한 검증 재설정

Geo는 검증에 실패한 프로젝트 및 체크섬 불일치가 있는 프로젝트를 백오프 기간 없이 다시 동기화하도록 노력합니다. 매뉴얼으로 재설정하려면 다음 Rake 작업을 실행하여 검증이 실패하거나 체크섬이 불일치하는 프로젝트를 표시해야 합니다:

보조 사이트의 Rails 노드에서 해당 명령을 실행하세요.

리포지터리의 경우: 

sudo gitlab-rake geo:verification:repository:reset

위키의 경우: 

sudo gitlab-rake geo:verification:wiki:reset

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

만약 기본 사이트와 보조 사이트의 체크섬 검증이 불일치한다면, 원인을 찾기 어려울 수 있습니다. 체크섬 불일치의 원인을 찾으려면 다음을 수행하세요:

  1. 기본 사이트에서:
    1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택하세요.
    2. 왼쪽 사이드바에서 개요 > 프로젝트를 선택하세요.
    3. 체크섬 차이를 확인하려는 프로젝트를 찾고 해당 이름을 선택하세요.
    4. 프로젝트 관리 페이지에서 리포지터리 이름과 상대 경로 필드의 값을 얻으세요.

  2. 기본 사이트의 Gitaly 노드와 보조 사이트의 Gitaly 노드에서 프로젝트의 리포지터리 디렉터리로 이동하세요. 만약 Gitaly 클러스터를 사용 중이라면, 이 명령을 실행하기 전에 클러스터가 정상 상태인지 확인하세요.

    기본 경로는 /var/opt/gitlab/git-data/repositories입니다. git_data_dirs가 사용자 지정되었다면 서버의 디렉터리 레이아웃을 확인하세요: 

    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 primary-site-refs secondary-site-refs

현재 제한 사항

복제 및 검증 방법이 지원되는지에 대한 자세한 정보는 지원되는 Geo 데이터 유형을 참조하세요.