Gitaly 클러스터의 Gitaly 노드 관리
- 새로운 Gitaly 노드 추가
  - 사용자 정의 복제 요소
  - 기본 복제 요소
- 기존 Gitaly 노드 교체
  - 동일한 이름의 노드로 교체
  - 다른 이름의 노드로 교체
    - 사용자 정의 복제 요소가 설정된 경우
    - 기본 복제 요소
주 노드 장애
데이터 복구
Praefect 추적 데이터베이스 유지 관리

Gitaly 클러스터 복구 옵션 및 도구

Gitaly 클러스터는 주 노드의 장애 및 사용 불가능한 저장소에서 복구할 수 있습니다. Gitaly 클러스터는 데이터 복구를 수행하고 Praefect 추적 데이터벤베이스 도구를 보유하고 있습니다.

Gitaly 클러스터의 Gitaly 노드 관리

Gitaly 클러스터에서 Gitaly 노드를 추가하고 교체할 수 있습니다.

새로운 Gitaly 노드 추가

새로운 Gitaly 노드를 Gitaly 클러스터에 추가하는 단계는 사용자 정의 복제 요소가 설정되었는지에 따라 다릅니다.

사용자 정의 복제 요소

사용자 정의 복제 요소가 설정된 경우, set-replication-factor Praefect 명령을 사용하여 각 저장소의 복제 요소를 설정합니다. 새 저장소는 복제 요소에 따라 복제됩니다. Praefect는 기존 저장소를 새 Gitaly 노드로 자동으로 복제하지 않습니다.

기본 복제 요소

기본 복제 요소를 사용하는 경우, 새 노드를 praefect['virtual_storages']의 Praefect 구성에 추가합니다. Praefect는 구성에 추가된 모든 새로운 Gitaly 노드로 모든 데이터를 자동으로 복제합니다.

기존 Gitaly 노드 교체

기존 Gitaly 노드를 동일한 이름 또는 다른 이름의 새 노드로 교체할 수 있습니다.

동일한 이름의 노드로 교체

교체 노드에 동일한 이름을 사용하려면 저장소 검증기를 사용하여 저장소를 스캔하고 더 이상 필요하지 않은 메타데이터 레코드를 제거합니다. 교체된 저장소의 검증을 수동으로 우선순위를 지정하여 프로세스를 가속화합니다.

다른 이름의 노드로 교체

Gitaly 클러스터의 교체 노드에 다른 이름을 사용하는 단계는 사용자 정의 복제 요소가 설정되었는지에 따라 달라집니다.

사용자 정의 복제 요소가 설정된 경우

사용자 정의 복제 요소가 설정된 경우, 각 저장소의 복제 요소를 다시 설정하여 새로운 저장소를 지정하기 위해 praefect set-replication-factor를 사용합니다. 예시:

$ sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml set-replication-factor -virtual-storage default -relative-path @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git -replication-factor 2

현재 할당: gitaly-1, gitaly-2

새로운 Gitaly 노드를 구성한 후 이전 저장소의 모든 저장소를 새로운 저장소로 재할당하기 위해:

Praefect 데이터베이스에 연결합니다:

/opt/gitlab/embedded/bin/psql -h <psql host> -U <user> -d <database name>

repository_assignments 테이블을 업데이트하여 이전 Gitaly 노드 이름(예: old-gitaly)을 새로운 Gitaly 노드 이름(예: new-gitaly)으로 교체합니다:
```
UPDATE repository_assignments SET storage='new-gitaly' WHERE storage='old-gitaly';
```

기본 복제 요소

기본 복제 요소를 사용하는 경우, 구성에서 노드를 교체합니다. 이전 노드의 상태는 Praefect 데이터베이스에 유지되지만 무시됩니다.

주 노드 장애

