InfoGrab DocsInfoGrab Docs

Geo 자주 묻는 질문

요약

요구 사항은 인덱스 페이지에 정리되어 있습니다. 각 보조 사이트에는 GitLab 데이터베이스의 읽기 전용 복제본이 있습니다. 처음에는 이 추적 데이터베이스가 비어 있으므로, Geo는 GitLab 데이터베이스에서 확인할 수 있는 모든 프로젝트를 대상으로 업데이트를 시도합니다.

Geo 실행 최소 요구 사항#

요구 사항은 인덱스 페이지에 정리되어 있습니다.

Geo가 동기화 대상 프로젝트를 파악하는 방식#

각 보조 사이트에는 GitLab 데이터베이스의 읽기 전용 복제본이 있습니다. 보조 사이트에는 동기화가 끝난 프로젝트를 저장하는 추적 데이터베이스도 있습니다. Geo는 두 데이터베이스를 비교하여 아직 추적되지 않은 프로젝트를 찾습니다.

처음에는 이 추적 데이터베이스가 비어 있으므로, Geo는 GitLab 데이터베이스에서 확인할 수 있는 모든 프로젝트를 대상으로 업데이트를 시도합니다.

동기화할 각 프로젝트에 대해 다음 과정을 수행합니다.

  1. Geo는 기본 사이트에서 최신 정보를 가져오기 위해 git fetch geo --mirror를 실행합니다. 변경 사항이 없으면 동기화가 빠르게 끝나고, 변경 사항이 있으면 최신 커밋을 가져와야 합니다.
  2. 보조 사이트는 추적 데이터베이스를 업데이트하여 프로젝트를 이름 단위로 동기화했다는 사실을 저장합니다.
  3. 모든 프로젝트가 동기화될 때까지 이 과정을 반복합니다.

기본 사이트에 커밋을 푸시하면 리포지터리가 변경되었다는 이벤트가 GitLab 데이터베이스에 생성됩니다. 보조 사이트는 이 이벤트를 확인하여 해당 프로젝트를 더티로 표시하고 재동기화를 예약합니다.

파이프라인 문제(예: 동기화 실패 횟수 초과 또는 job 유실) 때문에 프로젝트 동기화가 영구적으로 중단되지 않도록, Geo는 더티로 표시된 프로젝트가 있는지 추적 데이터베이스를 주기적으로 확인합니다. 이 확인은 동시 동기화 수가 repos_max_capacity 아래로 내려가고 동기화를 기다리는 새 프로젝트가 없을 때 수행됩니다.

Geo에는 SHA 값을 가리키는 모든 Git 참조에 대해 SHA256 합계를 계산하는 체크섬 기능도 있습니다. 기본 사이트와 보조 사이트 사이에서 refs가 일치하지 않으면 보조 사이트는 해당 프로젝트를 더티로 표시하고 재동기화를 시도합니다. 따라서 추적 데이터베이스가 오래된 상태라도 검증이 동작하여 리포지터리 상태의 불일치를 찾아내고 다시 동기화합니다.

재해 복구 상황에서의 Geo 사용#

재해 복구 상황에서도 Geo를 사용할 수 있지만, 복제 대상에는 제한이 있습니다 (보조 사이트에 복제되는 데이터를 참고합니다).

재해 복구 문서를 참고합니다.

보조 사이트에 복제되는 데이터#

GitLab은 Rails 데이터베이스 전체, 프로젝트 리포지터리, LFS 객체, 생성된 첨부 파일, 아바타 등을 복제합니다. 따라서 사용자 계정, 이슈, 머지 리퀘스트, 그룹, 프로젝트 데이터 같은 정보를 보조 사이트에서 조회할 수 있습니다.

Geo가 복제하는 데이터의 전체 목록은 지원되는 Geo 데이터 유형 페이지를 참고합니다.

보조 사이트로의 git push 지원 여부#

보조 사이트로 직접 푸시하는 방식은 HTTP와 SSH 모두 지원되며, Git LFS도 포함됩니다.

커밋이 보조 사이트에 복제되는 데 걸리는 시간#

모든 복제 작업은 비동기로 수행되며 디스패치 대기열에 들어갑니다. 따라서 트래픽 양, 커밋 크기, 사이트 간 연결 상태, 하드웨어 등 여러 요인에 따라 달라집니다.

