Gitaly Cluster (Praefect)는 프라이머리 노드 장애와 사용할 수 없는 리포지터리에서 복구할 수 있습니다. Gitaly Cluster (Praefect)는 데이터 복구를 수행할 수 있고 Praefect 추적 데이터베이스 도구를 갖추고 있습니다.

Gitaly Cluster (Praefect)의 Gitaly 노드 관리#

Gitaly Cluster (Praefect)에서 Gitaly 노드를 추가하고 교체할 수 있습니다.

새 Gitaly 노드 추가#

새 Gitaly 노드를 추가하는 방법은 다음과 같습니다.

1. 문서에 따라 새 Gitaly 노드를 설치합니다.

2. Praefect 구성의 praefect['virtual_storages'] 아래에 새 노드를 추가합니다.

3. 다음 명령을 실행해 Praefect를 재구성하고 다시 시작합니다.

   gitlab-ctl reconfigure
   gitlab-ctl restart praefect
   

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

사용자 정의 복제 계수#

사용자 정의 복제 계수가 설정되어 있으면 Praefect는 기존 리포지터리를 새 Gitaly 노드로 자동 복제하지 않습니다. set-replication-factor Praefect 명령으로 각 리포지터리의 복제 계수를 설정해야 합니다. 새 리포지터리는 복제 계수에 따라 복제됩니다.

기본 복제 계수#

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

기존 Gitaly 노드 교체#

기존 Gitaly 노드는 같은 이름 또는 다른 이름을 가진 새 노드로 교체할 수 있습니다.

프라이머리 노드 교체#

Gitaly Cluster (Praefect)는 리포지터리마다 프라이머리를 따로 선출합니다. 일부 리포지터리의 프라이머리인 노드를 제거하면 결과는 최신 복제본이 남아 있는지에 따라 달라집니다.

남아 있는 정상 노드에 최신 복제본이 있으면 리포지터리는 계속 사용할 수 있습니다. 읽기는 최신 복제본에서 제공되고, Praefect는 프라이머리가 필요한 다음 요청에서 유효한 후보 중에서 새 프라이머리를 선출합니다. 사용자는 영향을 받지 않습니다.

최신 복제본이 남아 있지 않으면(제거한 노드가 마지막 최신 복사본을 보유한 경우) 리포지터리를 사용할 수 없게 됩니다. Praefect는 오래된 복사본을 제공하는 대신 읽기에 404를 반환합니다. 다음 중 하나가 최신 복사본을 복원할 때까지 리포지터리는 사용할 수 없는 상태로 유지됩니다.

• 노드를 같은 이름으로 다시 투입해 재복제합니다.
• 리포지터리의 데이터를 담고 있는 교체 노드를 다른 이름으로 사용할 수 있게 만듭니다.

사용할 수 없는 리포지터리에는 선출할 유효한 프라이머리 후보가 없으므로 읽기로는 복구할 수 없습니다. 요청을 라우팅할 곳이 없기 때문입니다. 다음 쓰기는 사용 가능한 복제본 중 가장 나은 것(미복제 변경 사항이 가장 적은 복제본)을 승격해 프라이머리를 다시 설정하며, 이때 제거한 노드에만 있던 쓰기에 대해 데이터 손실이 발생할 수 있습니다. 이 상황을 완전히 피하려면 노드를 제거하기 전에 그 노드의 모든 리포지터리가 남아 있는 정상 노드에 최신 복사본을 갖도록 합니다.

Gitaly Cluster (Praefect)는 프라이머리 재선출을 수동으로 트리거하는 명령을 제공하지 않습니다. 가장 가까운 옵션은 accept-dataloss 하위 명령으로, 지정한 스토리지를 특정 상대 경로의 프라이머리로 설정하고 이전 프라이머리 대신 그 스토리지에서 복제를 시작합니다.

노드 제거 준비#

제거할 노드가 보유한 모든 리포지터리가 다른 정상 노드에 최신 복사본을 갖도록, 노드를 제거하기 전에 다음을 수행합니다.

1. 복제 계수가 중복성을 허용하는지 확인합니다.
   • 복제 계수가 설정되어 있다면 1보다 커야 합니다. 복제 계수가 1이면 노드를 제거할 때 데이터 손실이 발생합니다.
   • 복제 계수가 설정되어 있지 않다면 리포지터리가 가상 스토리지의 모든 노드로 복제되므로, 이미 다른 곳에 복사본이 있습니다.
2. 풀 리포지터리가 업스트림 리포지터리와 포크와 같은 노드로 복제되는지 확인합니다. 풀 리포지터리는 복제에서 다른 리포지터리와 동일하게 취급되지만, 오래된 클러스터에는 풀 리포지터리가 그것에 의존하는 리포지터리와 같은 노드에 없는 경우가 있습니다.
3. dataloss 하위 명령으로 영향을 받는 각 리포지터리가 유지할 노드에 최신 상태의 할당된 복제본을 갖고 있는지 확인합니다.
4. 노드를 제거하는 동안 클러스터가 새 쓰기를 처리하지 않도록 GitLab 인스턴스를 maintenance mode로 전환합니다.

