Gitaly 및 Gitaly 클러스터

Tier: Free, Premium, Ultimate Offering: Self-Managed

Gitaly은 Git 저장소에 대한 고수준의 RPC(Remote Procedure Call) 액세스를 제공합니다. GitLab에서는 Gitaly를 사용하여 Git 데이터를 읽고 쓰기 위해 사용합니다.

Gitaly는 모든 GitLab 설치에 존재하며 Git 저장소의 저장 및 검색을 조정합니다. Gitaly에는 다음과 같은 형태로 사용할 수 있습니다:

  • 단일 인스턴스 Linux 패키지 설치에서 작동하는 백그라운드 서비스(모든 GitLab을 한 대의 기계에 설치함).
  • 스케일링 및 가용성 요구에 따라 완전한 클러스터 구성으로 자체 인스턴스로 분리되어 구성됨.

Gitaly는 클라이언트-서버 아키텍처를 구현합니다:

Gitaly는 GitLab의 Git 저장소 액세스만 관리합니다. 다른 유형의 GitLab 데이터는 Gitaly를 통해 액세스되지 않습니다.

GitLab은 구성된 저장소 저장소(storage)를 통해 저장소(repository)에 액세스합니다. 각 새 저장소는 구성된 가중치에 따라 저장소 저장소 중 하나에 저장됩니다. 각 저장소 저장소는 다음 중 하나입니다:

Gitaly 클러스터를 배포하기 전에

Gitaly 클러스터는 내결함성의 이점을 제공하지만 추가적인 설정 및 관리 복잡성을 동반합니다. Gitaly 클러스터를 배포하기 전에 다음을 검토하세요:

아직 Gitaly 클러스터로 마이그레이션하지 않았다면 두 가지 옵션이 있습니다:

  • 분할된 Gitaly 인스턴스.
  • Gitaly 클러스터.

질문이 있으면 고객 성공 관리자 또는 고객 지원팀에 연락하세요.

알려진 문제

다음 표는 Gitaly 클러스터 사용에 영향을 주는 현재 알려진 문제를 설명합니다. 이러한 문제의 현재 상태에 대한 자세한 내용은 지정된 문제 및 이슈를 참조하세요.

문제 요약 피하는 방법
Gitaly Cluster + Geo - 실패한 동기화 재시도 문제 Gitaly 클러스터가 Geo 보조 사이트에서 사용되는 경우 동기화에 실패한 저장소는 Geo가 다시 동기화를 시도할 때 계속 실패할 수 있습니다. 이 상태에서 복구하려면 지원팀의 도움을 받아 수동 단계를 실행해야 합니다. GitLab 15.0에서 15.2에서 기능 플래그 gitaly_praefect_generated_replica_paths를 활성화하세요. GitLab 15.3에서는 기능 플래그가 기본적으로 활성화됩니다.
Praefect이 업그레이드 후에 마이그레이션이 완료되지 않았으므로 데이터를 데이터베이스에 삽입하지 못하는 문제 데이터베이스가 완료된 마이그레이션으로 최신 상태를 유지하지 않은 경우 Praefect 노드는 표준 작업을 실행할 수 없습니다. Praefect 데이터베이스가 모든 마이그레이션을 완료한 상태로 작동하도록 확인하세요(예: sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate-status 명령을 실행하여 적용된 모든 마이그레이션을 나열해야 합니다). 지원팀에 업그레이드 지원을 요청하여 지원팀이 업그레이드 계획을 검토하도록 합니다.
실행 중인 클러스터에서 스냅샷에서 Gitaly 클러스터 노드 복원하는 제한사항 Gitaly 클러스터가 일관된 상태로 실행되는데 단일 노드가 이전 상태로 뒤처진 경우, 클러스터는 노드 데이터와 다른 노드 데이터를 조화시키지 못할 수 있습니다 단일 Gitaly 클러스터 노드를 백업 스냅샷에서 복원하지 마세요.

1. GitLab을 종료하세요.
2. Gitaly 클러스터의 모든 노드를 동시에 스냅샷하세요.
3. Praefect 데이터베이스를 백업하세요.
Kubernetes, Amazon ECS 또는 유사한 환경에서 실행하는 한계 Praefect (Gitaly 클러스터)은 지원되지 않으며 Gitaly에는 알려진 제한 사항이 있습니다. 자세한 내용은 epic 6127을 참조하세요. 저희 참조 아키텍처를 사용하세요.