GitLab 13.0에서 도입된 Gitaly 클러스터는 주 노드에서 미복제 쓰기가 가장 적은 이차 노드를 새 주 노드로 선출합니다. 여전히 미복제 쓰기가 발생할 수 있으므로 데이터 유실이 발생할 수 있습니다.
GitLab 14.1에 추가된 주 노드 장애 복구 지원.

Gitaly 클러스터는 고장난 주 Gitaly 노드를 건강한 이차 노드로 승격하여 새 주 노드로 복구합니다. Gitaly 클러스터는:

저장소를 완전히 최신 복사본을 보유한 건강한 이차에게 새 주 노드로 선출합니다.
건강한 이차에 완전히 최신 복사본이 없으면 저장소는 사용 불가능 상태가 됩니다.

사용 불가능한 저장소

GitLab 13.0부터 14.0까지, 주 노드에서는 오래된 상태이지만 건강한 이차에 완전히 최신인 저장소는 읽기 전용으로 전환되었습니다. dataloss 하위 명령은 이러한 버전을 통해 기본적으로 읽기 전용 저장소를 표시합니다.
GitLab 14.1부터 Praefect에는 바로 대응하는 장애 조치 논리가 포함되어 저장소를 읽기 전용 모드로 전환하는 대신 즉시 완전히 최신인 이차 중 하나로 장애 조치합니다. GitLab 14.1부터 dataloss 하위 명령은 건강한 Gitaly 노드에서 완전히 최신인 복사본이 없어 사용 불가능한 저장소를 표시합니다.

모든 최신 복제본이 사용 불가능하면 저장소가 사용 불가능 상태가 됩니다. 사용 불가능한 저장소는 자동화된 도구가 손상된 데이터를 제공할 수 있으므로 Praefect를 통해 접근할 수 없습니다.

데이터 손실 확인

Praefect dataloss 하위 명령은 다음을 식별합니다:

GitLab 13.0에서 14.0으로의 저장소 사본에서 만료된 것으로 생각될 수 있는 것을 식별합니다. 이는 장애 조치 후 잠재적인 데이터 손실을 식별하는 데 도움이 될 수 있습니다.
GitLab 14.1 이상에서 사용할 수 없는 저장소입니다. 이것은 잠재적인 데이터 손실과 모든 최신 복제본 사본이 사용할 수 없기 때문에 더 이상 액세스할 수 없는 저장소를 식별하는 데 도움이 됩니다.

다음 매개 변수를 사용할 수 있습니다:

-virtual-storage는 어떤 가상 저장소를 확인할지 지정합니다. 이들은 관리자의 개입이 필요할 수 있기 때문에 기본 동작은 다음을 표시하는 것입니다:
- 13.0에서 14.0까지 GitLab의 읽기 전용 저장소 사본.
- 14.1 이상의 GitLab에서 사용할 수 없는 저장소.
14.1 이상의 GitLab에서는 출력에 포함할지 여부를 지정하는 -partially-unavailable가 있습니다. 사용 가능하지만 일부 할당된 사본이 사용할 수 없는 저장소를 출력에 포함할지 여부를 지정합니다.

참고: dataloss는 여전히 베타 상태이며 출력 형식이 변경될 수 있습니다.

만료된 주 서버를 가진 저장소 또는 사용할 수 없는 저장소를 확인하려면 다음을 실행합니다:

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss [-virtual-storage <가상-저장소>]

지정된 저장소가 없으면 모든 구성된 가상 저장소를 확인합니다:

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss

출력에 나오는 저장소는 다음 중 하나를 갖습니다:

주 서버에서의 만료된 저장소 사본 (GitLab 13.0 ~ GitLab 14.0).
사용할 수 없는 저장소에 대한 건강하고 완전히 최신의 사본이 없음 (GitLab 14.1 이상).

각 저장소에 대해 다음 정보가 출력됩니다:

저장소의 상대적 경로는 저장소를 식별하고 관련 정보를 그룹화합니다.
저장소의 현재 상태는 디스크 경로 옆에 괄호 안에 인쇄됩니다:
- 13.0에서 14.0에는 저장소의 주 노드가 만료되어 쓰기를 수용할 수 없는 경우 (read-only)로 출력됩니다. 그렇지 않으면 (writable)로 출력됩니다.
- 14.1에서 다음은 저장소가 사용할 수 없는 경우 디스크 경로 옆에 (unavailable)로 출력됩니다.
주 필드는 저장소의 현재 주 서버를 나열합니다. 저장소에 주 서버가 없으면 해당 필드에 No Primary가 표시됩니다.
In-Sync Storages는 최신 성공적인 쓰기와 그 이전의 모든 쓰기를 복제한 사본을 나열합니다.
Outdated Storages는 저장소의 만료된 사본을 포함하거나 저장소가 없어야 할 사본들을 나열합니다. 사본이 누락된 변경의 최대 횟수가 각 사본 옆에 나열됩니다. 만료된 사본이 완전히 최신 상태일 수도 있고 나중에 변경 사항을 포함할 수도 있지만 Praefect는 이를 보장할 수 없습니다.

추가 정보는 다음과 같습니다:

노드가 저장소를 호스팅하도록 지정된 경우 각 노드의 상태와 함께 나열됩니다. 저장소를 저장하도록 지정된 노드 옆에는 assigned host가 출력됩니다. 노드에 저장소의 사본이 있지만 저장소를 저장하도록 지정되지 않은 경우 텍스트가 생략됩니다. 이러한 사본은 Praefect에 의해 동기화되지 않지만 지정된 사본을 최신 상태로 가져 오도록 복제 소스로 작용할 수 있습니다.
14.1 이상의 GitLab에서는 unhealthy가 저장된 위치의 부사본 옆에 인쇄됩니다.

출력 예시:

가상 저장소: 기본
  만료된 저장소:
    @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git (사용 불가):
      주: gitaly-1
      In-Sync Storages:
        gitaly-2, assigned host, unhealthy
      Outdated Storages:
        gitaly-1은 3번 이하 뒤쳐져 있음, assigned host
        gitaly-3은 3번 이하 뒤쳐져 있음

각 저장소가 사용 가능하면 확인이 출력됩니다. 예:

가상 저장소: 기본
  모든 저장소 사용 가능!

사용 가능한 저장소의 사용 불가능한 사본

GitLab 14.0에서 도입되었으며, -partially-replicated로부터 이름이 변경되고 동작이 변경되었습니다.

할당된 노드 중 일부가 임시로 사용할 수 없을 수도 있는 일부 할당된 부 사본을 출력하는 것을 원하는 경우, -partially-unavailable 플래그를 사용하세요.

할당된 보조 사본의 업데이트가 이루어질 때까지 일시적으로 일부 할당된 보조 사본이 접근 불가능할 수 있기 때문에 저장소가 사용 가능한 경우가 있습니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss [-virtual-storage <가상-저장소>] [-partially-unavailable]

출력 예시:

가상 저장소: 기본
  만료된 저장소:
    @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git:
      주: gitaly-1
      In-Sync Storages:
        gitaly-1, assigned host
      Outdated Storages:
        gitaly-2는 3번 이하 뒤쳐져 있음, assigned host
        gitaly-3은 3번 이하 뒤쳐져 있음

-partially-unavailable 플래그가 설정된 경우, 모든 할당된 사본이 완전히 최신 상태이고 건강한 경우 확인이 출력됩니다.

예:

가상 저장소: 기본
  모든 할당된 저장소가 모든 사본에서 완전히 사용 가능합니다!

저장소 체크섬 확인

모든 Gitaly 노드에서 프로젝트 저장소의 체크섬을 확인하려면 메인 GitLab 노드에서 레플리카 레이크 작업을 실행하세요.

데이터 손실 수용

경고: accept-dataloss는 저장소의 다른 버전을 덮어쓰며 영구적인 데이터 손실을 야기합니다. 데이터 복구 작업을 수행한 후에 사용해야 합니다.