같은 이름 사용#

교체 노드에 같은 이름을 사용하려면 리포지터리 검증기로 스토리지를 스캔해 남아 있는 메타데이터 레코드를 제거합니다. 교체한 스토리지의 검증을 수동으로 우선 처리하면 이 과정을 더 빠르게 진행할 수 있습니다.

다른 이름 사용#

교체 노드에 다른 이름을 사용하면, 새 노드에 리포지터리를 올리는 방법은 복제 계수 구성에 따라 달라집니다.

사용자 정의 복제 계수가 설정되어 있으면 기존 리포지터리는 새로 추가한 노드로 자동 복제되지 않습니다. 다음 방법 중 하나로 새 노드를 채웁니다.

• 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 노드 이름으로 갱신됩니다.

• repository_assignments 테이블을 갱신해 같은 복제 계수로 재할당합니다. 이 방법은 복사본을 추가하지 않고 기존 스토리지를 새 스토리지로 교체하며, 노드를 비우거나 소스 용량이 제한된 경우에 권장됩니다. 이 절의 뒷부분에 있는 재할당 단계를 참고합니다.

기본 복제 계수가 설정되어 있으면 Praefect는 계수를 유지하기 위해 새로 추가한 노드로 모든 리포지터리를 자동 복제합니다. 리포지터리별 작업은 필요하지 않습니다.

리포지터리가 새 노드로 성공적으로 복제되었음을 확인한 뒤에는 다음을 수행합니다.

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

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

   gitlab-ctl reconfigure
   gitlab-ctl restart praefect
   

이전 Gitaly 노드를 참조하는 데이터베이스 상태는 무시할 수 있습니다.

새 Gitaly 노드를 구성한 뒤 모든 리포지터리를 이전 스토리지에서 새 스토리지로 재할당하는 방법도 있습니다.

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

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

2. repository_assignments 테이블에서 이전 Gitaly 노드 이름(예: old-gitaly)을 새 Gitaly 노드 이름 (예: new-gitaly)으로 바꿉니다.

   UPDATE repository_assignments SET storage='new-gitaly' WHERE storage='old-gitaly';
   

이렇게 하면 시스템을 원하는 상태로 되돌리는 복제 job이 실행됩니다. 이전 노드를 제거하기 전에 dataloss 하위 명령으로 영향을 받는 각 리포지터리가 새 노드에 최신 상태의 할당된 복제본을 갖고 있는지 확인합니다.

프라이머리 노드 장애#

Gitaly Cluster (Praefect)는 정상인 보조를 새 프라이머리로 승격해 프라이머리 Gitaly 노드 장애에서 복구합니다. Gitaly Cluster (Praefect)의 동작은 다음과 같습니다.

• 리포지터리의 완전히 최신인 복사본을 가진 정상 보조를 새 프라이머리로 선출합니다.
• 완전히 최신인 보조가 없으면 프라이머리에서 미복제 쓰기가 가장 적은 보조를 새 프라이머리로 선출합니다.
• 정상 보조에 완전히 최신인 복사본이 없으면 리포지터리를 사용할 수 없게 됩니다. Praefect dataloss 하위 명령으로 이를 감지합니다.

사용할 수 없는 리포지터리#

리포지터리의 최신 복제본을 모두 사용할 수 없으면 그 리포지터리는 사용할 수 없는 상태입니다. 사용할 수 없는 리포지터리는 자동화 도구를 망가뜨릴 수 있는 오래된 데이터 제공을 막기 위해 Praefect를 통해 액세스할 수 없습니다.

데이터 손실 확인#

Praefect dataloss 하위 명령은 사용할 수 없는 리포지터리를 식별합니다. 이를 통해 잠재적인 데이터 손실과, 최신 복제본 복사본을 모두 사용할 수 없어 더 이상 액세스할 수 없는 리포지터리를 파악할 수 있습니다.

사용할 수 있는 파라미터는 다음과 같습니다.

• -virtual-storage는 확인할 가상 스토리지를 지정합니다. 관리자의 개입이 필요할 수 있으므로 기본 동작은 사용할 수 없는 리포지터리를 표시하는 것입니다.
• -partially-unavailable은 사용할 수 있지만 할당된 복사본 일부를 사용할 수 없는 리포지터리를 출력에 포함할지 지정합니다.

프라이머리가 오래된 리포지터리 또는 사용할 수 없는 리포지터리를 확인하려면 다음을 실행합니다.

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)이 출력됩니다.
• primary 필드는 리포지터리의 현재 프라이머리를 나열합니다. 리포지터리에 프라이머리가 없으면 이 필드에 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
  Outdated repositories:
    @hashed/3f/db/3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278.git:
      Primary: gitaly-1
      In-Sync Storages:
        gitaly-1, assigned host
      Outdated Storages:
        gitaly-2 is behind by 3 changes or less, assigned host
        gitaly-3 is behind by 3 changes or less

