InfoGrab DocsInfoGrab Docs

컨테이너 레지스트리 메타데이터 데이터베이스 문제 해결

요약

레지스트리를 업데이트했는데 적용되지 않은 스키마 마이그레이션이 남아 있으면, 레지스트리가 다음 오류 메시지와 함께 시작에 실패합니다. 이 문제를 해결하려면 데이터베이스 마이그레이션 적용 절차를 따릅니다. 18.3 이전 버전에서는 버전을 업그레이드할 때마다 데이터베이스 마이그레이션을 수동으로 적용해야 합니다.

오류: there are pending database migrations#

레지스트리를 업데이트했는데 적용되지 않은 스키마 마이그레이션이 남아 있으면, 레지스트리가 다음 오류 메시지와 함께 시작에 실패합니다.

FATA[0000] configuring application: there are pending database migrations, use the 'registry database migrate' CLI command to check and apply them

이 문제를 해결하려면 데이터베이스 마이그레이션 적용 절차를 따릅니다.

18.3 이전 버전에서는 버전을 업그레이드할 때마다 데이터베이스 마이그레이션을 수동으로 적용해야 합니다.

오류: offline garbage collection is no longer possible#

레지스트리가 메타데이터 데이터베이스를 사용하는 상태에서 오프라인 가비지 컬렉션을 실행하려고 하면, 레지스트리가 다음 오류 메시지와 함께 실패합니다.

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 파일을 삭제합니다.

오류: cannot execute in a read-only transaction#

레지스트리가 다음 오류 메시지와 함께 데이터베이스 마이그레이션 적용에 실패할 수 있습니다.

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)"

PostgreSQL 콘솔에서 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으로 설정되어 있으면 비활성화해야 합니다.

  1. postgresql.conf를 편집해 다음 값을 설정합니다.

    default_transaction_read_only=off

  2. 이 설정을 적용하려면 Postgres 서버를 재시작합니다.

  3. 해당한다면 데이터베이스 마이그레이션 적용을 다시 시도합니다.

  4. sudo gitlab-ctl restart registry로 레지스트리를 재시작합니다.

오류: cannot import all repositories while the tags table has entries#

기존 레지스트리 메타데이터를 가져오려 할 때 다음 오류가 발생할 수 있습니다.

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/administration/packages/container_registry_metadata_database/#troubleshooting
common_blobs=true dry_run=false error="tags table is not empty"

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

  • 1단계 가져오기를 시도했다가 오류가 발생한 경우
  • 3단계 가져오기 절차를 시도했다가 오류가 발생한 경우
  • 가져오기 절차를 의도적으로 중단한 경우
  • 위 상황 이후에 가져오기를 다시 실행한 경우
  • 잘못된 구성 파일로 가져오기를 실행한 경우
Warning

tags 테이블은 완료되기 전에 실패한 가져오기를 다시 시도할 때만 비웁니다. 가져오기가 성공한 뒤에는 메타데이터 데이터베이스가 레지스트리 메타데이터의 유일한 사본입니다. 이전이 끝난 레지스트리나 프로덕션 레지스트리에서 테이블을 비우면 태그 메타데이터가 영구히 삭제됩니다. 삭제된 메타데이터는 오브젝트 스토리지에서 다시 가져오는 방식으로 복구할 수 없습니다. 이미 메타데이터 데이터베이스로 트래픽을 처리하는 레지스트리에서는 이 절차를 절대 실행하지 않습니다.

이 문제를 해결하려면 tags 테이블의 기존 항목을 삭제해야 합니다. PostgreSQL 인스턴스에서 테이블을 직접 비워야 합니다.

  1. /etc/gitlab/gitlab.rb를 편집해 메타데이터 데이터베이스가 비활성화되어 있는지 확인합니다.

    registry['database'] = {
  'enabled' => false,
}

  2. PostgreSQL 클라이언트로 레지스트리 데이터베이스에 연결합니다.

  3. 기존 항목을 모두 제거하도록 tags 테이블을 비웁니다.

    TRUNCATE TABLE tags RESTART IDENTITY CASCADE;

  4. 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에 있습니다.

오류: pre importing all repositories: AccessDenied:#

AWS S3를 스토리지 백엔드로 사용하면서 기존 레지스트리를 가져올 때 AccessDenied 오류가 발생할 수 있습니다.

/opt/gitlab/embedded/bin/registry database import --step-one /var/opt/gitlab/registry/config.yml
  [0s] step one: import manifests
  [0s] step one: import manifests failed to import metadata: pre importing all repositories: AccessDenied: Access Denied