SSH 서버가 다른 포트에서 실행되는 경우#

다른 포트를 사용해도 문제가 없습니다. GitLab은 기본 사이트에서 모든 보조 사이트로 리포지터리 변경 사항을 가져올 때 HTTP(S)를 사용합니다.

보조 사이트 컨테이너 레지스트리의 기본 사이트 미러링#

미러링할 수 있지만 재해 복구 시나리오에서만 지원됩니다. 보조 사이트의 컨테이너 레지스트리를 참고합니다.

보조 사이트 로그인 가능 여부#

보조 사이트에도 로그인할 수 있지만, 보조 사이트는 사용자 계정과 로그인 같은 모든 인증 데이터를 기본 인스턴스에서 받습니다. 따라서 인증을 위해 기본 사이트로 리디렉션되었다가 다시 돌아옵니다.

모든 Geo 사이트와 기본 사이트의 동일성 요구 여부#

Geo 사이트는 서로 다른 참조 아키텍처를 기반으로 구성할 수 있습니다. 예를 들어 기본 사이트는 3K 참조 아키텍처로, 한 보조 사이트는 3K 참조 아키텍처로, 다른 보조 사이트는 1K 참조 아키텍처로 구성할 수 있습니다.

Geo의 보관된 프로젝트 복제 여부#

선택적 동기화로 제외되지 않은 보관된 프로젝트는 복제됩니다.

Geo의 개인 프로젝트 복제 여부#

선택적 동기화로 제외되지 않은 개인 프로젝트는 복제됩니다.

지연 삭제 프로젝트의 보조 사이트 복제 여부#

지연 삭제로 삭제가 예약되었으나 아직 영구 삭제되지 않은 프로젝트는 보조 사이트에 복제됩니다.

기본 사이트 중단 시 보조 사이트의 동작#

기본 사이트가 중단되면 보조 사이트는 UI로 접근할 수 없습니다. 이 상태는 기본 사이트의 서비스를 복구하거나 보조 사이트에서 승격을 수행할 때까지 이어집니다.

Geo 자주 묻는 질문

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

요약

요구 사항은 인덱스 페이지에 정리되어 있습니다. 각 보조 사이트에는 GitLab 데이터베이스의 읽기 전용 복제본이 있습니다. 처음에는 이 추적 데이터베이스가 비어 있으므로, Geo는 GitLab 데이터베이스에서 확인할 수 있는 모든 프로젝트를 대상으로 업데이트를 시도합니다.

Geo 실행 최소 요구 사항#

요구 사항은 인덱스 페이지에 정리되어 있습니다.

Geo가 동기화 대상 프로젝트를 파악하는 방식#

각 보조 사이트에는 GitLab 데이터베이스의 읽기 전용 복제본이 있습니다. 보조 사이트에는 동기화가 끝난 프로젝트를 저장하는 추적 데이터베이스도 있습니다. Geo는 두 데이터베이스를 비교하여 아직 추적되지 않은 프로젝트를 찾습니다.

처음에는 이 추적 데이터베이스가 비어 있으므로, Geo는 GitLab 데이터베이스에서 확인할 수 있는 모든 프로젝트를 대상으로 업데이트를 시도합니다.

동기화할 각 프로젝트에 대해 다음 과정을 수행합니다.

  1. Geo는 기본 사이트에서 최신 정보를 가져오기 위해 git fetch geo --mirror를 실행합니다. 변경 사항이 없으면 동기화가 빠르게 끝나고, 변경 사항이 있으면 최신 커밋을 가져와야 합니다.
  2. 보조 사이트는 추적 데이터베이스를 업데이트하여 프로젝트를 이름 단위로 동기화했다는 사실을 저장합니다.
  3. 모든 프로젝트가 동기화될 때까지 이 과정을 반복합니다.

기본 사이트에 커밋을 푸시하면 리포지터리가 변경되었다는 이벤트가 GitLab 데이터베이스에 생성됩니다. 보조 사이트는 이 이벤트를 확인하여 해당 프로젝트를 더티로 표시하고 재동기화를 예약합니다.

