Gitaly 클러스터에서 Gitaly 노드 관리
- 새 Gitaly 노드 추가
  - 사용자 정의 복제 계수
  - 기본 복제 계수
- 기존 Gitaly 노드 교체
  - 동일한 이름의 노드로
  - 다른 이름의 노드로
    - 복제 계수 설정됨
기본 노드 실패
데이터 복구
- 리포지토리 수동 제거
Praefect 추적 데이터베이스 유지관리

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

Gitaly 클러스터는 주 노드 장애 및 사용할 수 없는 저장소에서 복구할 수 있습니다. Gitaly 클러스터는 데이터 복구를 수행할 수 있으며 Praefect 추적 데이터베이스 도구를 갖추고 있습니다.

Gitaly 클러스터에서 Gitaly 노드 관리

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

새 Gitaly 노드 추가

새 Gitaly 노드를 추가하려면:

문서를 따라 새로운 Gitaly 노드를 설치합니다.
praefect['virtual_storages'] 아래에 Praefect 구성에 새 노드를 추가합니다.
다음 명령어를 실행하여 Praefect를 재구성하고 재시작합니다:
```
gitlab-ctl reconfigure
gitlab-ctl restart praefect
```

복제 행동은 복제 계수 설정에 따라 달라집니다.

사용자 정의 복제 계수

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

기본 복제 계수

기본 복제 계수가 사용되는 경우, Praefect는 복제 계수를 유지하기 위해 구성에 추가된 모든 새 Gitaly 노드로 모든 데이터를 자동으로 복제합니다.

기존 Gitaly 노드 교체

동일한 이름이나 다른 이름을 가진 새로운 노드로 기존 Gitaly 노드를 교체할 수 있습니다. 이전 노드를 제거하기 전에:

복제 계수가 설정된 경우, 데이터 손실을 방지하기 위해 1보다 커야 합니다.
복제 계수가 설정되지 않은 경우, 저장소는 가상 스토리지 아래의 모든 노드에서 복제됩니다.

동일한 이름의 노드로

교체 노드에 동일한 이름을 사용하려면 저장소 검증기를 사용하여 저장소를 스캔하고 고리를 가진 메타데이터 레코드를 제거합니다. 과정 속도를 높이기 위해 교체된 저장소의 검증 우선순위를 수동으로 설정합니다.

다른 이름의 노드로

Gitaly 클러스터에서 교체 노드에 다른 이름을 사용하는 단계는 복제 계수가 설정되어 있는지에 따라 다릅니다.

복제 계수 설정됨

사용자 정의 복제 계수가 설정된 경우, 저장소를 새로 배정받기 위해 각 저장소에 대한 복제 계수를 다시 설정하기 위해 praefect set-replication-factor를 사용합니다.

예를 들어, 가상 스토리지에 있는 두 노드가 복제 계수가 2이고 새 노드(gitaly-3)가 추가된 경우, 복제 계수를 3으로 증가시켜야 합니다:

$ sudo -u git -- /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 3

current assignments: gitaly-1, gitaly-2, gitaly-3

이렇게 하면 저장소가 새 노드에 복제되고 repository_assignments 테이블이 새 Gitaly 노드의 이름으로 업데이트됩니다.

기본 복제 계수가 설정된 경우, 새 노드는 복제에 자동으로 포함되지 않습니다. 위에 설명한 단계를 따라야 합니다.

새 노드에 저장소가 성공적으로 복제되었는지 확인한 후:

praefect['virtual_storages'] 아래의 Praefect 구성에서 gitaly-1 노드를 제거합니다.

Praefect를 재구성하고 재시작합니다:

gitlab-ctl reconfigure
gitlab-ctl restart praefect

오래된 Gitaly 노드에 대한 데이터베이스 상태는 무시할 수 있습니다.