명령을 실행하는 사용자가 올바른 권한 스코프를 가지고 있는지 확인합니다.

오류: convert field 8 failed: invalid hex format#

기존 레지스트리 데이터를 메타데이터 데이터베이스로 가져올 때, 매니페스트를 읽는 도중 가져오기가 실패할 수 있습니다.

ERRO[0000] pre importing tagged manifests common_blobs=false dry_run=false error="finding tagged manifests in database: scanning manifest: convert field 8 failed: invalid hex format"

이 오류는 PostgreSQL 서버나 레지스트리의 데이터베이스 역할에 bytea_output = escape가 설정되어 있을 때 발생합니다. 레지스트리는 일부 바이너리 칼럼을 텍스트로 읽으며 기본 16진수 형식을 전제합니다.

레지스트리가 사용하는 것과 같은 연결 경로에서 값을 확인합니다. 예를 들어 PgBouncer를 사용한다면 PgBouncer를 통해 확인합니다.

SELECT current_setting('bytea_output');

오류를 해결하려면 레지스트리 데이터베이스의 출력 형식을 hex로 설정합니다.

ALTER DATABASE <registry_database> SET bytea_output = 'hex';

그런 다음 레지스트리를 재시작하거나 새 연결을 열어 다시 연결하고 가져오기를 재시도합니다. 역할 수준 설정이 데이터베이스 기본값보다 우선하므로, 역할에 bytea_output이 설정되어 있다면 그쪽도 함께 설정합니다.

ALTER ROLE <registry_user> SET bytea_output = 'hex';

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

레지스트리가 다음 오류 중 하나와 함께 시작에 실패할 수 있습니다.

오류: registry filesystem metadata in use, please import data before enabling the database#

이 오류는 구성에서 registry['database'] = { 'enabled' => true}로 데이터베이스를 활성화했지만 아직 기존 레지스트리 메타데이터를 가져오지 않았을 때 발생합니다.

오류: registry metadata database in use, please enable the database#

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

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

다음 오류 중 하나가 발생하는 경우가 있습니다.

  • could not check if filesystem metadata is locked
  • could not check if database metadata is locked
  • failed to mark filesystem for database only usage
  • failed to mark filesystem only usage

이는 레지스트리가 구성된 rootdirectory에 접근할 수 없다는 뜻입니다. 이전에 레지스트리가 정상 동작했다면 이 오류는 거의 발생하지 않습니다. 오류 로그에서 잘못된 구성이 없는지 확인합니다.

태그 삭제 후 스토리지 사용량이 감소하지 않음#

기본적으로 온라인 가비지 컬렉터는 참조되지 않는 레이어를 해당 레이어와 연결된 모든 태그가 삭제된 시점으로부터 48시간이 지나야 삭제하기 시작합니다. 레이어는 이미지 및 태그와 연결되기 전에 레지스트리로 푸시되므로, 이 지연은 가비지 컬렉터가 오래 걸리거나 중단된 이미지 푸시를 방해하지 않도록 합니다.

Note

온라인 가비지 컬렉션은 참조되지 않는 오브젝트를 스토리지에서 삭제합니다. 그 공간을 언제 회수할지는 오브젝트 스토리지 공급자가 결정합니다. 오브젝트 버전 관리나 보존 정책이 삭제된 오브젝트를 무기한 보관하면 공급자는 공간을 회수하지 않습니다. 공간을 회수하려면 현재 버전이 아닌 오브젝트를 만료시키는 수명 주기 규칙을 구성합니다.

오류: permission denied for schema public (SQLSTATE 42501)#

레지스트리 마이그레이션이나 GitLab 업그레이드 중에 다음 오류 중 하나가 발생할 수 있습니다.

  • ERROR: permission denied for schema public (SQLSTATE 42501)
  • ERROR: relation "public.blobs" does not exist (SQLSTATE 42P01)

이러한 오류는 보안상의 이유로 public 스키마의 기본 CREATE 권한을 제거한 PostgreSQL 15 이상의 변경 때문에 발생합니다. PostgreSQL 15 이상에서는 기본적으로 데이터베이스 소유자만 public 스키마에 오브젝트를 생성할 수 있습니다.

오류를 해결하려면 다음 명령을 실행해 레지스트리 사용자에게 레지스트리 데이터베이스의 소유자 권한을 부여합니다.

ALTER DATABASE <registry_database_name> OWNER TO <registry_user>;