스냅샷 백업 및 복구 제한

Gitaly 클러스터는 스냅샷 백업을 지원하지 않습니다. 스냅샷 백업은 Praefect 데이터베이스가 디스크 저장소와 동기화되지 않는 문제를 유발할 수 있습니다. Praefect가 복원 중에 Gitaly 디스크 정보의 복제 메타데이터를 다시 구축하는 방식으로 인해 공식 백업 및 복구 Rake 태스크를 사용해야 합니다.

증분 백업 방법을 사용하여 Gitaly 클러스터 백업을 가속화할 수 있습니다.

두 가지 방법 모두 사용할 수 없다면 복구 지원을 위해 고객 지원팀에 문의하세요.

Gitaly 클러스터에서 문제 또는 제한 사항이 발생하는 경우

즉시 복구나 복원을 위해 고객 지원팀에 문의하십시오.

디스크 요구 사항

Gitaly 및 Gitaly 클러스터는 I/O 중심 프로세스이기 때문에 효율적으로 작동하기 위해 빠른 로컬 스토리지가 필요합니다. 따라서 모든 Gitaly 노드가 고체 상태 드라이브(SSD)를 사용하는 것을 강력히 권장합니다.

이러한 SSD는 다음과 같은 처리량을 가져야 합니다.

  • 읽기 작업에 대해 초당 8,000개의 입출력 작업(IOPS)
  • 쓰기 작업에 대해 2,000개의 IOPS

이러한 IOPS 값은 초기 권장 사항이며 환경의 작업량 규모에 따라 더 크거나 작은 값으로 조정될 수 있습니다. 환경을 클라우드 제공업체에서 실행 중인 경우, 적절하게 IOPS를 구성하는 방법에 대해서는 해당 업체의 문서를 참조하십시오.

리포지토리 데이터의 경우 Gitaly 및 Gitaly 클러스터에서는 성능과 일관성을 위해 로컬 스토리지만 지원됩니다. NFS나 클라우드 기반 파일 시스템과 같은 대체 제품은 지원되지 않습니다.

리포지토리의 직접 액세스

GitLab은 Gitaly 리포지토리에 직접적인 Git 클라이언트나 다른 도구로의 액세스를 권장하지 않습니다. 왜냐하면 Gitaly은 지속적으로 개선 및 변경되고 있기 때문입니다. 이러한 개선 사항은 여러분의 전제를 무효화할 수 있어 성능 저하, 불안정성, 심지어 데이터 손실을 유발할 수 있습니다. 예를 들면: - Gitaly에는 info/refs 광고 캐시와 같은 최적화가 있으며, 이는 공식 gRPC 인터페이스를 사용하여 리포지토리에 대한 액세스를 제어하고 모니터링합니다. - Gitaly 클러스터에는 장애 허용 및 분산 리드와 같은 최적화가 있으며, 이는 gRPC 인터페이스와 데이터베이스에 의존하여 리포지토리 상태를 결정합니다.

경고: Git 리포지토리에 직접 액세스하는 것은 자체 책임 하에 이루어지며 지원되지 않습니다.

Gitaly

다음은 직접 Gitaly에 액세스하도록 설정된 GitLab의 구성을 보여줍니다:

GitLab 애플리케이션이 Gitaly 저장소 샤드와 상호 작용하는 예시

이 예시에서:

  • 각 리포지토리는 storage-1, storage-2, 또는 storage-3 중 하나의 세 개의 Gitaly 저장소에 저장됩니다.
  • 각 저장소는 Gitaly 노드에서 서비스를 받습니다.
  • 세 개의 Gitaly 노드는 각자의 파일 시스템에 데이터를 저장합니다.

Gitaly 아키텍처

다음은 Gitaly 클라이언트-서버 아키텍처를 설명한 것입니다:

flowchart LR subgraph Gitaly clients Rails[GitLab Rails] Workhorse[GitLab Workhorse] Shell[GitLab Shell] Zoekt[Zoekt Indexer] Elasticsearch[Elasticsearch Indexer] KAS["GitLab Agent for Kubernetes (KAS)"] end subgraph Gitaly GitalyServer[Gitaly server] end FS[Local filesystem] ObjectStorage[Object storage] Rails -- gRPC --> Gitaly Workhorse -- gRPC --> Gitaly Shell -- gRPC --> Gitaly Zoekt -- gRPC --> Gitaly Elasticsearch -- gRPC --> Gitaly KAS -- gRPC --> Gitaly GitalyServer --> FS GitalyServer -- TCP --> Workhorse GitalyServer -- TCP --> ObjectStorage

Gitaly 구성

Gitaly는 리눅스 패키지 설치와 함께 미리 구성되어 제공되며, 이는 최대 20 RPS / 1,000 users에 적합한 구성입니다. - 최대 40 RPS / 2,000 사용자를 대상으로 하는 리눅스 패키지 설치의 경우, 특정 Gitaly 구성 지침을 참조하십시오. - 직접 컴파일한 설치 또는 사용자 정의 Gitaly 설치의 경우, Gitaly 구성을 참조하십시오.

일일 Git 작성 작업을 수행하는 2000명 이상의 활성 사용자를 위한 GitLab 설치는 Gitaly 클러스터를 사용하는 것이 가장 적합할 수 있습니다.

Gitaly CLI

gitaly 명령어는 Gitaly 관리자를 위한 추가 하위 명령어를 제공하는 명령줄 인터페이스입니다. 예를 들면, Gitaly CLI는 다음과 같은 작업을 수행하는데 사용됩니다: - 리포지토리에 사용자 지정 Git 후크 구성. - Gitaly 구성 파일 유효성 검사. - 내부 Gitaly API의 접근 여부 확인. - 디스크에 저장된 리포지토리에 대한 Git 명령 실행.

다른 하위 명령어에 대한 자세한 정보는 sudo -u git -- /opt/gitlab/embedded/bin/gitaly --help를 실행하십시오.

리포지토리 백업

GitLab 외의 도구를 사용하여 리포지토리를 백업하거나 동기화해야 하는 경우, 리포지토리 데이터를 복사하는 동안 쓰기 작업을 방지해야 합니다.

번들 URI

Gitaly에서 Git 번들 URI를 사용할 수 있습니다. 자세한 내용은 번들 URI 문서를 참조하십시오.

Gitaly 클러스터

Git 저장소는 GitLab의 Gitaly 서비스를 통해 제공되며, GitLab의 작동에 필수적입니다. 사용자 수, 리포지토리 수, 그리고 활동이 증가할수록 Gitaly를 적절하게 확장하는 것이 중요합니다. 이것은 다음과 같은 방법으로 이루어집니다: - 리소스 고갈로 인해 Git, Gitaly 및 GitLab 애플리케이션 성능이 저하되기 전에 Git에 대해 사용 가능한 CPU 및 메모리 리소스를 증가시킵니다. - 저장 공간 한도에 도달하여 쓰기 작업이 실패하는 것을 방지하기 위해 사용 가능한 저장 공간을 늘립니다. - 고장 허용성을 향상시키기 위해 단일 장애 점을 제거합니다. 서비스 저하가 프로덕션 환경에 변경 배포를 방지할 수 있는 경우, Git은 미션 크리티컬로 간주되어야 합니다.

Gitaly는 클러스터 구성에서: - Gitaly 서비스 확장 - 고장 허용성 증가

각 Git 리포지토리가 클러스터의 여러 Gitaly 노드에 저장될 수 있도록 합니다.

Gitaly 클러스터를 사용하면 다음과 같은 방법으로 고장 허용성이 향상됩니다: - 쓰기 작업을 웜 스탠바이 Gitaly 노드에 복제합니다. - Gitaly 노드 장애를 감지합니다. - 사용 가능한 Gitaly 노드로 Git 요청을 자동으로 라우팅합니다.

주의: Gitaly 클러스터에 대한 기술 지원은 GitLab Premium 및 Ultimate 고객에게만 제공됩니다.

다음은 Gitaly 클러스터로 설정된 GitLab을 보여줍니다. storage-1에 액세스하는 Gitaly가 제공하는 가상 저장소의 상호 작용입니다:

Gitaly 물리적 저장소와 상호 작용하는 가상 Gitaly 저장소와 상호 작용하는 GitLab 애플리케이션

이 예시에서: - 리포지토리는 storage-1이라는 가상 저장소에 저장됩니다. - 세 개의 Gitaly 노드(gitaly-1, gitaly-2, gitaly-3)가 storage-1 액세스를 제공합니다. - 세 개의 Gitaly 노드는 서로 다른 해시화된 저장 위치에서 데이터를 공유합니다. - 복제 요소는 3입니다. 각 리포지토리의 세 개의 사본이 유지됩니다.

단일 노드 장애 상황을 가정한 Gitaly 클러스터의 가용성 목표는 다음과 같습니다: - 복구 지점 목표 (RPO): 1분 미만 작성은 비동기적으로 복제됩니다. 새로 승격된 기본 데이터에 아직 복제되지 않은 경우 해당 작성은 손실됩니다. 강력한 일관성은 특정 상황에서 손실을 방지합니다. - 복구 시간 목표 (RTO): 10초 미만 각 Praefect 노드에서 1초마다 실행되는 헬스 체크에 의해 중단이 감지됩니다. 장애 복구에는 각 Praefect 노드에 대해 연속하여 열 개의 실패한 헬스 체크가 필요합니다.

RPO 및 RTO의 개선 사항은 에픽 8903에서 제안되었습니다.

경고: 클러스터의 완전한 장애가 발생하는 경우, 재해 복구 계획을 실행해야 합니다. 이로 인해 위에서 논의된 RPO 및 RTO에 영향을 줄 수 있습니다.

Geo와 비교

Gitaly Cluster 및 Geo는 모두 중복성을 제공합니다. 그러나 중복성은 다음과 같습니다.

  • Gitaly Cluster는 데이터 저장에 대한 내결함성을 제공하며 사용자에게는 보이지 않습니다. 사용자는 Gitaly Cluster를 사용할 때 인식하지 못합니다.
  • Geo는 전체 GitLab 인스턴스에 대한 복제 및 재해 복구를 제공합니다. 사용자는 복제를 사용할 때 인식합니다. Geo는 Git 데이터를 포함하여 여러 데이터 유형을 복제합니다.

다음 표는 Gitaly Cluster와 Geo 간의 주요 차이점을 보여줍니다:

도구 노드 위치 지연 허용 장애 조치 일관성 중복성 제공
Gitaly Cluster 다수 단일 1초 미만, 이상적으로는 단일 자릿수 밀리초 자동 강력한 Git 데이터의 데이터 저장
Geo 다수 다중 최대 1분 수동 최종적 전체 GitLab 인스턴스

자세한 내용은 다음을 참조하세요:

가상 저장소

가상 저장소를 사용하면 GitLab의 단일 저장소 저장을 통합하여 저장소 관리를 단순화할 수 있습니다.

Gitaly Cluster의 가상 저장소는 일반적으로 직접 Gitaly 저장소 구성을 대체할 수 있습니다. 그러나 각 저장소를 여러 Gitaly 노드에 저장하는 추가 저장 공간 비용이 발생합니다. 직접 Gitaly 저장소 대신 Gitaly Cluster 가상 저장소를 사용하는 이점은 다음과 같습니다:

  • 각 Gitaly 노드에 모든 저장소의 사본이 있기 때문에 개선된 내결함성.
  • 읽기 부하가 Gitaly 노드에 고르게 분산되기 때문에 자원 활용이 개선되어 shard별 최대 부하에 대한 과다한 공급이 감소함.
  • 읽기 부하가 Gitaly 노드에 고르게 분산되기 때문에 성능을 위한 수동 리밸런싱이 필요하지 않음.
  • 모든 Gitaly 노드가 동일하므로 관리가 더 간단함.

저장소 사본의 수는 복제 팩터를 사용하여 구성할 수 있습니다.

모든 저장소에 동일한 복제 팩터를 사용하는 것은 경제적으로 비효율적일 수 있습니다. 매우 큰 GitLab 인스턴스에 대해 더 큰 유연성을 제공하기 위해 가변 복제 팩터가 추적됩니다. 이 이슈에서 자세한 내용을 확인할 수 있습니다.

표준 Gitaly 저장소와 마찬가지로 가상 저장소도 샤딩될 수 있습니다.