대안으로, 새로운 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';
```

이것은 적절한 복제 작업을 트리거하여 시스템을 원하는 상태로 되돌릴 것입니다.

기본 노드 실패

Gitaly Cluster는 고장난 기본 Gitaly 노드에서 건강한 보조 노드를 새로운 기본 노드로 승격하여 복구합니다. Gitaly Cluster:

저장소의 완전하게 최신 상태의 복사본을 가진 건강한 보조 노드를 새로운 기본 노드로 선출합니다.
완전하게 최신 상태의 보조 노드가 없는 경우, 기본 노드에서 복제되지 않은 쓰기가 가장 적은 보조 노드를 새로운 기본 노드로 선출합니다.
건강한 보조 노드에 완전하게 최신 상태의 복사본이 없다면 저장소는 사용할 수 없게 됩니다. 이를 감지하기 위해 Praefect dataloss 하위 명령어를 사용하세요.

사용 불가능한 저장소

모든 최신 복제본이 사용 불가능한 경우 저장소는 사용 불가능합니다. 오래된 데이터를 제공하여 자동화 도구가 중단되는 것을 방지하기 위해 사용 불가능한 저장소는 Praefect를 통해 접근할 수 없습니다.

데이터 손실 확인

Praefect dataloss 하위 명령어는 사용 불가능한 저장소를 식별합니다. 이는 잠재적인 데이터 손실과 최신 복제본이 모두 사용 불가능하여 더 이상 접근할 수 없는 저장소를 식별하는 데 도움이 됩니다.

다음 매개변수가 사용 가능합니다:

-virtual-storage는 어떤 가상 저장소를 확인할지 지정합니다. 관리자의 개입이 필요할 수 있으므로 기본 동작은 사용 불가능한 저장소를 표시합니다.
-partially-unavailable 매개변수는 출력에 사용 가능하나 일부 할당된 복사본이 이용할 수 없는 저장소를 포함할지 여부를 지정합니다.

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

구식 기본이 있는 저장소나 사용 불가능한 저장소를 확인하려면 다음을 실행하세요:

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss [-virtual-storage <virtual-storage>]

지정하지 않으면 모든 구성된 가상 저장소가 확인됩니다:

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

출력에는 건강하고 완전하게 최신 상태의 복사본이 없는 저장소가 나열됩니다. 각 저장소에 대한 다음 정보가 인쇄됩니다:

저장소의 상대 경로가 저장소 디렉터리를 식별하고 관련 정보를 그룹화합니다.
저장소가 사용 불가능한 경우 디스크 경로 옆에 (unavailable)가 인쇄됩니다.
기본 필드는 저장소의 현재 기본 노드를 나열합니다. 저장소에 기본 노드가 없는 경우 필드는 No Primary를 표시합니다.
In-Sync Storages는 최신 성공적인 쓰기와 그 이전의 모든 쓰기를 복제한 복제본을 나열합니다.
Outdated Storages는 저장소의 구식 복사본을 포함한 복제본을 나열합니다. 저장소의 복사본이 없지만 포함해야 하는 복제본도 여기에 나열됩니다. 복제본이 놓친 변경 사항의 최대 수는 복제본 옆에 나열됩니다. 구식 복제본은 완전하게 최신 상태일 수도 있고 이후 변경 사항을 포함할 수도 있지만 Praefect는 이를 보장할 수 없습니다.

추가 정보는 다음을 포함합니다:

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

예시 출력:

Virtual storage: default
  Outdated repositories:
    @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git (unavailable):
      Primary: gitaly-1
      In-Sync Storages:
        gitaly-2, assigned host, unhealthy
      Outdated Storages:
        gitaly-1 is behind by 3 changes or less, assigned host
        gitaly-3 is behind by 3 changes or less

모든 저장소가 이용 가능할 때 확인 문구가 인쇄됩니다. 예를 들어:

Virtual storage: default
  All repositories are available!

사용 가능한 리포지토리의 사용 불가능한 복제본

사용 가능하지만 일부 할당된 노드에서 사용할 수 없는 리포지토리에 대한 정보를 나열하려면, -partially-unavailable 플래그를 사용합니다.

리포지토리는 건강하고 최신 상태의 복제본이 있는 경우 사용 가능합니다. 일부 할당된 보조 복제본은 최신 변경 사항을 복제하는 동안 일시적으로 액세스할 수 없게 될 수 있습니다.

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss [-virtual-storage <virtual-storage>] [-partially-unavailable]

예시 출력:

Virtual storage: default
  구식 리포지토리:
    @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git:
      Primary: gitaly-1
      동기화된 스토리지:
        gitaly-1, 할당된 호스트
      구식 스토리지:
        gitaly-2는 3개의 변경 사항 뒤쳐져 있으며, 할당된 호스트
        gitaly-3는 3개의 변경 사항 뒤쳐져 있습니다.

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

예를 들면:

Virtual storage: default
  모든 리포지토리가 모든 할당된 스토리지에서 완전히 사용 가능합니다!

리포지토리 체크섬 확인

모든 Gitaly 노드에서 프로젝트의 리포지토리 체크섬을 확인하려면, 메인 GitLab 노드에서 replicas Rake 작업을 실행하세요.

데이터 손실 수용

경고: accept-dataloss는 리포지토리의 다른 버전을 덮어짐으로써 영구적인 데이터 손실을 일으킵니다. 사용하기 전에 데이터 복구 작업을 수행해야 합니다.

최신 복제본 중 하나를 온라인으로 복구하는 것이 불가능한 경우, 데이터 손실을 수용해야 할 수도 있습니다. 데이터 손실을 수용할 때 Praefect는 선택된 리포지토리 복제본을 최신 버전으로 표시하고 이를 다른 할당된 Gitaly 노드에 복제합니다. 이 과정은 리포지토리의 다른 버전을 덮어쓰므로 주의해야 합니다.

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss
-virtual-storage <virtual-storage> -relative-path <relative-path> -authoritative-storage <storage-name>

쓰기 활성화 또는 데이터 손실 수용

경고: accept-dataloss는 리포지토리의 다른 버전을 덮어짐으로써 영구적인 데이터 손실을 일으킵니다. 데이터 복구 작업을 수행해야 합니다.

Praefect는 쓰기를 다시 활성화하거나 데이터 손실을 수용하기 위한 다음의 하위 명령을 제공합니다. 최신 노드 중 하나를 온라인으로 복구하는 것이 불가능한 경우, 데이터 손실을 수용해야 할 수도 있습니다:

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss -virtual-storage <virtual-storage> -relative-path <relative-path> -authoritative-storage <storage-name>

데이터 손실을 수용할 때 Praefect는:

선택한 리포지토리 복제본을 최신 버전으로 표시합니다.
복사본을 다른 할당된 Gitaly 노드에 복제합니다.

이 과정은 리포지토리의 다른 복사본을 덮어쓰므로 주의해야 합니다.

데이터 복구

Gitaly 노드가 어떤 이유로든 복제 작업에 실패하면 영향을 받은 리포지토리의 구식 버전을 호스팅하게 됩니다. Praefect는 자동 조정 도구를 제공합니다. 이 도구들은 구식 리포지토리를 조정하여 완전히 최신 상태로 되돌립니다.

Praefect는 최신 상태가 아닌 리포지토리를 자동으로 조정합니다. 기본적으로, 이 작업은 5분마다 수행됩니다. 건강한 Gitaly 노드에서 구식 리포지토리에 대해 Praefect는 다른 건강한 Gitaly 노드에서 완전히 최신 상태의 리포지토리의 복제본을 무작위로 선택하여 복제합니다. 대상 리포지토리에 대해 대기 중인 다른 복제 작업이 없는 경우에만 복제 작업이 예약됩니다.

조정 빈도는 구성 파일을 통해 변경할 수 있습니다. 값은 유효한 Go duration value일 수 있습니다. 0보다 낮은 값은 이 기능을 비활성화합니다.

예시:

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

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

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

리포지토리 수동 제거

GitLab 15.3에서 도입됨, Praefect 추적 데이터베이스에서 리포지토리를 제거하는 지원.

remove-repository Praefect 하위 명령은 Gitaly 클러스터에서 리포지토리를 제거하며, 특정 리포지토리와 관련된 모든 상태를 포함합니다:

모든 관련 Gitaly 노드에서의 디스크 상 리포지토리.
Praefect에 의해 추적되는 모든 데이터베이스 상태.

기본적으로, 명령은 건조 실행 모드에서 작동합니다. 예를 들어:

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage <virtual-storage> -relative-path <repository>

<virtual-storage>를 리포지토리를 포함하는 가상 스토리지의 이름으로 바꿉니다.
<repository>를 제거할 리포지토리의 상대 경로로 바꿉니다.
GitLab 15.3 및 이후 버전에서는 -db-only를 추가하여 디스크 상 리포지토리를 제거하지 않고 Praefect 추적 데이터베이스 항목만 제거합니다. 이 옵션을 사용하여 고아 데이터베이스 항목을 제거하고 유효한 리포지토리가 우연히 지정될 때 디스크 상 리포지토리 데이터를 삭제로부터 보호합니다. 데이터베이스 항목이 우연히 삭제된 경우, track-repository 명령으로 리포지토리를 다시 추적합니다.

-apply를 추가하여 건조 실행 모드를 벗어나 명령을 실행하고 리포지토리를 제거합니다. 예를 들어:

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml remove-repository -virtual-storage <virtual-storage> -relative-path <repository> -apply

-virtual-storage는 리포지토리가 위치한 가상 스토리지입니다. 가상 스토리지는 /etc/gitlab/gitlab.rb의 praefect['configuration']['virtual_storage]에서 구성되며 다음과 같이 보입니다:
```
praefect['configuration'] = {
  # ...
  virtual_storage: [
    {
      # ...
      name: 'default',
    },
    {
      # ...
      name: 'storage-1',
    },
  ],
}
```
이 예시에서 지정할 가상 스토리지는 default 또는 storage-1입니다.
-repository는 스토리지에서의 리포지토리의 상대 경로입니다 계속 @hashed. 예를 들어:
```
@hashed/f5/ca/f5ca38f748a1d6eaf726b8a42fb575c3c71f1864a8143301782de13da2d9202b.git
```

리포지토리를 제거한 후에도 리포지토리의 일부가 계속 존재할 수 있습니다. 이는 다음 때문일 수 있습니다:

삭제 오류.
리포지토리를 대상으로 하는 진행 중인 RPC 호출.

이런 경우, remove-repository를 다시 실행하세요.

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

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

추적되지 않은 리포지토리 목록

GitLab 15.0에서 older-than 옵션 추가됨.

list-untracked-repositories Praefect 서브 커맨드는 다음 두 가지 조건을 만족하는 Gitaly 클러스터의 리포지토리를 나열합니다:

적어도 하나의 Gitaly 스토리지에 존재합니다.
Praefect 추적 데이터베이스에서 추적되지 않습니다.

-older-than 옵션을 추가하여 다음을 포함하는 리포지토리를 표시하지 않도록 할 수 있습니다:

생성 중인 리포지토리.
Praefect 추적 데이터베이스에 기록이 아직 존재하지 않는 리포지토리.

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

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-untracked-repositories -older-than <duration>

지정된 시간이 지난 리포지토리만 고려됩니다.

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

결과를 STDOUT과 명령의 로그에.
오류를 STDERR에.

각 항목은 마지막에 줄 바꿈이 있는 완전한 JSON 문자열입니다 (변경 가능: -delimiter 플래그 사용). 예:

sudo -u git -- /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"}

단일 리포지토리를 추적 데이터베이스에 수동으로 추가

알려진 문제로 인해, Praefect에 의해 생성된 복제 경로(@cluster)로 리포지토리를 Praefect 추적 데이터베이스에 추가할 수 없습니다. 이러한 리포지토리는 GitLab에서 사용되는 리포지토리 경로와 연결되어 있지 않으며 접근할 수 없습니다.

track-repository Praefect 서브 커맨드는 디스크에 있는 리포지토리를 Praefect 추적 데이터베이스에 추가하여 추적되도록 합니다.

sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml track-repository -virtual-storage <virtual-storage> -authoritative-storage <storage-name> -relative-path <repository> -replica-path <disk_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가 기본(primary)으로 간주했으면 하는 스토리지입니다. 저장소별 복제 전략이 설정되어 있을 경우 필수입니다.
-replicate-immediately는 명령이 리포지토리를 즉시 2차 저장소로 복제하도록 합니다. 그렇지 않으면 복제 작업이 데이터베이스에 대한 실행으로 예약되고 Praefect 백그라운드 프로세스에 의해 처리됩니다.

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

결과를 STDOUT과 명령의 로그에.
오류를 STDERR에.

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

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

수동으로 여러 리포지토리를 추적 데이터베이스에 추가하기

GitLab 15.4에서 도입됨.

알려진 문제로 인해, Praefect에서 생성된 복제 경로(@cluster)를 사용하여 리포지토리를 Praefect 추적 데이터베이스에 추가할 수 없습니다.

이 리포지토리는 GitLab에서 사용하는 리포지토리 경로와 관련이 없으며 접근할 수 없습니다.

API를 사용하는 이주는 리포지토리를 자동으로 Praefect 추적 데이터베이스에 추가합니다.

대신 기존 인프라에서 리포지토리를 수동으로 복사하는 경우, track-repositories Praefect 서브 커맨드를 사용할 수 있습니다.

이 서브 커맨드는 대량의 디스크 상의 리포지토리를 Praefect 추적 데이터베이스에 추가합니다.

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

# 소스 설치
sudo -u git -- /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 -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-storages -virtual-storage <virtual_storage_name>

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

결과를 STDOUT와 명령의 로그에 기록합니다.
오류는 STDERR에 기록합니다.

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

Gitaly 클러스터에서 Gitaly 노드 관리

새 Gitaly 노드 추가

사용자 정의 복제 계수

기본 복제 계수

기존 Gitaly 노드 교체

동일한 이름의 노드로

다른 이름의 노드로

복제 계수 설정됨

기본 노드 실패

사용 불가능한 저장소

데이터 손실 확인

사용 가능한 리포지토리의 사용 불가능한 복제본

리포지토리 체크섬 확인

데이터 손실 수용

쓰기 활성화 또는 데이터 손실 수용

데이터 복구

리포지토리 수동 제거

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

추적되지 않은 리포지토리 목록

단일 리포지토리를 추적 데이터베이스에 수동으로 추가

수동으로 여러 리포지토리를 추적 데이터베이스에 추가하기

가상 저장소 세부정보 목록

도움말

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

도움받기