-partially-unavailable 플래그를 설정하면, 할당된 모든 복제본이 완전히 최신이고 정상일 때 확인 메시지가 출력됩니다.

예를 들면 다음과 같습니다.

Virtual storage: default
  All repositories are fully available on all assigned storages!

리포지터리 체크섬 확인#

모든 Gitaly 노드에서 프로젝트 리포지터리의 체크섬을 확인하려면 기본 GitLab 노드에서 replicas Rake 태스크를 실행합니다.

데이터 손실 수락#

최신 복제본 중 하나를 다시 온라인 상태로 만들 수 없다면 데이터 손실을 수락해야 할 수 있습니다. 데이터 손실을 수락하면 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>

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

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는 다음을 수행합니다.

1. 선택한 리포지터리 복사본을 최신 버전으로 표시합니다.

2. 그 복사본을 할당된 다른 Gitaly 노드로 복제합니다.

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

데이터 복구#

Gitaly 노드가 어떤 이유로든 복제 job에 실패하면 영향을 받은 리포지터리의 오래된 버전을 호스팅하게 됩니다. Praefect는 자동 조정 도구를 제공합니다. 이 도구는 오래된 리포지터리를 조정해 다시 완전히 최신 상태로 만듭니다.

Praefect는 최신 상태가 아닌 리포지터리를 자동으로 조정합니다. 기본적으로 이 작업은 5분마다 수행됩니다. 정상 Gitaly 노드에 있는 오래된 리포지터리마다 Praefect는 다른 정상 Gitaly 노드에서 완전히 최신인 복제본을 무작위로 골라 복제 소스로 사용합니다. 복제 job은 대상 리포지터리에 대기 중인 다른 복제 job이 없을 때만 예약됩니다.

조정 빈도는 구성에서 변경할 수 있습니다. 값으로는 유효한 Go duration 값을 쓸 수 있습니다. 0보다 작은 값은 이 기능을 비활성화합니다.

예시는 다음과 같습니다.

praefect['configuration'] = {
   # ...
   reconciliation: {
      # ...
      scheduling_interval: '5m', # the default value
   },
}

praefect['configuration'] = {
   # ...
   reconciliation: {
      # ...
      scheduling_interval: '30s', # reconcile every 30 seconds
   },
}

praefect['configuration'] = {
   # ...
   reconciliation: {
      # ...
      scheduling_interval: '0', # disable the feature
   },
}

수동으로 리포지터리 제거#

remove-repository Praefect 하위 명령은 Gitaly Cluster (Praefect)에서 리포지터리를 제거하고, 해당 리포지터리와 관련된 다음 상태를 모두 제거합니다.

• 관련된 모든 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>는 제거할 리포지터리의 상대 경로로 바꿉니다.

• 디스크상 리포지터리를 제거하지 않고 Praefect 추적 데이터베이스 항목만 제거하려면 -db-only를 추가합니다. 고아 데이터베이스 항목을 제거할 때, 그리고 유효한 리포지터리를 실수로 지정했을 때 디스크상 리포지터리 데이터가 삭제되지 않도록 보호할 때 이 옵션을 사용합니다. 데이터베이스 항목을 실수로 삭제했다면 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
  

remove-repository를 실행한 뒤에도 리포지터리의 일부가 남아 있을 수 있습니다. 원인은 다음과 같습니다.

• 삭제 오류.
• 해당 리포지터리를 대상으로 진행 중인 RPC 호출.

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

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

이 절에서는 Praefect 추적 데이터베이스의 일반적인 유지 관리 작업을 설명합니다.

추적되지 않는 리포지터리 나열#

list-untracked-repositories Praefect 하위 명령은 다음 두 조건을 모두 만족하는 Gitaly Cluster (Praefect)의 리포지터리를 나열합니다.

• 적어도 하나의 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"}

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

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가 프라이머리로 취급할 스토리지입니다. 리포지터리별 복제를 복제 전략으로 설정한 경우 필수입니다.

• -replicate-immediately를 지정하면 명령이 리포지터리를 보조로 즉시 복제합니다. 지정하지 않으면 복제 job이 데이터베이스에서 실행 예약되고 Praefect 백그라운드 프로세스가 이를 가져갑니다.

이 명령의 출력은 다음과 같습니다.

• 결과는 STDOUT과 명령 로그로 출력됩니다.
• 오류는 STDERR로 출력됩니다.

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

• 리포지터리가 이미 Praefect 추적 데이터베이스에서 추적되고 있습니다.
• 리포지터리가 디스크에 존재하지 않습니다.

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

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

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

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

# Source install
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를 지정하면 명령이 리포지터리를 보조로 즉시 복제합니다. 지정하지 않으면 복제 job이 데이터베이스에서 실행 예약되고 Praefect 백그라운드 프로세스가 이를 가져갑니다.

가상 스토리지 세부 정보 나열#

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로 출력됩니다.