파이프라인 문제(예: 동기화 실패 횟수 초과 또는 job 유실) 때문에 프로젝트 동기화가 영구적으로 중단되지 않도록, Geo는 더티로 표시된 프로젝트가 있는지 추적 데이터베이스를 주기적으로 확인합니다. 이 확인은 동시 동기화 수가 repos_max_capacity 아래로 내려가고 동기화를 기다리는 새 프로젝트가 없을 때 수행됩니다.

Geo에는 SHA 값을 가리키는 모든 Git 참조에 대해 SHA256 합계를 계산하는 체크섬 기능도 있습니다. 기본 사이트와 보조 사이트 사이에서 refs가 일치하지 않으면 보조 사이트는 해당 프로젝트를 더티로 표시하고 재동기화를 시도합니다. 따라서 추적 데이터베이스가 오래된 상태라도 검증이 동작하여 리포지터리 상태의 불일치를 찾아내고 다시 동기화합니다.

재해 복구 상황에서의 Geo 사용#

재해 복구 상황에서도 Geo를 사용할 수 있지만, 복제 대상에는 제한이 있습니다 (보조 사이트에 복제되는 데이터를 참고합니다).

재해 복구 문서를 참고합니다.

보조 사이트에 복제되는 데이터#

GitLab은 Rails 데이터베이스 전체, 프로젝트 리포지터리, LFS 객체, 생성된 첨부 파일, 아바타 등을 복제합니다. 따라서 사용자 계정, 이슈, 머지 리퀘스트, 그룹, 프로젝트 데이터 같은 정보를 보조 사이트에서 조회할 수 있습니다.

Geo가 복제하는 데이터의 전체 목록은 지원되는 Geo 데이터 유형 페이지를 참고합니다.

보조 사이트로의 git push 지원 여부#

보조 사이트로 직접 푸시하는 방식은 HTTP와 SSH 모두 지원되며, Git LFS도 포함됩니다.

커밋이 보조 사이트에 복제되는 데 걸리는 시간#

모든 복제 작업은 비동기로 수행되며 디스패치 대기열에 들어갑니다. 따라서 트래픽 양, 커밋 크기, 사이트 간 연결 상태, 하드웨어 등 여러 요인에 따라 달라집니다.

SSH 서버가 다른 포트에서 실행되는 경우#

다른 포트를 사용해도 문제가 없습니다. GitLab은 기본 사이트에서 모든 보조 사이트로 리포지터리 변경 사항을 가져올 때 HTTP(S)를 사용합니다.

보조 사이트 컨테이너 레지스트리의 기본 사이트 미러링#

미러링할 수 있지만 재해 복구 시나리오에서만 지원됩니다. 보조 사이트의 컨테이너 레지스트리를 참고합니다.

보조 사이트 로그인 가능 여부#

보조 사이트에도 로그인할 수 있지만, 보조 사이트는 사용자 계정과 로그인 같은 모든 인증 데이터를 기본 인스턴스에서 받습니다. 따라서 인증을 위해 기본 사이트로 리디렉션되었다가 다시 돌아옵니다.

모든 Geo 사이트와 기본 사이트의 동일성 요구 여부#

Geo 사이트는 서로 다른 참조 아키텍처를 기반으로 구성할 수 있습니다. 예를 들어 기본 사이트는 3K 참조 아키텍처로, 한 보조 사이트는 3K 참조 아키텍처로, 다른 보조 사이트는 1K 참조 아키텍처로 구성할 수 있습니다.

Geo의 보관된 프로젝트 복제 여부#

선택적 동기화로 제외되지 않은 보관된 프로젝트는 복제됩니다.

Geo의 개인 프로젝트 복제 여부#

선택적 동기화로 제외되지 않은 개인 프로젝트는 복제됩니다.

지연 삭제 프로젝트의 보조 사이트 복제 여부#

지연 삭제로 삭제가 예약되었으나 아직 영구 삭제되지 않은 프로젝트는 보조 사이트에 복제됩니다.

기본 사이트 중단 시 보조 사이트의 동작#

기본 사이트가 중단되면 보조 사이트는 UI로 접근할 수 없습니다. 이 상태는 기본 사이트의 서비스를 복구하거나 보조 사이트에서 승격을 수행할 때까지 이어집니다.