컨테이너 레지스트리 메타데이터 데이터베이스

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

GitLab 16.4에 도입, Self-Managed GitLab 인스턴스를 위한 베타 기능으로 추가됨.
GitLab 17.3에서 일반 사용 가능.

메타데이터 데이터베이스를 사용하면 온라인 가비지 수집 등 여러 가지 새로운 레지스트리 기능을 활성화할 수 있으며, 많은 레지스트리 작업의 효율성을 높일 수 있습니다. 레지스트리 메타데이터 데이터베이스 기능의 Self-Managed 릴리즈 작업은 에픽 5521에서 추적됩니다.

기본적으로 컨테이너 레지스트리는 컨테이너 이미지와 관련된 메타데이터를 영속화하기 위해 객체 저장소를 사용합니다. 여러 이미지에 걸친 데이터를 특히 효율적으로 액세스하는 데 제한을 둘 수 있는 메타데이터 저장 방식이지만, 태그 목록을 작성할 때와 같이 여러 이미지에 걸친 데이터의 효율적인 액세스가 어려워집니다. 이 데이터를 저장하기 위해 데이터베이스를 사용하면 온라인 가비지 수집과 같은 새로운 기능을 포함하여 많은 새로운 기능이 가능합니다. 이를 통해 오래된 데이터를 자동으로 제거하고 다운타임이 없습니다.

이 데이터베이스는 레지스트리에서 이미 사용 중인 객체 저장소와 함께 작동하지만, 객체 저장소를 대체하지는 않습니다. 메타데이터 데이터베이스로 마이그레이션한 후에도 여전히 객체 저장소 솔루션을 유지해야 합니다.

Helm Charts 설치의 경우 Helm Charts 설명서의 컨테이너 레지스트리 메타데이터 데이터베이스 관리를 참조하세요.

알려진 제한 사항

온라인 마이그레이션 지원 안 됨.
Geo Support가 확인되지 않음.
레지스트리 데이터베이스 마이그레이션은 버전 업그레이드 시 수동으로 실행되어야 함.
멀티 노드 Omnibus GitLab 환경에서 레지스트리 업그레이드 중에 제로 다운타임 보장 안 됨.

메타데이터 데이터베이스 기능 지원

기존 레지스트리를 메타데이터 데이터베이스로 마이그레이션하고 온라인 가비지 수집을 사용할 수 있습니다. 일부 데이터베이스 지원 기능은 GitLab.com에서만 활성화되어 있으며 레지스트리 데이터베이스의 자동 프로비저닝은 사용할 수 없습니다. 컨테이너 레지스트리 데이터베이스와 관련된 기능 상태에 대한 피드백 이슈의 기능 지원 테이블을 확인하세요 피드백 이슈.

리눅스 패키지 설치에서 메타데이터 데이터베이스 활성화

필수 구성 요소: - GitLab 17.3 이상. - PostgreSQL 데이터베이스 버전 12 이상. 레지스트리 노드에서 액세스할 수 있어야 함.

귀하의 상황에 맞는 지침에 따르세요: - 새로운 설치 또는 레지스트리 최초로 활성화. - 기존 컨테이너 이미지를 메타데이터 데이터베이스로 마이그레이션: - 일반 마이그레이션. 상대적으로 작은 레지스트리에 권장되며 다운 타임을 피할 필요가 없을 때만 권장됨. - 세 단계 마이그레이션. 큰 컨테이너 레지스트리에 권장됨.

시작하기 전에

데이터베이스를 활성화한 후에는 계속 사용해야 합니다. 데이터베이스는 이후에 비활성화하면 레지스트리가 활성 상태일 때 기록된 모든 이미지에 대한 레지스트리 가시성을 잃게 됩니다.
데이터 가져오기 단계가 완료된 후에는 언제든지 오프라인 가비지 수집을 실행해서는 안 됩니다. 해당 명령은 메타데이터 데이터베이스를 사용하는 레지스트리와 호환되지 않으며 데이터를 삭제합니다.
오프라인 가비지 수집을 자동화하지 않았는지 확인하세요.
레지스트리의 저장소를 줄일 수 있습니다 혹시 저장소를 빠르게 할 수 있습니다.
가능한 경우 컨테이너 레지스트리 데이터를 백업하세요.

새로운 설치

데이터베이스를 활성화하려면:

/etc/gitlab/gitlab.rb을 편집하고 데이터베이스 연결 세부 정보를 추가하되, 메타데이터 데이터베이스는 비활성화 상태로 시작하세요:

registry['database'] = {
  'enabled' => false,
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'database-user',
  'password' => 'database-password',
  'dbname' => 'database-name',
  'sslmode' => 'require', # 자세한 정보는 PostgreSQL 설명서를 참조하세요 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/cert.pem 경로',
  'sslkey' => '/private.key 경로',
  'sslrootcert' => '/ca.pem 경로'
}

파일을 저장하고 GitLab 재구성하세요.
스키마 마이그레이션 적용.

/etc/gitlab/gitlab.rb을 편집하여 enabled를 true로 설정하여 데이터베이스를 활성화하세요:

registry['database'] = {
  'enabled' => true,
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'database-user',
  'password' => 'database-password',
  'dbname' => 'database-name',
  'sslmode' => 'require', # 자세한 정보는 PostgreSQL 설명서를 참조하세요 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/cert.pem 경로',
  'sslkey' => '/private.key 경로',
  'sslrootcert' => '/ca.pem 경로'
}

파일을 저장하고 GitLab 재구성하세요.

기존 레지스트리

기존 컨테이너 레지스트리 데이터를 한 단계 또는 세 단계로 마이그레이션할 수 있습니다. 마이그레이션 소요 시간에 영향을 미치는 몇 가지 요소가 있습니다:

기존 레지스트리 데이터의 크기.
PostgresSQL 인스턴스의 사양.
실행 중인 레지스트리 인스턴스 수.
레지스트리, PostgresSQL 및 구성된 객체 저장소 간의 네트워크 지연.

참고: 해당 마이그레이션은 태그가 지정된 이미지만 대상으로 합니다. 태그가 지정되지 않거나 참조되지 않는 매니페스트 및 이러한 매니페스트에 단독으로 참조되는 레이어는 남겨집니다. 태그가 지정되지 않은 이미지는 GitLab UI 또는 API를 통해 볼 수 없었지만 “둥글게” 될 수 있으며 백엔드에 남게 됩니다. 새 레지스트리로의 마이그레이션이 이루어진 후, 기본값으로 언제든지 온라인 가비지 수집이 실행되며 24시간을 넘게 지속되는 쌓인 태그가 지정되지 않은 매니페스트 및 레이어가 기본적으로 삭제됩니다.

레지스트리 설치에 따라 하나 또는 세 단계 방법 중 하나를 선택하세요.

One-step migration

경고: 마이그레이션 중 레지스트리는 종료되거나 읽기 전용 모드로 유지되어야 합니다. 마이그레이션 중 레지스트리에 쓰지 않아도 되고 레지스트리에 상대적으로 적은 양의 데이터가 포함되어 있는 경우에만이 방법을 선택하십시오.

/etc/gitlab/gitlab.rb 파일에 database 섹션을 추가하되, 메타데이터 데이터베이스가 비활성화된 상태로 시작하십시오.

registry['database'] = {
  'enabled' => false, # 반드시 false여야 합니다!
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'registry-database-user',
  'password' => 'registry-database-password',
  'dbname' => 'registry-database-name'
  'sslmode' => 'require', # 추가 정보는 PostgreSQL 문서를 참조하십시오 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/path/to/cert.pem',
  'sslkey' => '/path/to/private.key',
  'sslrootcert' => '/path/to/ca.pem'
}

레지스트리가 읽기 전용 모드로 설정되어 있는지 확인하십시오.
/etc/gitlab/gitlab.rb를 편집하고 registry['storage'] 구성에 maintenance 섹션을 추가하십시오. 예를 들어, gs://my-company-container-registry 버킷을 사용하는 gcs를 백엔드로 하는 레지스트리의 경우 구성은 다음과 같을 수 있습니다.
```
## Object Storage - Container Registry
registry['storage'] = {
  'gcs' => {
    'bucket' => "my-company-container-registry",
    'chunksize' => 5242880
  },
  'maintenance' => {
    'readonly' => {
      'enabled' => true # 반드시 true여야 합니다.
    }
  }
}
```
파일을 저장하고 GitLab 재구성을 수행하십시오.
스키마 마이그레이션 적용을 아직 수행하지 않은 경우 수행하십시오.

다음 명령을 실행하십시오.

sudo gitlab-ctl registry-database import

명령이 성공적으로 완료되면, 레지스트리가 이제 완전히 가져옵니다. 이제 데이터베이스를 활성화하고 구성에서 읽기 전용 모드를 해제하고 레지스트리 서비스를 시작할 수 있습니다.