이렇게 하면 레지스트리 사용자가 테이블을 생성하고 마이그레이션을 정상적으로 실행하는 데 필요한 권한을 갖습니다.

오류: database-in-use and filesystem-in-use lockfiles present#

이 오류는 구성된 레지스트리 스토리지에 filesystem-in-use와 database-in-use 잠금 파일이 모두 존재할 때 발생하며, 레지스트리 상태가 모호하다는 뜻입니다.

이 오류를 해결하려면 레지스트리가 메타데이터 데이터베이스를 사용해야 하는지 기존 메타데이터 스토리지를 사용해야 하는지 판단해야 합니다.

다음에 해당한다면 레지스트리가 메타데이터 데이터베이스를 사용해야 할 가능성이 큽니다.

  • 이전에 가져오기 절차 중 하나를 수행한 경우
  • 레지스트리 구성에 레지스트리가 활성화되어 있다고 표시된 경우

/etc/gitlab/gitlab.rb 파일에서 레지스트리가 활성화되어 있는지 확인합니다.

registry['database'] = {
  'enabled' => true,
}

레지스트리가 데이터베이스를 사용해야 한다고 확인했다면, 구성된 레지스트리 스토리지의 /docker/registry/lockfiles/filesystem-in-use에 있는 filesystem-in-use 잠금 파일을 삭제합니다.

위 상황에 해당하지 않고 레지스트리가 기존 메타데이터 스토리지를 사용해야 한다면, /docker/registry/lockfiles/database-in-use에 있는 database-in-use 잠금 파일을 삭제합니다.

GitLab 18.8과 18.9에서는 REGISTRY_FF_ENFORCE_LOCKFILES 컨테이너 레지스트리 기능 플래그를 false로 설정해 잠금 파일 검사를 비활성화할 수 있습니다. 이렇게 하면 검사가 비활성화되지만, 이 오류는 레지스트리 데이터의 무결성을 지키기 위한 것이므로 어떤 메타데이터 스토리지를 사용하는지 먼저 확인하는 편이 좋습니다. REGISTRY_FF_ENFORCE_LOCKFILES 기능 플래그는 GitLab 18.10에서 제거되었습니다. 자세한 내용은 컨테이너 레지스트리 기능 플래그를 참고합니다.

컨테이너 레지스트리 메타데이터 데이터베이스 문제 해결

GitLab v19.5
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

레지스트리를 업데이트했는데 적용되지 않은 스키마 마이그레이션이 남아 있으면, 레지스트리가 다음 오류 메시지와 함께 시작에 실패합니다. 이 문제를 해결하려면 데이터베이스 마이그레이션 적용 절차를 따릅니다. 18.3 이전 버전에서는 버전을 업그레이드할 때마다 데이터베이스 마이그레이션을 수동으로 적용해야 합니다.

오류: there are pending database migrations#

레지스트리를 업데이트했는데 적용되지 않은 스키마 마이그레이션이 남아 있으면, 레지스트리가 다음 오류 메시지와 함께 시작에 실패합니다.

FATA[0000] configuring application: there are pending database migrations, use the 'registry database migrate' CLI command to check and apply them

이 문제를 해결하려면 데이터베이스 마이그레이션 적용 절차를 따릅니다.

18.3 이전 버전에서는 버전을 업그레이드할 때마다 데이터베이스 마이그레이션을 수동으로 적용해야 합니다.

오류: offline garbage collection is no longer possible#

레지스트리가 메타데이터 데이터베이스를 사용하는 상태에서 오프라인 가비지 컬렉션을 실행하려고 하면, 레지스트리가 다음 오류 메시지와 함께 실패합니다.

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 파일을 삭제합니다.

오류: cannot execute in a read-only transaction#

레지스트리가 다음 오류 메시지와 함께 데이터베이스 마이그레이션 적용에 실패할 수 있습니다.

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)"

PostgreSQL 콘솔에서 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으로 설정되어 있으면 비활성화해야 합니다.

  1. postgresql.conf를 편집해 다음 값을 설정합니다.

    default_transaction_read_only=off

  2. 이 설정을 적용하려면 Postgres 서버를 재시작합니다.

  3. 해당한다면 데이터베이스 마이그레이션 적용을 다시 시도합니다.

  4. sudo gitlab-ctl restart registry로 레지스트리를 재시작합니다.

오류: cannot import all repositories while the tags table has entries#