저장소 레이아웃

경고: 저장소 레이아웃은 Gitaly Cluster의 내부 세부 정보이며 릴리스 간에 안정적이라는 것을 보장하지 않습니다. 여기에 있는 정보는 정보를 제공하고 디버깅을 위한 것입니다. 디스크 위에서 리포지토리에 직접 변경 사항을 적용하는 것은 지원되지 않으며, 깨짐 또는 변경 사항이 덮어씌워질 수 있습니다.

Gitaly Cluster의 가상 저장소는 단일 저장소처럼 보이는 추상화를 제공하지만 실제로 여러 물리적 저장소로 구성됩니다. Gitaly Cluster는 모든 물리적 저장소로 각 작업을 복제해야 합니다. 작업은 몇 개의 물리적 저장소에서 성공할 수 있지만, 다른 곳에서 실패할 수 있습니다.

부분 적용된 작업으로 인해 다른 작업들에 문제가 발생하고 시스템이 회복할 수 없는 상태에 놓일 수 있습니다. 이러한 유형의 문제를 피하기 위해 각 작업은 완전히 적용되거나 전혀 적용되지 않아야 합니다. 작업의 이러한 속성을 원자성이라고 합니다 (원자성).

GitLab은 리포지토리 저장소의 저장소 레이아웃을 제어합니다. GitLab은 리포지토리 저장소에게 리포지토리를 만들고, 삭제하고, 이동할 위치를 지시합니다. 이러한 작업은 여러 물리적 저장소에 적용될 때 원자성 문제를 발생시킬 수 있습니다. 예를 들어:

  • GitLab이 저장소를 삭제하는 동안 그 중 한 곳의 사본이 사용 불가능한 경우.
  • 나중에 GitLab이 저장소를 다시 만들 경우.

결과적으로, 삭제 시에 사용 불가능한 구식 replica는 충돌을 일으키고 저장소의 다시 만들기를 방해할 수 있습니다.

이러한 원자성 문제로 인해 과거에 여러 문제가 발생했습니다:

  • Gitaly Cluster와 함께 이중 지점과의 동기화.
  • 백업 복원.
  • 리포지토리 저장소간의 이동.

Gitaly Cluster는 이러한 작업에 대해 접하는 원자성을 제공하여 부딪히는 문제를 해결합니다.

클라이언트에서 생성한 복제 경로

리포지토리는 Gitaly 클라이언트에 의해 상대적인 경로에 저장됩니다. 이러한 경로는 @cluster 접두사로 시작하지 않기 때문에 식별할 수 있습니다. 상대적 경로는 해시 저장 스키마를 따릅니다.

Praefect에서 생성한 복제 경로

  • 15.0 GitLab에 도입됨, gitaly_praefect_generated_replica_paths라는 플래그로. 기본 설정은 비활성화됨.
  • 15.2 GitLab에서 GitLab.com에서 활성화됨.
  • 15.3 GitLab에서 자체 관리에서 활성화됨.
  • 15.6 GitLab에서 일반 사용 가능함. 기능 플래그 gitaly_praefect_generated_replica_paths가 제거됨.

Gitaly Cluster가 리포지토리를 만들면 리포지토리에 유니크하고 영구적인 ID인 _리포지토리 ID_가 할당됩니다. 리포지토리 ID는 Gitaly Cluster 내부적이며 GitLab의 다른 ID와는 관련이 없습니다. 리포지토리가 Gitaly Cluster에서 제거되었다가 나중에 다시 이동되면 리포지토리는 새로운 리포지토리 ID가 할당되어 Gitaly Cluster의 관점에서 다른 리포지토리가됩니다. 리포지토리 ID의 시퀀스는 항상 증가하지만 시퀀스에 갭이 있을 수 있습니다.

리포지토리 ID는 클러스터의 각 리포지토리에 대해 _복제 경로_라고 하는 고유한 저장소 경로를 파생하기 위해 사용됩니다. 리포지토리의 사본은 모두 저장소의 동일한 복제 경로에 저장됩니다. 복제 경로는 _상대 경로_와 구분됩니다:

  • 상대 경로는 Gitaly 클라이언트가 그들만의 가상 저장소와 함께 고유한 리포지토리를 식별하는데 사용하는 이름입니다.
  • 복제 경로는 물리적 저장소의 실제 경로입니다.