registry['database'] = {
  'enabled' => true, # 이제 활성화해야 합니다!
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'registry-database-user',
  'password' => 'registry-database-password',
  'dbname' => 'registry-database-name',
  'sslmode' => 'require', # 추가 정보는 PostgreSQL 문서를 참조하십시오 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/path/to/cert.pem',
  'sslkey' => '/path/to/private.key',
  'sslrootcert' => '/path/to/ca.pem'
}

## Object Storage - Container Registry
registry['storage'] = {
  'gcs' => {
    'bucket' => "my-company-container-registry",
    'chunksize' => 5242880
  },
  'maintenance' => {
    'readonly' => {
      'enabled' => false
    }
  }
}

파일을 저장하고 GitLab 재구성을 수행하십시오.

이제 메타데이터 데이터베이스를 모든 작업에 사용할 수 있습니다!

Three-step migration

기존 컨테이너 레지스트리 데이터를 마이그레이션하는 방법을 알아봅니다. 이 절차는 더 많은 데이터 또는 마이그레이션을 완료하는 동안 다운 타임을 최소화하려는 경우에 권장됩니다.

참고: 사용자들은 첫 번째 단계의 가져오기가 시간당 2에서 4TB를 완료했다고 보고했습니다. 보다 느린 속도로, 100TB 이상의 데이터가 포함된 레지스트리는 48시간보다 더 오래 걸릴 수 있습니다.

레포지토리 사전 가져오기 (첫 번째 단계)

크기가 큰 인스턴스의 경우, 이 명령은 레지스트리의 크기에 따라 몇 시간에서 며칠이 소요될 수 있습니다. 첫 단계가 완료되는 동안 정상적으로 레지스트리를 계속 사용할 수 있습니다.

경고: 마이그레이션을 다시 시작하는 것은 아직 불가능합니다, 따라서 마이그레이션을 완료할 수 있도록 작동시켜놓는 것이 중요합니다. 작업을 중지해야하는 경우,이 단계를 다시 시작해야합니다.

/etc/gitlab/gitlab.rb 파일에 database 섹션을 추가하되, 메타데이터 데이터베이스가 비활성화된 상태로 시작하십시오.

registry['database'] = {
  'enabled' => false, # 반드시 false여야 합니다!
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'registry-database-user',
  'password' => 'registry-database-password',
  'dbname' => 'registry-database-name'
  'sslmode' => 'require', # 추가 정보는 PostgreSQL 문서를 참조하십시오 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/path/to/cert.pem',
  'sslkey' => '/path/to/private.key',
  'sslrootcert' => '/path/to/ca.pem'
}

파일을 저장하고 GitLab 재구성을 수행하십시오.
스키마 마이그레이션 적용을 아직 수행하지 않은 경우 수행하십시오.
마이그레이션을 시작하려면 첫 번째 단계를 실행하십시오.
```
sudo gitlab-ctl registry-database import --step-one
```

참고: 가능한 한 빨리 다음 단계를 스케줄에 등록하도록 해야합니다 다운타임이 필요한 시간을 줄이기 위해서입니다. 가능한한 이후, 첫 번째 단계와 두 번째 단계 사이에 레지스트리에 신규 데이터를 작성하면 두 번째 단계를 실행하는 데 더 많은 시간이 소요됩니다.

모든 레포지토리 데이터 가져오기 (두 번째 단계)

이 단계에 따라 레지스트리는 종료되거나 읽기 전용 모드로 설정되어야 합니다. 두 번째 단계가 실행되는 동안 다운 타임에 충분한 시간을 제공하십시오.

레지스트리가 읽기 전용 모드로 설정되어 있는지 확인하십시오.
/etc/gitlab/gitlab.rb를 편집하고 registry['storage'] 구성에 maintenance 섹션을 추가하십시오. 예를 들어, gs://my-company-container-registry 버킷을 사용하는 gcs를 백엔드로 하는 레지스트리의 경우 구성은 다음과 같을 수 있습니다.
```
## Object Storage - Container Registry
registry['storage'] = {
  'gcs' => {
    'bucket' => "my-company-container-registry",
    'chunksize' => 5242880
  },
  'maintenance' => {
    'readonly' => {
      'enabled' => true # 반드시 true여야 합니다.
    }
  }
}
```
파일을 저장하고 GitLab 재구성을 수행하십시오.
마이그레이션의 두 번째 단계를 실행하십시오
```
sudo gitlab-ctl registry-database import --step-two
```