기존 레지스트리 메타데이터를 가져오려 할 때 다음 오류가 발생할 수 있습니다.

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/administration/packages/container_registry_metadata_database/#troubleshooting
common_blobs=true dry_run=false error="tags table is not empty"

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

  • 1단계 가져오기를 시도했다가 오류가 발생한 경우
  • 3단계 가져오기 절차를 시도했다가 오류가 발생한 경우
  • 가져오기 절차를 의도적으로 중단한 경우
  • 위 상황 이후에 가져오기를 다시 실행한 경우
  • 잘못된 구성 파일로 가져오기를 실행한 경우
Warning

tags 테이블은 완료되기 전에 실패한 가져오기를 다시 시도할 때만 비웁니다. 가져오기가 성공한 뒤에는 메타데이터 데이터베이스가 레지스트리 메타데이터의 유일한 사본입니다. 이전이 끝난 레지스트리나 프로덕션 레지스트리에서 테이블을 비우면 태그 메타데이터가 영구히 삭제됩니다. 삭제된 메타데이터는 오브젝트 스토리지에서 다시 가져오는 방식으로 복구할 수 없습니다. 이미 메타데이터 데이터베이스로 트래픽을 처리하는 레지스트리에서는 이 절차를 절대 실행하지 않습니다.

이 문제를 해결하려면 tags 테이블의 기존 항목을 삭제해야 합니다. PostgreSQL 인스턴스에서 테이블을 직접 비워야 합니다.

  1. /etc/gitlab/gitlab.rb를 편집해 메타데이터 데이터베이스가 비활성화되어 있는지 확인합니다.

    registry['database'] = {
  'enabled' => false,
}

  2. PostgreSQL 클라이언트로 레지스트리 데이터베이스에 연결합니다.

  3. 기존 항목을 모두 제거하도록 tags 테이블을 비웁니다.

    TRUNCATE TABLE tags RESTART IDENTITY CASCADE;

  4. 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에 있습니다.

오류: pre importing all repositories: AccessDenied:#

AWS S3를 스토리지 백엔드로 사용하면서 기존 레지스트리를 가져올 때 AccessDenied 오류가 발생할 수 있습니다.

/opt/gitlab/embedded/bin/registry database import --step-one /var/opt/gitlab/registry/config.yml
  [0s] step one: import manifests
  [0s] step one: import manifests failed to import metadata: pre importing all repositories: AccessDenied: Access Denied

명령을 실행하는 사용자가 올바른 권한 스코프를 가지고 있는지 확인합니다.

오류: convert field 8 failed: invalid hex format#

기존 레지스트리 데이터를 메타데이터 데이터베이스로 가져올 때, 매니페스트를 읽는 도중 가져오기가 실패할 수 있습니다.

ERRO[0000] pre importing tagged manifests common_blobs=false dry_run=false error="finding tagged manifests in database: scanning manifest: convert field 8 failed: invalid hex format"

이 오류는 PostgreSQL 서버나 레지스트리의 데이터베이스 역할에 bytea_output = escape가 설정되어 있을 때 발생합니다. 레지스트리는 일부 바이너리 칼럼을 텍스트로 읽으며 기본 16진수 형식을 전제합니다.

레지스트리가 사용하는 것과 같은 연결 경로에서 값을 확인합니다. 예를 들어 PgBouncer를 사용한다면 PgBouncer를 통해 확인합니다.

SELECT current_setting('bytea_output');

오류를 해결하려면 레지스트리 데이터베이스의 출력 형식을 hex로 설정합니다.

ALTER DATABASE <registry_database> SET bytea_output = 'hex';

그런 다음 레지스트리를 재시작하거나 새 연결을 열어 다시 연결하고 가져오기를 재시도합니다. 역할 수준 설정이 데이터베이스 기본값보다 우선하므로, 역할에 bytea_output이 설정되어 있다면 그쪽도 함께 설정합니다.

ALTER ROLE <registry_user> SET bytea_output = 'hex';

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

레지스트리가 다음 오류 중 하나와 함께 시작에 실패할 수 있습니다.

오류: registry filesystem metadata in use, please import data before enabling the database#

이 오류는 구성에서 registry['database'] = { 'enabled' => true}로 데이터베이스를 활성화했지만 아직 기존 레지스트리 메타데이터를 가져오지 않았을 때 발생합니다.

오류: registry metadata database in use, please enable the database#

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

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

다음 오류 중 하나가 발생하는 경우가 있습니다.

  • could not check if filesystem metadata is locked
  • could not check if database metadata is locked
  • failed to mark filesystem for database only usage
  • failed to mark filesystem only usage