최신 상태의 레플리카 중 하나를 다시 온라인으로 가져올 수 없는 경우 데이터 손실을 수용해야 할 수 있습니다. 데이터 손실을 수용하면 Praefect는 선택한 저장소의 레플리카를 최신 버전으로 표시하고 다른 할당된 Gitaly 노드로 레플리케이트합니다. 이 과정은 저장소의 다른 버전을 덮어쓸 수 있으므로 주의가 필요합니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss
-virtual-storage <가상-스토리지> -relative-path <상대-경로> -authoritative-storage <스토리지-명>

쓰기 가능하게하거나 데이터 손실 수용

경고: accept-dataloss는 저장소의 다른 버전을 덮어쓰며 영구적인 데이터 손실을 야기합니다. 데이터 복구 작업을 수행한 후에 사용해야 합니다.

Praefect는 쓰기를 다시 활성화하거나 데이터 손실을 수용하기 위해 다음 하위 명령을 제공합니다. 최신 상태의 노드 중 하나를 다시 온라인으로 가져올 수 없는 경우 데이터 손실을 수용해야 할 수 있습니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss -virtual-storage <가상-스토리지> -relative-path <상대-경로> -authoritative-storage <스토리지-명>

데이터 손실을 수용할 때 Praefect는 다음을 수행합니다:

선택한 저장소 사본을 최신 버전으로 표시합니다.
사본을 다른 할당된 Gitaly 노드로 레플리케이트합니다.

이 과정은 저장소의 다른 사본을 덮어쓸 수 있으므로 주의가 필요합니다.

데이터 복구

Gitaly 노드가 어떠한 이유로 복제 작업에 실패하는 경우, 영향을 받는 저장소의 오래된 버전을 호스팅하게 됩니다. Praefect는 다음을 위한 도구를 제공합니다:

자동 조정(GitLab 13.4 이상).
수동 조정:
- GitLab 13.3 이하.
- repositories 테이블에 항목이 없는 상태로 GitLab 13.4 이상으로 업그레이드된 저장소. GitLab 13.6 이상에서는 마이그레이션이 실행됩니다 Praefect가 이러한 저장소에 대해 시작될 때.

이 도구들은 오래된 저장소를 조정하여 완전히 최신 상태로 가져옵니다.

자동 조정

13.4 버전에서 도입되었습니다.

Praefect는 자동으로 최신 상태가 아닌 저장소를 조정합니다. 기본적으로 이 작업은 5분마다 수행됩니다. 건강한 Gitaly 노드에서 오래된 저장소마다 Praefect는 다른 건강한 Gitaly 노드에 있는 표준으로 최신 상태인 해당 저장소의 임의의 사본을 선택하여 레플리케이트합니다. 대상 저장소에 대기 중인 다른 레플리케이션 작업이 없는 경우에만 레플리케이션 작업이 예약됩니다.

조정 빈도는 구성을 통해 변경할 수 있습니다. 이 값을 유효한 Go 기간 값으로 지정할 수 있습니다. 0 이하는 기능을 사용 안 함을 나타냅니다.

예시:

praefect['configuration'] = {
   # ...
   reconciliation: {
      # ...
      scheduling_interval: '5m', # 기본 값
   },
}

praefect['configuration'] = {
   # ...
   reconciliation: {
      # ...
      scheduling_interval: '30s', # 30초마다 조정
   },
}

praefect['configuration'] = {
   # ...
   reconciliation: {
      # ...
      scheduling_interval: '0', # 기능 비활성화
   },
}

수동 조정

경고: reconcile 하위 명령이 GitLab 14.1에서 제거되었습니다. 대신 자동 조정을 사용하세요. 수동 조정은 초과 레플리케이션 작업을 생성할 수 있으며 기능이 제한됩니다. 수동 조정은 저장소별 주 노드가 활성화된 경우 작동하지 않습니다.