Praefect는 클라이언트 요청을 처리할 때 가상 (가상 저장소, 상대 경로) 식별자를 물리적 리포지토리 (저장소, 복제 경로) 식별자로 변환합니다.

다음과 같은 복사본에 대한 복제 경로 형식은 다릅니다:

  • 객체 풀의 경우 @cluster/pools/<xx>/<xx>/<리포지토리 ID>입니다. 객체 풀은 다른 디렉토리에 저장됩니다. Gitaly는 제거되지 않도록 식별 가능해야 합니다. 객체 풀을 정리하면 연결된 리포지토리에서 데이터 손실을 발생시킬 수 있습니다.
  • 기타 리포지토리의 경우 @cluster/repositories/<xx>/<xx>/<리포지토리 ID>입니다.

예를 들어, @cluster/repositories/6f/96/54771입니다.

복제 경로의 마지막 구성 요소 54771은 리포지토리 ID입니다. 이를 사용하여 디스크에서 리포지토리를 식별할 수 있습니다.

<xx>/<xx>는 리포지토리 ID의 문자열 표현의 SHA256 해시의 처음 네 자리 16진수입니다. 이 숫자는 리포지토리를 균등하게 분산하여 일부 파일 시스템에서 문제가 발생할 수있는 지나치게 큰 디렉토리를 피하기 위해 사용됩니다. 이 경우 54771은 6f960ab01689464e768366d3315b3d3b2c28f38761a58a70110554eb04d582f7를 해시 처리하여 6f 및 96으로 모두 해시됩니다.

디스크 상의 저장소 식별

praefect metadata 하위 명령을 사용하여 다음을 수행하세요.

  • 메타데이터 저장소에서 저장소의 가상 저장소 및 상대 경로를 검색합니다. 해시된 저장소 경로를 얻은 후 Rails 콘솔을 사용하여 프로젝트 경로를 검색할 수 있습니다.
  • 다음 중 클러스터에 저장된 저장소 위치를 찾습니다:
    • 가상 저장소 및 상대 경로.
    • 저장소 ID.

디스크 상의 저장소에는 저장소의 메타데이터가 삭제된 경우에도 구성 파일에서 프로젝트 경로가 포함되어 있습니다. 구성 파일을 사용하여 프로젝트 경로를 결정할 수 있습니다. 해시된 저장소의 문서에서 지침에 따릅니다.

작업의 원자성

Gitaly Cluster는 저장소의 생성, 삭제 및 이동 작업의 원자성을 보장하기 위해 저장 레이아웃을 가진 PostgreSQL 메타데이터 저장소를 사용합니다. 디스크 작업은 여러 저장소에 걸쳐 원자적으로 적용될 수 없습니다. 그러나 PostgreSQL은 메타데이터 작업의 원자성을 보장합니다. Gitaly 클러스터는 실패하는 작업을 항상 일관성 있는 메타데이터로 남도록 작업을 모델링합니다. 디스크는 성공한 작업 후에도 오래된 상태를 가질 수 있습니다. 이 상황은 예상된 것이며 남아있는 상태는 미래의 작업에 방해가 되지는 않지만 정리가 이루어질 때까지 디스크 공간을 불필요하게 사용할 수 있습니다.

저장소에서

복제 요소

복제 요소는 Gitaly Cluster가 특정 저장소의 복사본을 유지하는 수입니다. 더 높은 복제 요소는 다음과 같은 이점을 제공합니다:

  • 더 나은 중복 및 읽기 워크로드 분산을 제공합니다.
  • 보다 높은 저장 비용으로 이어집니다.

기본적으로 Gitaly Cluster는 모든 저장 공간에 저장소를 복제합니다.

구성 정보는 복제 요소 구성를 참조하세요.

Gitaly Cluster 구성

Gitaly Cluster의 구성에 대한 자세한 정보는 Gitaly Cluster 구성을 참조하세요.

Gitaly Cluster 업그레이드

Gitaly Cluster를 업그레이드하려면 제로 다운타임 업그레이드 설명서를 따르세요.

이전 버전으로 Gitaly Cluster 다운그레이드