명령이 성공적으로 완료되면, 모든 이미지가 이제 완전히 가져와졌습니다. 이제 데이터베이스를 활성화하고 구성에서 읽기 전용 모드를 해제하고 레지스트리 서비스를 시작할 수 있습니다.

registry['database'] = {
  'enabled' => true, # 반드시 true여야 합니다!
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'registry-database-user',
  'password' => 'registry-database-password',
  'dbname' => 'registry-database-name',
  'sslmode' => 'require', # 추가 정보는 PostgreSQL 문서를 참조하십시오 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/path/to/cert.pem',
  'sslkey' => '/path/to/private.key',
  'sslrootcert' => '/path/to/ca.pem'
}

## Object Storage - Container Registry
registry['storage'] = {
  'gcs' => {
    'bucket' => "my-company-container-registry",
    'chunksize' => 5242880
  },
  'maintenance' => { # 이 섹션은 제거할 수 있습니다.
    'readonly' => {
      'enabled' => false
    }
  }
}

파일을 저장하고 GitLab 재구성을 수행하십시오.

이제 메타데이터 데이터베이스를 모든 작업에 사용할 수 있습니다!

나머지 데이터 가져오기 (세 번째 단계)

이제 레지스트리는 메타데이터에 완전히 데이터베이스를 사용하고 있지만, 아직 사용되지 않을 수 있는 레이어 blob에 대한 액세스 권한이 없습니다.

프로세스를 완료하려면 이주의 마지막 단계를 실행하세요.

sudo gitlab-ctl registry-database import --step-three

해당 명령을 성공적으로 실행한 후, 레지스트리는 이제 데이터베이스로 완전히 마이그레이션되었습니다!

마이그레이션 후

마이그레이션 후 스토리지 감소를 보려면 마이그레이션 후 약 48시간이 소요될 수 있습니다. 이것은 온라인 가비지 수집의 일반적이고 예상되는 부분으로, 이 지연으로 인해 온라인 가비지 수집이 이미지 푸시와 간섭되지 않습니다. 온라인 가비지 수집 진행 및 건강 상태를 모니터링하는 방법은 온라인 가비지 수집 모니터링 섹션을 확인하세요.

스키마 마이그레이션 관리

컨테이너 레지스트리 메타데이터 데이터베이스에 대한 스키마 마이그레이션을 실행하는 데 다음 명령어를 사용하세요. 레지스트리는 활성화되어 있어야 하며 구성 섹션에는 데이터베이스 섹션이 채워져 있어야 합니다.

스키마 마이그레이션 적용

레지스트리 데이터베이스 스키마 마이그레이션을 실행하세요.
```
sudo gitlab-ctl registry-database migrate up
```
레지스트리가 실행 중이라면 중지해야 합니다. 프로세스가 완료될 때까지 y를 입력하세요.

참고: migrate up 명령에는 마이그레이션을 어떻게 적용할지 제어하는 추가 플래그가 있습니다. 세부 정보는 sudo gitlab-ctl registry-database migrate up --help 명령을 실행하세요.

스키마 마이그레이션 취소

문제가 발생했을 경우 스키마 마이그레이션을 취소할 수 있지만, 이는 복구할 수 없는 작업입니다. 데이터베이스를 사용하는 동안 새 이미지를 푸시했다면 이후에는 더 이상 액세스할 수 없게 됩니다.

레지스트리 데이터베이스 스키마 마이그레이션을 취소하세요.
```
sudo gitlab-ctl registry-database migrate down
```

참고: migrate down 명령에는 추가 플래그가 있습니다. 자세한 내용은 sudo gitlab-ctl registry-database migrate down --help 명령을 실행하세요.

(이하 생략)

에러: `오프라인 가비지 수집이 더는 불가능합니다`

만약 레지스트리가 메타데이터 데이터베이스를 사용하고 오프라인 가비지 수집을 시도하면, 다음과 같은 오류 메시지로 레지스트리가 실패합니다.

ERRO[0000] this filesystem is managed by the metadata database, and offline garbage collection is no longer possible, if you are not using the database anymore, remove the file at the lock_path in this log message lock_path=/docker/registry/lockfiles/database-in-use

다음 중 하나를 해야 합니다:

오프라인 가비지 수집을 사용하지 않도록 합니다.
만약 더 이상 메타데이터 데이터베이스를 사용하지 않는다면, 오류 메시지에 표시된 lock_path에 있는 잠금 파일을 삭제합니다. 예를 들어, /docker/registry/lockfiles/database-in-use 파일을 제거합니다.

에러: `읽기 전용 트랜잭션에서 <명령문>을(를) 실행할 수 없습니다`

레지스트리에서 다음과 같은 오류 메시지로 스키마 마이그레이션을 적용하지 못할 수 있습니다.

err="ERROR: cannot execute CREATE TABLE in a read-only transaction (SQLSTATE 25006)"

또한, 레지스트리가 온라인 가비지 수집을 시도하면 다음과 같은 오류 메시지로 실패할 수 있습니다:

error="processing task: fetching next GC blob task: scanning GC blob task: ERROR: cannot execute SELECT FOR UPDATE in a read-only transaction (SQLSTATE 25006)"

default_transaction_read_only 및 transaction_read_only의 값 확인을 통해 읽기 전용 트랜잭션이 비활성화되어 있는지 검증해야 합니다.

예를 들어:

# SHOW default_transaction_read_only;
 default_transaction_read_only
 -------------------------------
 on
(1 row)

# SHOW transaction_read_only;
 transaction_read_only
 -----------------------
 on
(1 row)

이 값 중 하나라도 on으로 설정되어 있다면, 다음을 수행해야 합니다:

postgresql.conf를 편집하고 다음 값을 설정합니다:
```
default_transaction_read_only=off
```
이러한 설정을 적용하려면 Postgres 서버를 재시작합니다.
적용 가능하다면 스키마 마이그레이션을 적용을 다시 시도합니다.
레지스트리를 다시 시작합니다. sudo gitlab-ctl restart registry.

에러: `태그 테이블에 항목이 있는 상태에서 모든 저장소를 가져올 수 없음`

기존 레지스트리를 이전하기 위해 시도하고 다음과 같은 오류를 만난다면:

ERRO[0000] cannot import all repositories while the tags table has entries, you must truncate the table manually before retrying,
see https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html#troubleshooting
common_blobs=true dry_run=false error="tags table is not empty"

이 오류는 레지스트리 데이터베이스의 tags 테이블에 기존 항목이 있는 경우 발생하며, 다음과 같은 경우에 발생할 수 있습니다:

원스텝 마이그레이션을 시도하고 오류가 발생한 경우
쓰리스텝 마이그레이션 프로세스를 시도하고 오류가 발생한 경우
마이그레이션 프로세스를 의도적으로 중지한 경우
위의 어떤 상황에서든 마이그레이션을 다시 시도한 경우
잘못된 구성 파일에 대해 마이그레이션을 실행한 경우

이 문제를 해결하려면 tags 테이블의 기존 항목을 삭제해야 합니다.

다음을 수행합니다:

/etc/gitlab/gitlab.rb를 편집하여 메타데이터 데이터베이스가 비활성화되었는지 확인합니다:

registry['database'] = {
  'enabled' => false,
  'host' => 'localhost',
  'port' => 5432,
  'user' => 'registry-database-user',
  'password' => 'registry-database-password',
  'dbname' => 'registry-database-name',
  'sslmode' => 'require', # 추가 정보는 PostgreSQL documentation을 참조하세요 https://www.postgresql.org/docs/current/libpq-ssl.html.
  'sslcert' => '/cert.pem에 대한/경로',
  'sslkey' => '/private.key에 대한/경로',
  'sslrootcert' => '/ca.pem에 대한/경로'
}

PostgreSQL 클라이언트를 사용하여 레지스트리 데이터베이스에 연결합니다.
모든 기존 항목을 제거하려면 tags 테이블을 잘라내십시오:
```
TRUNCATE TABLE tags RESTART IDENTITY CASCADE;
```
tags 테이블을 잘라낸 후, 마이그레이션 프로세스를 다시 실행합니다.

에러: `database-in-use lockfile exists`

기존 레지스트리를 이전하기 위해 시도하고 다음과 같은 오류를 만난다면:

|  [0s] step two: import tags failed to import metadata: importing all repositories: 1 error occurred:
    * could not restore lockfiles: database-in-use lockfile exists

이 오류는 이전에 레지스트리를 가져오고 모든 저장소 데이터(스텝 2) 가져오기를 완료했으며, database-in-use가 레지스트리 파일 시스템에 존재하는 경우 발생합니다. 이 문제를 만난 경우 임포터를 다시 실행하면 안 됩니다.