Praefect reconcile 하위 명령을 사용하면 두 Gitaly 노드 간에 수동으로 조정할 수 있습니다. 해당 명령은 기준 저장소에 있는 모든 저장소의 최신 버전을 대상 저장소로 레플리케이트합니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml reconcile -virtual <가상-스토리지> -reference <최신-스토리지> -target <오래된-스토리지> -f

<가상-스토리지>를 사용할 Gitaly 노드 스토리지를 포함하는 가상 스토리지로 대체하세요.
<최신-스토리지>를 최신의 저장소를 포함한 Gitaly 스토리지 이름으로 대체하세요.
<오래된-스토리지>를 오래된 저장소를 포함한 Gitaly 스토리지 이름으로 대체하세요.

저장소 수동으로 제거

GitLab 14.3에서 도입됨.
GitLab 14.6에서 도입됨. dry-run 모드 지원.
GitLab 15.3에서 도입됨. Praefect 추적 데이터베이스에서 저장소 제거 지원.

remove-repository Praefect 하위 명령은 Gitaly Cluster에서 저장소 및 관련 상태를 모두 제거합니다.

관련 Gitaly 노드에있는 디스크 저장소.
Praefect가 추적하는 모든 데이터베이스 상태.

GitLab 14.6 및 이후 버전에서는 기본적으로 명령이 dry-run 모드에서 작동합니다. 이전 버전에서는 dry-run 모드가 지원되지 않았습니다. 예를 들면:

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage <가상-저장소> -relative-path <저장소>

<가상-저장소>를 저장소를 포함하는 가상 저장소의 이름으로 바꿉니다.
<저장소>를 제거할 저장소의 상대 경로로 바꿉니다.
GitLab 15.3 이상 버전에서는 on-disk 저장소를 제거하지 않고 Praefect 추적 데이터베이스 항목을 제거하려면 -db-only를 추가합니다. 이 옵션은 고아 상태의 데이터베이스 항목을 제거하고, 유효한 저장소가 실수로 지정된 경우 디스크 상의 저장소 데이터가 삭제되는 것을 방지합니다. 데이터베이스 항목을 실수로 삭제한 경우 track-repository 명령으로 저장소를 다시 추적합니다.

GitLab 14.6 및 이후 버전에서는 -apply를 추가하여 dry-run 모드 외에서 명령을 실행하고 저장소를 제거합니다. 예를 들면:

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage <가상-저장소> -relative-path <저장소> -apply