이는 레지스트리가 구성된 rootdirectory에 접근할 수 없다는 뜻입니다. 이전에 레지스트리가 정상 동작했다면 이 오류는 거의 발생하지 않습니다. 오류 로그에서 잘못된 구성이 없는지 확인합니다.

태그 삭제 후 스토리지 사용량이 감소하지 않음#

기본적으로 온라인 가비지 컬렉터는 참조되지 않는 레이어를 해당 레이어와 연결된 모든 태그가 삭제된 시점으로부터 48시간이 지나야 삭제하기 시작합니다. 레이어는 이미지 및 태그와 연결되기 전에 레지스트리로 푸시되므로, 이 지연은 가비지 컬렉터가 오래 걸리거나 중단된 이미지 푸시를 방해하지 않도록 합니다.

Note

온라인 가비지 컬렉션은 참조되지 않는 오브젝트를 스토리지에서 삭제합니다. 그 공간을 언제 회수할지는 오브젝트 스토리지 공급자가 결정합니다. 오브젝트 버전 관리나 보존 정책이 삭제된 오브젝트를 무기한 보관하면 공급자는 공간을 회수하지 않습니다. 공간을 회수하려면 현재 버전이 아닌 오브젝트를 만료시키는 수명 주기 규칙을 구성합니다.

오류: permission denied for schema public (SQLSTATE 42501)#

레지스트리 마이그레이션이나 GitLab 업그레이드 중에 다음 오류 중 하나가 발생할 수 있습니다.

  • ERROR: permission denied for schema public (SQLSTATE 42501)
  • ERROR: relation "public.blobs" does not exist (SQLSTATE 42P01)

이러한 오류는 보안상의 이유로 public 스키마의 기본 CREATE 권한을 제거한 PostgreSQL 15 이상의 변경 때문에 발생합니다. PostgreSQL 15 이상에서는 기본적으로 데이터베이스 소유자만 public 스키마에 오브젝트를 생성할 수 있습니다.

오류를 해결하려면 다음 명령을 실행해 레지스트리 사용자에게 레지스트리 데이터베이스의 소유자 권한을 부여합니다.

ALTER DATABASE <registry_database_name> OWNER TO <registry_user>;

이렇게 하면 레지스트리 사용자가 테이블을 생성하고 마이그레이션을 정상적으로 실행하는 데 필요한 권한을 갖습니다.

오류: database-in-use and filesystem-in-use lockfiles present#

이 오류는 구성된 레지스트리 스토리지에 filesystem-in-use와 database-in-use 잠금 파일이 모두 존재할 때 발생하며, 레지스트리 상태가 모호하다는 뜻입니다.

이 오류를 해결하려면 레지스트리가 메타데이터 데이터베이스를 사용해야 하는지 기존 메타데이터 스토리지를 사용해야 하는지 판단해야 합니다.

다음에 해당한다면 레지스트리가 메타데이터 데이터베이스를 사용해야 할 가능성이 큽니다.

  • 이전에 가져오기 절차 중 하나를 수행한 경우
  • 레지스트리 구성에 레지스트리가 활성화되어 있다고 표시된 경우

/etc/gitlab/gitlab.rb 파일에서 레지스트리가 활성화되어 있는지 확인합니다.

registry['database'] = {
  'enabled' => true,
}

레지스트리가 데이터베이스를 사용해야 한다고 확인했다면, 구성된 레지스트리 스토리지의 /docker/registry/lockfiles/filesystem-in-use에 있는 filesystem-in-use 잠금 파일을 삭제합니다.

위 상황에 해당하지 않고 레지스트리가 기존 메타데이터 스토리지를 사용해야 한다면, /docker/registry/lockfiles/database-in-use에 있는 database-in-use 잠금 파일을 삭제합니다.

GitLab 18.8과 18.9에서는 REGISTRY_FF_ENFORCE_LOCKFILES 컨테이너 레지스트리 기능 플래그를 false로 설정해 잠금 파일 검사를 비활성화할 수 있습니다. 이렇게 하면 검사가 비활성화되지만, 이 오류는 레지스트리 데이터의 무결성을 지키기 위한 것이므로 어떤 메타데이터 스토리지를 사용하는지 먼저 확인하는 편이 좋습니다. REGISTRY_FF_ENFORCE_LOCKFILES 기능 플래그는 GitLab 18.10에서 제거되었습니다. 자세한 내용은 컨테이너 레지스트리 기능 플래그를 참고합니다.