만약 계속 진행해야 한다면, 파일 시스템에서 database-in-use 잠금 파일을 수동으로 삭제해야 합니다. 파일은 /path/to/rootdirectory/docker/registry/lockfiles/database-in-use에 위치합니다.

메타데이터 관리 문제로 인해 레지스트리 시작 실패

레지스트리는 다음 오류 중 하나로 시작에 실패할 수 있습니다:

에러: `registry filesystem metadata in use, please import data before enabling the database`

이 오류는 데이터베이스가 구성에서 활성화되었지만 아직 메타데이터 데이터베이스로 기존 데이터를 마이그레이션하지 않았을 때 발생합니다.

에러: `registry metadata database in use, please enable the database`

이 오류는 기존 데이터를 메타데이터 데이터베이스로 마이그레이션을 완료했지만 아직 구성에서 데이터베이스를 활성화하지 않았을 때 발생합니다.

잠금 파일 확인 또는 생성 문제

다음과 같은 오류를 만난다면:

파일 시스템 메타데이터가 잠겨 있는지 확인할 수 없음
데이터베이스 메타데이터가 잠겨 있는지 확인할 수 없음
파일 시스템을 데이터베이스 전용 사용으로 표시하는 데 실패했습니다
파일 시스템만 사용토록 표시하는 데 실패했습니다

레지스트리는 구성된 rootdirectory에 액세스할 수 없습니다. 이 오류는 이전에 작동하던 레지스트리에서 발생할 확률이 낮습니다. 잘못된 구성 문제에 대한 오류 로그를 검토하십시오.

컨테이너 레지스트리 메타데이터 데이터베이스

알려진 제한 사항

메타데이터 데이터베이스 기능 지원

리눅스 패키지 설치에서 메타데이터 데이터베이스 활성화

시작하기 전에

새로운 설치

기존 레지스트리

One-step migration

Three-step migration

레포지토리 사전 가져오기 (첫 번째 단계)

모든 레포지토리 데이터 가져오기 (두 번째 단계)

나머지 데이터 가져오기 (세 번째 단계)

마이그레이션 후

스키마 마이그레이션 관리

스키마 마이그레이션 적용

스키마 마이그레이션 취소

에러: `오프라인 가비지 수집이 더는 불가능합니다`

에러: `읽기 전용 트랜잭션에서 <명령문>을(를) 실행할 수 없습니다`

에러: `태그 테이블에 항목이 있는 상태에서 모든 저장소를 가져올 수 없음`

에러: `database-in-use lockfile exists`

메타데이터 관리 문제로 인해 레지스트리 시작 실패

에러: `registry filesystem metadata in use, please import data before enabling the database`

에러: `registry metadata database in use, please enable the database`

잠금 파일 확인 또는 생성 문제

도움말

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

도움받기

컨테이너 레지스트리 메타데이터 데이터베이스

알려진 제한 사항

메타데이터 데이터베이스 기능 지원

리눅스 패키지 설치에서 메타데이터 데이터베이스 활성화

시작하기 전에

새로운 설치

기존 레지스트리

One-step migration

Three-step migration

레포지토리 사전 가져오기 (첫 번째 단계)

모든 레포지토리 데이터 가져오기 (두 번째 단계)

나머지 데이터 가져오기 (세 번째 단계)

마이그레이션 후

스키마 마이그레이션 관리

스키마 마이그레이션 적용

스키마 마이그레이션 취소

에러: 오프라인 가비지 수집이 더는 불가능합니다

에러: 읽기 전용 트랜잭션에서 <명령문>을(를) 실행할 수 없습니다

에러: 태그 테이블에 항목이 있는 상태에서 모든 저장소를 가져올 수 없음

에러: database-in-use lockfile exists

메타데이터 관리 문제로 인해 레지스트리 시작 실패

에러: registry filesystem metadata in use, please import data before enabling the database

에러: registry metadata database in use, please enable the database

잠금 파일 확인 또는 생성 문제

도움말

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

도움받기

에러: `오프라인 가비지 수집이 더는 불가능합니다`

에러: `읽기 전용 트랜잭션에서 <명령문>을(를) 실행할 수 없습니다`

에러: `태그 테이블에 항목이 있는 상태에서 모든 저장소를 가져올 수 없음`

에러: `database-in-use lockfile exists`

에러: `registry filesystem metadata in use, please import data before enabling the database`

에러: `registry metadata database in use, please enable the database`