-virtual-storage는 저장소가 있는 가상 저장소입니다. Virtual storages는 /etc/gitlab/gitlab.rb의 praefect['configuration']['virtual_storage]에 구성되어 있으며 다음과 같습니다.
```
praefect['configuration'] = {
  # ...
  virtual_storage: [
    {
      # ...
      name: 'default',
    },
    {
      # ...
      name: 'storage-1',
    },
  ],
}
```
이 예에서 지정해야 하는 가상 저장소는 default 또는 storage-1입니다.
-repository는 저장소의 저장소 상대 경로입니다. [ @hashed로 시작하는 저장소 storage paths]의 일부입니다. 예를 들어:
```
@hashed/f5/ca/f5ca38f748a1d6eaf726b8a42fb575c3c71f1864a8143301782de13da2d9202b.git
```

remove-repository를 실행한 후 저장소의 일부가 남을 수 있습니다. 이는 다음과 같은 이유로 발생할 수 있습니다.

삭제 오류.
저장소를 대상으로 한 진행 중인 RPC 호출.

이런 경우에는 remove-repository을 다시 실행합니다.

Praefect 추적 데이터베이스 유지 관리

Praefect 추적 데이터베이스의 일반 유지 관리 작업은 이 섹션에 문서화되어 있습니다.

추적되지 않은 저장소 나열

GitLab 14.4에서 도입됨.
older-than 옵션이 GitLab 15.0에 추가됨.

list-untracked-repositories Praefect 하위 명령은 Gitaly Cluster의 저장소를 나열합니다.

적어도 하나 이상의 Gitaly 저장소에 존재합니다.
Praefect 추적 데이터베이스에 추적되지 않습니다.

-older-than 옵션을 추가하여 다음을 표시하지 않도록 합니다.

생성 중인 저장소.
아직 Praefect 추적 데이터베이스에 레코드가 없는 저장소.

<기간>을 시간 기간으로 바꿉니다(예: 5s, 10m, 또는 1h). 기본값은 6h입니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-untracked-repositories -older-than <기간>

지정된 기간 이전에 생성된 저장소만 고려됩니다.

명령은 다음을 출력합니다.

STDOUT 및 명령의 로그 결과.
STDERR에 대한 오류 메시지.

각 항목은 마지막에 새 줄로 된 완전한 JSON 문자열입니다(-delimiter 플래그를 사용하여 구성 가능). 예를 들면:

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-untracked-repositories
{"virtual_storage":"default","storage":"gitaly-1","relative_path":"@hashed/ab/cd/abcd123456789012345678901234567890123456789012345678901234567890.git"}
{"virtual_storage":"default","storage":"gitaly-1","relative_path":"@hashed/ab/cd/abcd123456789012345678901234567890123456789012345678901234567891.git"}

단일 저장소를 추적 데이터베이스에 수동으로 추가

GitLab 14.4에서 소개됨.
GitLab 14.6에서 즉시 복제를 지원하는 지원이 추가됨.

경고: Praefect에서 생성된 레플리카 경로(@cluster)로 생성된 리포지토리는 Praefect 추적 데이터베이스에 추가할 수 없습니다. 이러한 리포지토리는 GitLab이 사용하는 리포지토리 경로와 관련이 없으며 접근할 수 없습니다.

track-repository Praefect 하위 명령은 디스크에 있는 리포지토리를 Praefect 추적 데이터베이스에 추가하여 추적합니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml track-repository -virtual-storage <가상-스토리지> -authoritative-storage <스토리지-이름> -relative-path <리포지토리> -replica-path <디스크_경로> -replicate-immediately

-virtual-storage는 리포지토리가 위치한 가상 스토리지입니다. 가상 스토리지는 /etc/gitlab/gitlab.rb의 praefect['configuration'][:virtual_storage]에 구성되어 있으며 다음과 같이 보입니다:
```
praefect['configuration'] = {
  # ...
  virtual_storage: [
    {
      # ...
      name: 'default',
    },
    {
      # ...
      name: 'storage-1',
    },
  ],
}
```
이 예에서 지정해야 할 가상 스토리지는 default 또는 storage-1입니다.
-relative-path는 가상 스토리지 내의 상대 경로입니다. 일반적으로 @hashed로 시작합니다. 예:
```
@hashed/f5/ca/f5ca38f748a1d6eaf726b8a42fb575c3c71f1864a8143301782de13da2d9202b.git
```
-replica-path는 물리적 스토리지의 상대 경로입니다. @cluster로 시작하거나 relative_path와 일치할 수 있습니다.
-authoritative-storage는 Praefect가 주 프라이머리로 취급해야 하는 저장소입니다. 저장소별 복제가 복제 전략으로 설정된 경우 필요합니다.
-replicate-immediately는 GitLab 14.6 이후 사용 가능하며 리포지토리를 즉시 복제하도록 합니다. 그렇지 않으면 복제 작업은 데이터베이스에서 실행을위한 예약이되어 Praefect 백그라운드 프로세스에서 가져옵니다.

이 명령은 다음을 출력합니다:

STDOUT 및 명령의 로그 결과.
STDERR에 대한 오류.

이 명령은 다음 경우에 실패합니다:

리포지토리가 이미 Praefect 추적 데이터베이스에 추적되고 있음.
리포지토리가 디스크에 존재하지 않음.

다수의 저장소를 추적 데이터베이스에 수동으로 추가

GitLab 15.4에서 소개됨.

API를 사용하여 마이그레이션하면 리포지토리를 Praefect 추적 데이터베이스에 자동으로 추가합니다.

대신 기존 인프라에서 수동으로 리포지토리를 복사하는 경우 track-repositories Praefect 하위 명령을 사용할 수 있습니다. 이 하위 명령은 디스크에 대규모 리포지토리를 Praefect 추적 데이터베이스에 추가합니다.

# Omnibus GitLab 설치
sudo gitlab-ctl praefect track-repositories --input-path /path/to/input.json

# 소스 설치
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml track-repositories -input-path /path/to/input.json

이 명령은 다음을 확인합니다:

올바르게 서식이 지정되었으며 필수 필드가 포함되었는지 확인.
유효한 Git 리포지토리와 일치하는지 확인.
Praefect 추적 데이터베이스에 추적되지 않았는지 확인합니다.

이러한 점검에 실패하는 항목이 있으면 명령은 리포지토리를 추적하려고 시도하기 전에 중단됩니다.

input-path는 새 줄로 구분된 JSON 객체 목록이 포함 된 파일의 경로입니다. 객체에는 다음 키가 있어야합니다:

relative_path: track-repository의 repository와 일치합니다.
authoritative-storage: Praefect가 주 프라이머리로 취급해야 하는 스토리지입니다.

virtual-storage: 리포지토리가 위치한 가상 스토리지입니다.

예:

{"relative_path":"@hashed/f5/ca/f5ca38f748a1d6eaf726b8a42fb575c3c71f1864a8143301782de13da2d9202b.git","replica_path":"@cluster/fe/d3/1","authoritative_storage":"gitaly-1","virtual_storage":"default"}
{"relative_path":"@hashed/f8/9f/f89f8d0e735a91c5269ab08d72fa27670d000e7561698d6e664e7b603f5c4e40.git","replica_path":"@cluster/7b/28/2","authoritative_storage":"gitaly-2","virtual_storage":"default"}

-replicate-immediately는 리포지토리를 즉시 두 번째 위치로 복제하도록합니다. 그렇지 않으면 복제 작업은 데이터베이스에서 실행을위한 예약이되어 Praefect 백그라운드 프로세스에서 가져옵니다.

가상 저장소 세부 정보 목록

소개된 GitLab 15.1.

list-storages Praefect 하위 명령은 가상 저장소와 해당 저장소 노드를 나열합니다. 가상 저장소가 다음과 같은 경우:

-virtual-storage를 사용하여 지정된 경우 지정된 가상 저장소에 대한 저장소 노드만 나열합니다.
지정되지 않은 경우 모든 가상 저장소와 해당 저장소 노드가 표 형식으로 나열됩니다.

sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-storages -virtual-storage <가상_저장소_이름>

해당 명령은 다음을 출력합니다:

STDOUT에 결과 및 명령 로그를 출력합니다.
STDERR에 오류를 출력합니다.

Gitaly 클러스터 복구 옵션 및 도구

Gitaly 클러스터의 Gitaly 노드 관리

새로운 Gitaly 노드 추가

사용자 정의 복제 요소

기본 복제 요소

기존 Gitaly 노드 교체

동일한 이름의 노드로 교체

다른 이름의 노드로 교체

사용자 정의 복제 요소가 설정된 경우

기본 복제 요소

주 노드 장애

사용 불가능한 저장소

데이터 손실 확인

사용 가능한 저장소의 사용 불가능한 사본

저장소 체크섬 확인

데이터 손실 수용

쓰기 가능하게하거나 데이터 손실 수용

데이터 복구

자동 조정

수동 조정

저장소 수동으로 제거

Praefect 추적 데이터베이스 유지 관리

추적되지 않은 저장소 나열

단일 저장소를 추적 데이터베이스에 수동으로 추가

다수의 저장소를 추적 데이터베이스에 수동으로 추가

가상 저장소 세부 정보 목록

도움말

기능 사용 가능성과 제품 평가판

도움받기