Gitaly Cluster를 이전 버전으로 롤백해야 하는 경우, 일부 Praefect 데이터베이스 마이그레이션을 되돌아가야 할 수 있습니다.

다음 단계를 따라 Gitaly Cluster를 이전 버전으로 다운그레이드하세요(여러 Praefect 노드를 가정함):

  1. 모든 Praefect 노드에서 Praefect 서비스를 중지합니다: 

    gitlab-ctl stop praefect
  2. Praefect 노드 중 하나에서 GitLab 패키지를 이전 버전으로 다운그레이드하세요.

  3. 다운그레이드된 노드에서 Praefect 마이그레이션 상태를 확인합니다: 

    sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate-status
  4. APPLIED 열에 unknown migration이 포함된 마이그레이션 수를 계산합니다.

  5. 다운그레이드된 노드에서 보고된 알 수 없는 마이그레이션 수를 검증하기 위해 롤백의 드라이 테스트를 수행하세요. <CT_UNKNOWN> 은 다운그레이드된 노드에서 보고된 알 수 없는 마이그레이션 수입니다. 

    sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate <CT_UNKNOWN>

  6. 결과가 올바르게 보이면, 마이그레이션을 되돌릴 타당성을 확인하기 위해 동일한 명령을 -f 옵션과 함께 실행하세요: 

    sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate -f <CT_UNKNOWN>

  7. 남은 Praefect 노드에서 GitLab 패키지를 다운그레이드하고 Praefect 서비스를 다시 시작합니다: 

    gitlab-ctl start praefect

Gitaly Cluster로 마이그레이션

경고: Gitaly Cluster에는 일부 알려진 이슈가 있습니다. 계속하기 전에 다음 정보를 검토하세요.

Gitaly Cluster로 마이그레이션하기 전에 다음을 검토하세요:

  • Gitaly Cluster 배포 전을 검토하세요.
  • 개선 사항 및 버그 수정의 이점을 살리기 위해 가능한 최신 버전의 GitLab으로 업그레이드하세요.

Gitaly Cluster로 마이그레이션하기 위해:

  1. 필요한 저장소를 생성하세요. 저장소 저장 권장사항을 참조하세요.
  2. Gitaly Cluster 만들기 및 구성을 생성 및 구성하세요.
  3. 기존 Gitaly 인스턴스를 TCP를 사용하도록 구성하세요(구성되어 있지 않은 경우).
  4. 저장소를 이동하세요. Gitaly Cluster로 마이그레이션하려면 Gitaly Cluster 밖에 있는 기존 저장소를 이동해야 합니다. 자동 마이그레이션이 없지만 GitLab API를 사용하여 이동을 예약할 수 있습니다.

default 저장소 저장을 사용하지 않더라도 구성되어 있는지 확인해야 합니다. 이 제한 사항에 대해 자세히 알아보기.

Gitaly Cluster에서 마이그레이션 rollback

Gitaly Cluster의 제한 사항 및 교환을 찾는 경우 환경에 적합하지 않다고 판단된다면, Gitaly Cluster에서 sharded Gitaly 인스턴스로 마이그레이션합니다:

  1. 새로운 Gitaly 서버를 생성 및 구성하세요.
  2. 저장소 이동을 새로 생성된 저장소로 이동하세요. 샤드별 또는 그룹별로 이동할 수 있으며 이를 통해 여러 Gitaly 서버로 분산시킬 수 있습니다.

Gitaly Cluster로 전환

복잡성을 제거하기 위해 GitLab에서 직접적인 Git 액세스를 제거해야 합니다. 그러나 일부 GitLab 설치에서는 NFS에서 Git 리포지토리가 필요하기 때문에 제거할 수 없습니다.

GitLab에서 직접적인 Git 액세스를 제거하기 위한 저희의 노력의 두 가지 측면은 다음과 같습니다:

  • GitLab의 비효율적인 Gitaly 쿼리 수를 줄입니다.
  • 장애 허용성 또는 수평 확장된 GitLab 인스턴스의 관리자를 NFS에서 마이그레이션하도록 설득합니다.

두 번째 측면은 유일한 실질적인 해결책을 제시합니다. 이를 위해 저희는 Gitaly Cluster를 개발했습니다.