GitLab 16 변경 사항

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

이 페이지에는 GitLab 16의 소규모 및 패치 버전을 업그레이드하는 정보가 포함되어 있습니다. 다음 사항을 확인해야합니다.

  • 귀하의 설치 유형
  • 귀하의 현재 버전과 목표 버전 사이의 모든 버전

GitLab Helm Chart를 업그레이드 하는 데 대한 자세한 정보는 릴리스 노트를 참조하십시오.

15.11에서 업그레이드할 때 주의할 사항

  • GitLab 16부터 PostgreSQL 12 지원 중단. GitLab 16.0 이상으로 업그레이드하기 전에 PostgreSQL을 적어도 버전 13.6으로 업그레이드하십시오.
  • GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드 된 경우 데이터베이스 스키마가 올바르지 않습니다. 16.x로 업그레이드 하기 전에 workaround를 수행하십시오.

  • 대부분의 설치에서 16.0, 16.1 및 16.2를 건너뛸 수 있습니다. 처음으로 필요한 업그레이드 경로의 중지점은 16.3입니다. 모든 경우에 해당합니다. 해당 중간 버전에 대한 참고 사항을 검토해야합니다.

    GitLab 설치에 따라 특정 기능을 사용하는지 여부 및 환경의 크기에 따라 중간 버전에서 중지해야 하는 경우가 있습니다.

    인스턴스가 영향을 받고 이러한 중지점을 건너 뛰는 경우:

    • 업그레이드에 수십 시간이 걸릴 수 있습니다.
    • 데이터베이스 변경이 모두 완료될 때까지 인스턴스에서 500 오류가 생성됩니다. 이후 Puma와 Sidekiq를 다시 시작해야합니다.

    • Linux 패키지 설치의 경우 시간이 초과되어 수동 workaround를 완료해야합니다.

    • GitLab 16.0은 프로젝트 크기에 대한 한계를 강제하는 변경 사항을 도입했습니다. Self-managed의 경우 이러한 제한을 사용하는 경우, 제한에 도달한 프로젝트는 동일한 그룹의 영향을받지 않는 Git 저장소로 푸시 할 때 오류 메시지가 발생합니다. 오류는 종종 0 바이트의 제한(0 B 제한)을 초과한다는 내용입니다.

    푸시는 성공하지만 오류는 반대로 시사하며 자동화에 문제를 일으킬 수 있습니다. 이 문제에 대해 더 읽기. 이 버그는 GitLab 16.5 이후로 수정되었습니다.

  • 보통 PgBouncer가 있는 환경의 백업은 GITLAB_BACKUP_로 접두사가 지정된 변수를 설정하여 PgBouncer를 우회해야합니다. 그러나 이슈 때문에 gitlab-backup은 오버라이드에 정의된 직접적인 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 이 문제의 해결책은 직접적으로 pg_dump를 사용하는 것입니다.

    영향을받는 릴리스:

    영향을받는 마이너 릴리스 영향을받는 패치 릴리스 수정된 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

  • Gitaly 및 Praefect 구성 구조는 GitLab 16로 업그레이드하기 전에 변경해야합니다. 데이터 손실을 피하려면 먼저 Praefect를 재구성하고, 새 구성의 일환으로 메타데이터 확인을 비활성화하십시오. 자세한 정보는 다음을 읽으십시오:

  • 만약 Gitaly를 /var/opt/gitlab/git-data/repositories 이외의 위치에 저장하도록 다시 구성하는 경우, 패키지화된 GitLab 16.0 이상은 자동으로 디렉토리 구조를 생성하지 않습니다. 자세한 내용 및 해결책은 이슈를 읽어보십시오.

16.10.0

Linux 패키지 설치

GitLab 16.10의 Linux 패키지 설치에는 Patroni의 새 주요 버전으로의 업그레이드가 포함되어 있습니다. 버전 2.1.0에서 버전 3.0.1로 업그레이드되었습니다.

참조 아키텍처 중 하나를 사용하는 경우(고가용성 (HA)(3,000명 이상의 사용자), Linux 패키지 설치용 PostgreSQL 복제 및 장애 조치에서 Patroni를 사용합니다.

이 경우 다중 노드 인스턴스를 업그레이드하는 방법에 대해서는 다운타임을 가진 다중 노드 업그레이드를 읽어보세요.

2.1.0 버전과 3.0.1 버전 사이에 소개된 변경 사항에 대한 자세한 정보는 Patroni 릴리스 노트를 참조하세요.

16.9.0

GitLab 16.9.0으로 업그레이드하는 동안 다음 오류를 만날 수 있습니다: 

PG::UndefinedTable: ERROR:  relation "p_ci_pipeline_variables" does not exist

모든 마이그레이션이 완료되었는지 확인하고 모든 Rails 및 Sidekiq 노드를 재시작하세요. 이 버그에 대한 수정은 16.9.1에서 릴리스 예정입니다.

Geo 설치

  • GitLab 16.5에서 소개된 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터 손실이 발생할 수 있습니다. 문제의 세부 정보 및 해결책은 이슈 #439933에서 확인하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • 기본 사이트와 보조 사이트 간 체크섬 불일치로 일부 컨테이너 레지스트리 이미지의 확인 실패가 발생할 수 있습니다. 이슈 442667에 자세한 내용이 기술되어 있습니다. 데이터는 올바르게 복제되지만 확인에는 실패하는 상황이므로 직접적인 데이터 손실의 위험은 없습니다. 현재는 알려진 해결책이 없습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.8.0

  • GitLab 16.8.0 및 16.8.1에서 Sidekiq gem이 업그레이드되었으며, 최신 버전은 Redis 6.2 이상이 필요합니다. Redis 6.0을 사용 중이라면 직접적으로 16.8.2로 업그레이드하여 Redis 6.0과의 호환성을 복원하세요.

  • 참고: Redis 6.0은 더 이상 지원되지 않습니다.

  • 보통 PgBouncer가 있는 환경의 백업은 GITLAB_BACKUP_로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접적인 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하므로 데이터베이스 백업이 실패합니다. 해결 방법은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

  • PostgreSQL 버전 14는 GitLab 16.7 이후의 최신 설치에 대한 기본값입니다. 알려진 문제로 인해 기존 Geo 이차 사이트는 PostgreSQL 버전 14로 업그레이드할 수 없습니다. 자세한 정보는 이슈 7768를 참조하십시오. 모든 Geo 사이트는 동일한 버전의 PostgreSQL을 실행해야 합니다. GitLab 16.7에서 16.8.1로 새 Geo 이차 사이트를 추가하려면 구성에 따라 다음 조치 중 하나를 취해야 합니다:

    • 첫 번째 Geo 이차 사이트를 추가하려면: 새 Geo 이차 사이트를 설정하기 전에 Primary 사이트를 PostgreSQL 14로 업그레이드하십시오. 기본 사이트가 이미 PostgreSQL 14를 실행 중이라면 특별한 조치가 필요하지 않습니다.
    • 하나 이상의 Geo 이차 사이트가 이미 설치된 배포에 새 Geo 이차 사이트를 추가하려면:
      • 모든 기존 사이트가 PostgreSQL 13을 실행하는 경우, 고정된 PostgreSQL 버전 13으로 새 Geo 이차 사이트를 설치합니다.
      • 모든 기존 사이트가 PostgreSQL 14를 실행하는 경우: 특별한 조치가 필요하지 않습니다.
      • 새 Geo 이차 사이트를 배포에 추가하기 전에 모든 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드하십시오.

  • GitLab 16.5에서 소개된 버그로 개인 스니펫이 이차 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터의 손실이 발생할 수 있습니다. 이 문제에 대한 자세한 내용 및 해결 방법은 이슈 #439933를 참조하십시오.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 해결된 릴리스
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • 기본 사이트와 이차 사이트 간 체크섬 불일치로 일부 컨테이너 레지스트리 이미지의 검증 실패가 발생할 수 있습니다. 자세한 내용은 이슈 442667를 참조하십시오. 데이터가 이차 사이트로 올바르게 복제되지만 성공적으로 확인되지 않기 때문에 데이터 손실의 직접적인 위험이 없습니다. 현재는 알려진 해결 방법이 없습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 해결된 릴리스
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.7.0

  • GitLab 16.7는 필수 업그레이드입니다. 이는 GitLab 16.7 및 이전의 모든 자체 관리형 인스턴스에서 도입된 모든 데이터베이스 변경 사항이 구현되었음을 보장합니다. 종속 변경 내용은 이후에 GitLab 16.8 및 이후에 릴리스될 수 있습니다. 자세한 내용은 이슈 429611을 참조하십시오.

  • 일반적으로 PgBouncer를 사용하는 환경에서의 백업은 GITLAB_BACKUP_로 접두사가 있는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 해결된 릴리스
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

리눅스 패키지 설치에 특정 정보가 적용됩니다:

  • GitLab 16.7부터 PostgreSQL 14가 리눅스 패키지와 함께 기본 버전으로 설치됩니다. 패키지 업그레이드 중에는 데이터베이스가 PostgreSQL 14로 업그레이드되지 않습니다. PostgreSQL 14로 업그레이드하려면 수동으로 해야 합니다.

    PostgreSQL 13을 사용하려면 /etc/gitlab/gitlab.rb에서 postgresql['version'] = 13을 설정해야 합니다.

Geo 설치

  • GitLab 16.7 이상의 최신 설치에는 PostgreSQL 버전 14가 기본 설정됩니다. 알려진 문제로 인해 기존 Geo 이중 사이트는 PostgreSQL 버전 14로 업그레이드할 수 없습니다. 자세한 내용은 이슈를 참조하세요. 모든 Geo 사이트는 동일한 버전의 PostgreSQL을 실행해야 합니다. GitLab 16.7부터 16.8.1을 기반으로 새 Geo 이중 사이트를 추가하려면 구성에 따라 다음 조치 중 하나를 취해야 합니다:

    • 첫 번째 Geo 이중 사이트를 추가하는 경우: 새로운 Geo 이중 사이트를 설정하기 전에 기본 사이트를 PostgreSQL 14로 업그레이드하세요. 기본 사이트가 이미 PostgreSQL 14를 실행 중이면 별도의 조치가 필요하지 않습니다.
    • 이미 기존 이중 사이트가 모두 PostgreSQL 13을 실행 중인 경우: 포함된 PostgreSQL 버전 13으로 새 Geo 이중 사이트를 설치하세요.
    • 이미 기존 사이트가 모두 PostgreSQL 14를 실행 중인 경우: 별도의 조치가 필요하지 않습니다.
    • 새 Geo 이중 사이트를 배포에 추가하기 전에 모든 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드하세요.

  • 기본 사이트와 이중 사이트 간의 체크섬 불일치로 일부 프로젝트의 검증 실패가 발생할 수 있습니다. 자세한 내용은 이 이슈에서 추적됩니다. 데이터가 이중 사이트에 올바르게 복제되고 있기 때문에 데이터 손실 가능성은 없습니다. 영향을 받는 프로젝트를 이중 사이트에서 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재 알려진 해결책은 없습니다. 문제를 해결하기 위해 노력 중입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 해결 버전
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 소개된 버그로 개인 스니펫이 이중 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #439933에서 확인할 수 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 해결 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.6.0

  • GitLab 16.6으로 업그레이드한 후 이전 CI 환경 파괴 작업이 생성될 수 있습니다.

  • 일반적으로 PgBouncer가 있는 환경의 백업은 GITLAB_BACKUP_ 접두어가 있는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결책은 pg_dump을 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 해결 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

  • 기본 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트에서 확인 실패를 경험할 수 있습니다. 자세한 내용은 이슈에서 추적됩니다. 데이터가 올바르게 보조 사이트로 복제되기 때문에 데이터 손실 위험이 없습니다. 영향을 받는 프로젝트를 Geo 보조 사이트에서 클론하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재는 알려진 해결책이 없습니다. 문제에 대해 적극적으로 해결 중입니다.

    영향을 받는 릴리스:

    영향을 받는 소규모 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 버그가 발생하여 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 발생 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 자세한 내용과 해결책은 이슈 #439933에서 확인할 수 있습니다.

    영향을 받는 릴리스:

    영향을 받는 소규모 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.5.0

  • Gitaly에서는 Git 2.42.0 이상이 필요합니다. 직접 컴파일된 설치의 경우, Gitaly에서 제공하는 Git 버전을 사용해야 합니다.
  • 회귀로 인해 때로는 그룹을 탐색할 때 HTTP 500 오류가 발생할 수 있습니다. GitLab 16.6 이상으로 업그레이드하면 문제가 해결됩니다.
  • 회귀로 인해 선택되지 않은 고급 검색 기능이 로드되지 않을 수 있습니다. 16.6 이상으로 업그레이드하면 문제가 해결됩니다.

  • 16.5에서는 unique_batched_background_migrations_queued_migration_version 인덱스가 도입되었으며, 게시 후 마이그레이션인 DeleteOrphansScanFindingLicenseScanningApprovalRules2는 제로 다운타임 업그레이드 중에 이 고유 제약 조건을 깨뜨릴 수 있습니다. 이슈 #437291에서 오류를 수정하는 해결책이 제공됩니다: 

    PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint
"unique_batched_background_migrations_queued_migration_version"
DETAIL:  Key (queued_migration_version)=(20230721095222) already exists.

  • 일반적으로 PgBouncer가 있는 환경에서는 백업이 Prefix GITLAB_BACKUP_로 시작하는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에서 정의한 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 소규모 릴리스 영향을 받는 패치 릴리스 수정 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

  • SSH 클론 URL은 /etc/gitlab/gitlab.rb에서 gitlab_rails['gitlab_ssh_host']를 설정하여 사용자 정의로 변경할 수 있습니다. 이 설정은 이제 유효한 호스트 이름이어야 합니다. 이전에는 리포지토리 클론 URL에 사용되는 임의의 문자열로 사용되었던 사용자 정의 호스트 이름 및 포트로 설정할 수 있었습니다.

    예를 들어, GitLab 16.5 이전에는 다음 설정이 작동했습니다: 

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com:2222"

    GitLab 16.5부터 호스트 이름과 포트를 별도로 지정해야 합니다: 

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com"
gitlab_rails['gitlab_shell_ssh_port'] = 2222

    설정을 변경한 후에는 GitLab을 재구성해야 합니다: 

    sudo gitlab-ctl reconfigure

Geo 설치

지오를 사용하는 설치에는 특정 정보가 적용됩니다:

  • 16.3.0에서 일부 Prometheus 메트릭이 잘못 제거되어 대시보드 및 경고가 손상될 수 있습니다:

    영향 받는 메트릭 16.5.2 및 이후에 복원된 메트릭 16.3 이상에서 사용 가능한 대체
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 불가
    geo_repositories_retrying_verification 아니요 사용 불가
    • 영향을 받는 버전:
      • 16.3.0에서 16.5.1
    • 수정 사항이 포함된 버전:
      • 16.5.2 이후

    더 많은 정보는 이슈 429617을 참조하세요.

  • 객체 저장소 검증이 GitLab 16.4에 추가되었습니다. 이슈로 인해 일부 Geo 설치에서 메모리 사용량이 높게 보고되어 기본 사이트의 GitLab 애플리케이션이 응답하지 않을 수 있습니다.

    객체 저장소를 구성하고 GitLab 관리 객체 저장소 복제를 활성화한 경우 설치에 영향을 미칠 수 있습니다.

    이 문제가 해결될 때까지 객체 저장소 검증을 비활성화해야 합니다. 기본 사이트의 Rails 노드 중 하나에서 다음 명령을 실행하세요: 

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.4 16.4.0 - 16.4.2 16.4.3
    16.5 16.5.0 - 16.5.1 16.5.2

  • GitLab 16.3에 그룹 위키 검증이 추가된 이후, 누락된 그룹 위키 리포지토리가 잘못된 검증 실패로 표시됩니다. 이 문제는 실제 복제/검증 실패가 아니라 Geo 내에서 이러한 누락된 리포지토리의 유효하지 않은 내부 상태로 발생하여 로그와 검증 진행률에 오류가 발생합니다.

    문제의 자세한 내용 및 해결 방법은 이슈 #426571을 참조하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 16.5.0 - 16.5.1 16.5.2

  • 기본 사이트와 보조 사이트 간 체크섬 불일치로 일부 프로젝트의 검증 실패가 발생할 수 있습니다. 자세한 내용은 이 이슈에서 추적됩니다. 데이터는 올바르게 보조 사이트로 복제되기 때문에 데이터 손실의 위험이 없습니다. 영향을 받은 프로젝트를 Geo 보조 사이트에서 클론하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재는 알려진 해결책이 없습니다. 문제에 대해 노력하고 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.4 모두 없음
    16.5 모두 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 소개된 버그로 인해 개인 스니펫이 Geo 보조 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #439933을 참조하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

16.4.0

  • 그룹 경로를 업데이트하는 버그 수정을 받았습니다16.3에 도입된 데이터베이스 인덱스를 사용합니다.

    16.3보다 낮은 버전에서 16.4로 업그레이드하는 경우 사용하기 전에 데이터베이스에서 ANALYZE packages_packages;를 실행해야 합니다.

  • GitLab 16.4 이상으로 업그레이드하는 동안 다음과 같은 오류가 발생할 수 있습니다: 

    main: == 20230830084959 ValidatePushRulesConstraints: migrating =====================
main: -- execute("SET statement_timeout TO 0")
main:    -> 0.0002s
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT force_push_regex_size_constraint;")
main:    -> 0.0004s
main: -- execute("RESET statement_timeout")
main:    -> 0.0003s
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT delete_branch_regex_size_constraint;")
rails aborted!
StandardError: An error has occurred, all later migrations canceled:

PG::CheckViolation: ERROR:  check constraint "delete_branch_regex_size_constraint" of relation "push_rules" is violated by some row

    이러한 제약 조건은 오류를 반환할 수 있습니다:

    • author_email_regex_size_constraint
    • branch_name_regex_size_constraint
    • commit_message_negative_regex_size_constraint
    • commit_message_regex_size_constraint
    • delete_branch_regex_size_constraint
    • file_name_regex_size_constraint
    • force_push_regex_size_constraint

    오류를 해결하려면 511 글자 제한을 초과하는 레코드를 push_rules 테이블에서 찾으세요. 

    ;; 제약 조건에 사용된 필드 이름으로 `delete_branch_regex`를 바꿉니다
SELECT id FROM push_rules WHERE LENGTH(delete_branch_regex) > 511;

    푸시 규칙이 프로젝트, 그룹 또는 인스턴스에 속하는지 확인하려면 Rails 콘솔에서 다음 스크립트를 실행하세요: 

    # 제약 조건에 사용된 필드 이름으로 `delete_branch_regex`를 바꿉니다
long_rules = PushRule.where("length(delete_branch_regex) > 511")

array = long_rules.map do |lr|
  if lr.project
    "ID가 #{lr.id}인 푸시 규칙은 프로젝트 #{lr.project.full_name}에 구성되어 있습니다"
  elsif lr.group
    "ID가 #{lr.id}인 푸시 규칙은 그룹 #{lr.group.full_name}에 구성되어 있습니다"
  else
    "ID가 #{lr.id}인 푸시 규칙은 인스턴스 수준에 구성되어 있습니다"
  end
end

puts "총 규칙 수: #{array.count}"
puts array.join("\n")

    영향을 받는 푸시 규칙 레코드의 정규식 필드 값을 줄이고, 그 후 마이그레이션을 다시 시도하세요.

    영향을 받는 푸시 규칙이 너무 많고 GitLab UI를 통해 업데이트할 수 없는 경우, GitLab 지원팀에 문의하세요.

  • 일반적으로 PgBouncer가 있는 환경의 백업은 GITLAB_BACKUP_로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에서 정의된 직접적인 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 내용
    15.11 전체 없음
    16.0 전체 없음
    16.1 전체 없음
    16.2 전체 없음
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 전체 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

자체 컴파일 설치

  • GitLab 16.4 이상에서 GitLab 시크릿 및 사용자 정의 후크 경로를 구성하는 새로운 방법을 선호합니다:
    1. 구성을 업데이트하여 [gitlab] secret_file을 GitLab 시크릿 토큰의 경로로 구성합니다.
    2. 사용자 정의 후크가 있는 경우, 구성을 업데이트하여 [hooks] custom_hooks_dir를 서버 측 사용자 정의 후크의 경로로 구성합니다.
    3. [gitlab-shell] dir 구성을 제거하세요.

지오 설치

지오를 사용하는 설치에는 특정 정보가 적용됩니다.

  • 16.3.0에서 잘못 제거된 프로메테우스 메트릭의 번호가 대시 보드와 경보를 중단시킬 수 있습니다:

    영향을 받는 메트릭 16.5.2 및 이후에 복원된 메트릭 16.3+에서 사용 가능한 대체
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 불가
    geo_repositories_retrying_verification 아니요 사용 불가
    • 영향을 받는 버전:
      • 16.3.0부터 16.5.1
    • 수정이 포함된 버전:
      • 16.5.2 및 이후

    더 많은 정보는 issue 429617을 참조하세요.

  • GitLab 16.4에서 객체 저장소 검증이 추가되었습니다. 이슈로 인해 일부 Geo 설치에서 높은 메모리 사용량이 보고되어 주 서버의 GitLab 애플리케이션이 응답하지 않을 수 있습니다.

    개체 저장소를 구성하고 GitLab 관리 객체 저장소 복제를 활성화한 경우 설치에 영향을 받을 수 있습니다.

    이 문제가 해결될 때까지 대안은 객체 저장소 검증을 비활성화하는 것입니다. 주 사이트의 레일스 노드 중 하나에서 다음 명령을 실행하십시오: 

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.4 16.4.0 - 16.4.2 16.4.3
    16.5 16.5.0 - 16.5.1 16.5.2

  • 동기 상태가 대기 상태로 멈추는 문제로 이어진 결과로 영향을 받는 항목의 복제가 계속되고 실패로 이어져 장애 조치 발생 시 데이터 손실 위험이 있습니다. 이 문제는 주로 저장소 동기화에 영향을 미치지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실 위험을 피하려면 수정된 버전으로 업그레이드하는 것이 좋습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 16.3.0 - 16.3.5 16.3.6
    16.4 16.4.0 - 16.4.1 16.4.2

  • 그룹 위키 확인이 GitLab 16.3에 추가된 후 일부 그룹 위키 저장소가 잘못된 상태로 실패한 것으로 표시됩니다. 이 문제는 실제 복제/확인 실패가 아니라 지오 내부에서 이러한 누락된 저장소에 대한 잘못된 내부 상태로 로그와 확인 진행에 대한 오류를 유발합니다.

    문제의 자세한 내용 및 해결 방법은 issue #426571을 확인하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 16.5.0 - 16.5.1 16.5.2

  • 일부 프로젝트의 주 부하 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트의 확인 실패가 발생할 수 있습니다. 자세한 내용은 issue를 확인하세요. 데이터는 올바르게 보조 사이트로 복제되기 때문에 데이터 손실 위험이 없습니다. 영향을 받는 프로젝트를 복제하는 사용자는 항상 주 사이트로 리디렉션됩니다. 현재 알려진 해결책은 없습니다. 문제에 대해 빠르게 해결하고 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.4 모두 없음
    16.5 모두 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

16.3.0

  • GitLab 16.3.5 이상으로 업데이트하세요. 이렇게 하면 issue 425971로 인해 GitLab 16.3.3 및 16.3.4의 데이터베이스 디스크 공간이 과도하게 사용되는 문제를 피할 수 있습니다.

  • 중복된 NPM 패키지가 데이터베이스에 없도록 보장하기 위해 고유한 인덱스가 추가되었습니다. 중복된 NPM 패키지가 있는 경우 16.1로 먼저 업그레이드해야 하거나 다음 오류를 실행할 수 있습니다. PG::UniqueViolation: ERROR: could not create unique index "idx_packages_on_project_id_name_version_unique_when_npm".

  • Go 어플리케이션의 경우, crypto/tls: verifying certificate chains containing large RSA keys is slow (CVE-2023-29409) RSA 키의 크기가 8192 비트로 제한되었습니다. GitLab의 Go 어플리케이션에서는 RSA 키가 다음과 같이 구성될 수 있습니다:

    업그레이드하기 전에 위 어플리케이션 중 어느 것이라도 RSA 키의 크기를 확인하세요 (openssl rsa -in <your-key-file> -text -noout | grep "Key:").

  • BackfillCiPipelineVariablesForPipelineIdBigintConversion 배경 마이그레이션이 EnsureAgainBackfillForCiPipelineVariablesPipelineIdIsFinished 포스트-디플로이 마이그레이션과 함께 최종화되었습니다. GitLab 16.2.0에서는 일괄적인 배경 마이그레이션으로 ci_pipeline_variables 테이블의 bigint pipeline_id` 값을 backfill했습니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 오랜 시간이 걸릴 수 있으며(한 사례에서 5000만 행을 처리하는 데 4시간이 소요되었습니다), 업그레이드 다운타임을 줄이기 위해 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

    데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다: 

    select count(*) from ci_pipeline_variables;

  • PgBouncer가 있는 환경에서 백업을 수행하는 경우, 일반적으로 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup이 오버라이드에서 정의된 다이렉트 연결 대신 PgBouncer를 통해 일반적인 데이터베이스 연결을 사용하고 백업이 실패합니다. 해결책은 직접 pg_dump를 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 릴리스
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

Linux 패키지 설치에 특정 정보가 적용됩니다:

  • GitLab 16.0에서 업그레이드된 기본 Docker 이미지를 발표했는데, 여기에는 새 버전의 OpenSSH Server가 포함되어 있습니다. 새 버전의 의도하지 않은 결과는 기본적으로 SSH RSA SHA-1 서명을 수락하지 않도록 비활성화되었는데, 이 문제는 매우 오래된 SSH 클라이언트를 사용하는 사용자에만 영향을 줍니다.

    SHA-1 서명 사용이 불가능한 문제를 피하기 위해 사용자는 보안 이유로 상위 라이브러리에서 권장하지 않기 때문에 SSH 클라이언트를 업데이트해야 합니다.

    사용자가 SSH 클라이언트를 즉시 업그레이드할 수 없는 전환 기간을 허용하기 위해, GitLab 16.3 이후에서는 Dockerfile에서 GITLAB_ALLOW_SHA1_RSA 환경 변수를 지원합니다. GITLAB_ALLOW_SHA1_RSA가 true로 설정되면 이 새로운 지원이 다시 활성화됩니다.

    우리는 보안 모범 사례를 촉진하고 상위 라이브러리 권장을 따르기를 원하기 때문에 이 환경 변수는 GitLab 17.0에서 지원 중단 예정입니다.

    더 많은 정보를 보려면 아래를 참조하세요:

Geo 설치

Geo를 사용하는 설치에 대해 특정 정보가 적용됩니다:

  • 보조 Geo 사이트에 대한 Git pull은 해당 보조 사이트가 최신 상태일 때에도 기본 Geo 사이트로 프록시됩니다. 보조 Geo 사이트에 대한 Git pull 요청을 가속화하기 위해 Geo를 사용하는 경우 이에 영향을 받습니다.

    • 영향을 받는 버전:
      • 16.3.0 ~ 16.3.3
    • 수정이 포함된 버전:
      • 16.3.4 이후

    자세한 내용은 issue 425224를 참조하십시오.

  • 16.3.0에서 여러 Prometheus 메트릭이 잘못 제거되어 대시보드 및 경고를 망가뜨릴 수 있습니다:

    영향을 받는 메트릭 16.5.2 이상에서 복원된 메트릭 16.3+에서 이용 가능한 대체 항목
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 이용 가능한 항목 없음
    geo_repositories_retrying_verification 아니요 이용 가능한 항목 없음
    • 영향을 받는 버전:
      • 16.3.0 ~ 16.5.1
    • 수정이 포함된 버전:
      • 16.5.2 이후

    자세한 내용은 issue 429617를 참조하십시오.

  • 보류 중인 상태의 동기화 상태 문제가 이슈로 인해 해당 아이템을 영구적으로 보류된 상태로 유지시키므로 장애 조치시 데이터 손실 위험이 발생합니다. 이는 주로 저장소 동기화에 영향을 미치지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실 위험을 피하려면 수정된 버전으로 업그레이드하는 것이 좋습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 16.3.0 ~ 16.3.5 16.3.6
    16.4 16.4.0 ~ 16.4.1 16.4.2

  • GitLab 16.3에 그룹 위키 확인이 추가된 후, 누락된 그룹 위키 저장소가 잘못된 상태로 오해되어 검증 실패로 표시됩니다. 이 문제는 실제 복제/확인 실패가 아니라 Geo 내부에서 누락된 이러한 저장소에 대한 잘못된 내부 상태로 로그 및 검증 진행이 이 그룹 위키 저장소에 대한 실패 상태를 보고합니다.

    문제에 대한 자세한 내용 및 해결 방법은 이슈 #426571을 참조하십시오.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 전체 없음
    16.4 전체 없음
    16.5 16.5.0 ~ 16.5.1 16.5.2

16.2.0

  • 이하 버전에서 레거시 LDAP 구성 설정은 NoMethodError: undefined method 'devise' for User:Class 오류를 발생시킬 수 있습니다. 이 오류는 ca_file와 같은 TLS 옵션을 tls_options 해시에 지정하지 않거나 레거시 gitlab_rails['ldap_host'] 옵션을 사용한 경우에 발생합니다. 자세한 내용은 구성 해결책을 참조하십시오.

  • GitLab 데이터베이스가 15.11.0 ~ 15.11.2를 통해 생성되었거나 업그레이드된 경우, GitLab 16.2로 업그레이드하려고 하면 다음과 같은 오류가 발생합니다: 

    PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

    자세한 내용 및 해결 방법은 #undefined-column-error-upgrading-to-162-or-later를 참조하십시오.

  • GitLab 16.2 이상으로 업그레이드하는 동안 다음과 같은 오류가 발생할 수 있습니다: 

    main: == 20230620134708 ValidateUserTypeConstraint: migrating =======================
main: -- execute("ALTER TABLE users VALIDATE CONSTRAINT check_0dd5948e38;")
rake aborted!
StandardError: An error has occurred, all later migrations canceled:
PG::CheckViolation: ERROR:  check constraint "check_0dd5948e38" of relation "users" is violated by some row

    자세한 내용은 issue 421629을 참조하십시오.

  • GitLab 16.2 이상으로 업그레이드한 후 다음과 같은 오류가 발생할 수 있습니다: 

    PG::NotNullViolation: ERROR:  null value in column "source_partition_id" of relation "ci_sources_pipelines" violates not-null constraint

    이 문제를 해결하려면 Sidekiq 및 Puma 프로세스를 재시작해야 합니다.

  • 일반적으로 PgBouncer가 있는 환경에서는 GITLAB_BACKUP_로 접두어가 붙은 변수를 설정하여 백업을 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통한 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 전체 없음
    16.0 전체 없음
    16.1 전체 없음
    16.2 전체 없음
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 전체 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

Linux 패키지 설치에 특정 정보가 적용됩니다.

  • GitLab 16.2부터 PostgreSQL 13.11 및 14.8이 모두 Linux 패키지와 함께 제공됩니다. 패키지 업그레이드 중에는 데이터베이스가 PostgreSQL 14로 업그레이드되지 않습니다. PostgreSQL 14로 업그레이드하려면 수동으로 실행해야 합니다: 

    sudo gitlab-ctl pg-upgrade -V 14

    PostgreSQL 14는 Geo 배포에서 지원되지 않으며 향후 릴리스에서 계획되어 있습니다.

  • 16.2에서는 Redis를 6.2.11에서 7.0.12로 업그레이드합니다. 이 업그레이드는 완전히 하위 호환성이 있는 것으로 예상됩니다.

    Redis는 ‘gitlab-ctl reconfigure’의 일환으로 자동으로 다시 시작되지 않습니다. 따라서 사용자는 새로운 Redis 버전을 사용하도록 하기 위해 ‘sudo gitlab-ctl restart redis’를 수동으로 실행해야 합니다. 재구성 실행 후에 설치된 Redis 버전이 실행 중인 버전과 다를 경우 다시 시작이 수행될 때까지 경고가 표시됩니다.

    만약 인스턴스에 Redis HA가 포함되어 있다면 Zero Downtime 문서에서 업그레이드 단계를 확인하세요.

자체 컴파일 설치

Geo 설치

Geo를 사용하는 설치에는 특정 정보가 적용됩니다:

  • 작업 artifact가 객체 저장소에 저장되고 direct_upload가 활성화되어 있는 경우 Geo가 새로운 작업 artifact를 복제하지 않습니다. 이 버그는 GitLab 버전 16.1.4, 16.2.3, 16.3.0 및 그 이후에서 수정되었습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.3 및 16.2.0 - 16.2.2.
    • 영향을 받는 버전에서 실행 중일 때 동기화된 것처럼 보이던 artifact는 실제로 보조 사이트에 없을 수 있습니다. 영향을 받는 artifact는 16.1.5, 16.2.5, 16.3.1, 16.4.0 또는 그 이후 버전으로 업그레이드하면 자동으로 다시 동기화됩니다. 필요한 경우 영향을 받는 작업 artifact를 수동으로 동기화할 수 있습니다.

보조 사이트에서 LFS 객체를 복제할 때 기본 사이트에서 다운로드

LFS 객체에 대한 Geo 프록시 로직의 버그로 인해 모든 보조 사이트에 대한 LFS 클론 요청이 기본 사이트로 프록시됩니다. 이는 보조 사이트가 최신 상태일 때에도 발생할 수 있습니다. 이로 인해 기본 사이트에 대한 부하가 증가하고 보조 사이트에서 클론하는 사용자의 LFS 객체에 대한 액세스 시간이 길어질 수 있습니다.

GitLab 15.1에서 프록시 기능이 기본적으로 활성화되었습니다.

영향을 받지 않는 경우:

  • LFS 객체를 사용하도록 구성하지 않은 경우
  • 원격 사용자의 가속화를 위해 Geo를 사용하지 않은 경우
  • 원격 사용자의 가속화를 위해 Geo를 사용하지만 프록시 기능을 비활성화한 경우
영향을 받는 부수적 릴리스 영향을 받는 패치 릴리스 수정 버전
15.1 - 16.2 모든 16.3 및 이후

작업 방법: 프록시 기능을 비활성화하는 것이 가능한 해결 방법입니다. 클론 시점에 복제되지 않은 LFS 파일은 보조 사이트에서 서비스할 수 없을 수 있음을 참고하세요.

16.1.0

  • BackfillPreparedAtMergeRequests 배경 마이그레이션이 FinalizeBackFillPreparedAtMergeRequests 및 GitLab 15.10.0에서는 [일괄 배경 마이그레이션](../background_migrations.md#batched-background-migrations)으로 [merge_requests 테이블의 prepared_at` 값을 백필](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111865)하는 기능을 도입했습니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 여러 일이 소요될 수 있습니다. 16.1.0으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.
  • GitLab 16.1.0에는 일괄 배경 마이그레이션 MarkDuplicateNpmPackagesForDestruction이 포함되어 있으며 중복 NPM 패키지를 표시합니다. 16.3.0이나 이후에 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

  • BackfillCiPipelineVariablesForBigintConversion 배경 마이그레이션이 EnsureBackfillBigintIdIsCompleted와 함께 최종 완료되었습니다. GitLab 16.0.0에서는 배경 마이그레이션을 도입하여 더 큰 GitLab 인스턴스에서 ci_pipeline_variables 테이블의 bigint id 값을 백필했습니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 오랜 시간이 걸릴 수 있습니다(한 경우에 5000만 개의 행을 처리하는 데 4시간이 소요되었습니다). 장기간의 업그레이드 다운타임을 피하려면 마이그레이션이 성공적으로 완료되었는지 확인하고 16.1으로 업그레이드하기 전에 데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인하세요: 

    select count(*) from ci_pipeline_variables;

자체 컴파일 설치

  • puma.rb 구성 파일에서 Puma worker killer와 관련된 설정을 제거해야 합니다. 이 설정은 제거되었으며 자세한 내용은 puma.rb.example 파일을 참조하세요.

  • 일반적으로 PgBouncer가 있는 환경에서는 PgBouncer를 우회해야 합니다. 이를 위해 GITLAB_BACKUP_로 접두어가 있는 변수를 설정해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 있어 데이터베이스 백업에 실패합니다. 해결책으로 pg_dump를 직접 사용해야 합니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정됨
    15.11 All 없음
    16.0 All 없음
    16.1 All 없음
    16.2 All 없음
    16.3 All 없음
    16.4 All 없음
    16.5 All 없음
    16.6 All 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

Tier: 프리미엄, 얼티메이트 Offering: Self-Managed

Geo를 사용하는 설치에 적용되는 구체적인 정보:

  • 일부 프로젝트 가져오기는 프로젝트 생성 시 위키 저장소를 초기화하지 않습니다. 자세한 내용 및 해결책을 참조하세요.
  • 프로젝트 디자인을 SSF로 이전했기 때문에 누락된 디자인 저장소가 검증 실패로 잘못 플래그 지정되고 있습니다. 이 문제는 실제 복제/검증 실패가 아니라 이러한 누락된 저장소에 대한 잘못된 내부 상태로 인해 로그 및 검증 진행이 이러한 디자인 저장소에 대해 실패한 상태로 표시됩니다. 프로젝트를 가져오지 않은 경우에도 이 문제에 영향을 받을 수 있습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.2
    • 수정 버전이 포함된 버전: GitLab 16.1.3 이후
  • 객체 스토리지에 작업 아티팩트를 저장하도록 구성되었고 direct_upload가 활성화된 경우 Geo가 새 작업 아티팩트를 복제하지 않습니다. 이 버그는 GitLab 버전 16.1.4, 16.2.3, 16.3.0 및 이후에 수정되었습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.3 및 16.2.0 - 16.2.2.
    • 영향을 받는 버전에서 실행 중인 아티팩트는 실제로 이차 사이트에 누락될 수 있습니다. 영향을 받는 아티팩트는 16.1.5, 16.2.5, 16.3.1, 16.4.0 이후로 업그레이드하면 자동으로 다시 동기화됩니다. 필요한 경우 영향을 받는 작업 아티팩트를 수동으로 다시 동기화할 수 있습니다.
    • 완전히 동기화된 이차 사이트에서도 이차 사이트에서 LFS 객체를 복제하면 기본 사이트에서 다운로드됩니다. 자세한 내용 및 해결책을 참조하세요.

프로젝트 생성 시 위키 저장소 초기화되지 않음

영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정됨
15.11 All 없음
16.0 All 없음
16.1 16.1.0 - 16.1.2 16.1.3 이후

일부 프로젝트 가져오기는 프로젝트 생성 시 위키 저장소를 초기화하지 않습니다. 프로젝트 위키를 SSF로 마이그레이션한 이후, 누락된 위키 저장소가 검증 실패로 잘못 플래그 지정되고 있습니다. 이는 실제 복제/검증 실패가 아니며, 이러한 누락된 저장소를 위한 잘못된 내부 상태로 인해 로그에 오류가 표시되며 검증 진행이 이러한 위키 저장소에 대해 실패한 상태로 보고됩니다. 프로젝트를 가져오지 않은 경우 이 문제에 영향을 받지 않습니다.

16.0.0

  • /etc/gitlab/gitlab.rb 파일에 비 ASCII 문자가 있으면 Sidekiq가 충돌합니다. 이를 수정하려면 issue 412767의 해결 방법을 따르세요.
  • Sidekiq 작업은 기본적으로 default 및 mailers 큐로만 라우팅되며, 따라서 모든 Sidekiq 프로세스는 모든 큐에서 작업을 처리하기 위해 이러한 큐도 수신대상입니다. 이 동작은 라우팅 규칙을 구성하지 않았다면 적용되지 않습니다.
  • GitLab Docker 이미지를 실행하려면 Docker 20.10.10 이상이 필요합니다. 오래된 버전은 시작 시 오류를 발생시킵니다.
  • 16.0부터, GitLab Self-Managed 설치는 기본적으로 두 개의 데이터베이스 연결을 갖고 있으며, 기존의 하나 대신 두 배가 됩니다. 이 변경으로 인해 PostgreSQL 연결 수가 2배로 증가합니다. 이로써 Self-Managed 버전의 GitLab이 GitLab.com과 유사하게 동작하도록 만들어졌으며, Self-Managed 버전의 GitLab에서 CI 기능을 위한 별도의 데이터베이스를 활성화하기 위한 단계입니다. 16.0으로 업그레이드하기 전에 PostgreSQL의 최대 연결 수를 증가시켜야 하는지 확인하세요.
  • Azure 저장소를 사용하는 컨테이너 레지스트리에는 태그가 없는 경우가 있습니다. 이를 해결하려면 중단 변경 지침을 따르세요.

  • 일반적으로 PgBouncer가 있는 환경에서 백업은 GITLAB_BACKUP_으로 접두어가 붙은 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 issue로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신에 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

Linux 패키지 설치에 적용되는 특정 정보입니다:

  • PostgreSQL 12의 실행 파일이 삭제되었습니다.

    업그레이드 하기 전에 Linux 패키지 설치의 관리자는 PostgreSQL 13를 사용하는지 확인해야 합니다.

  • GitLab과 번들링된 Grafana는 폐기되었으며 더 이상 지원되지 않습니다. 이것은 GitLab 16.3에서 제거되었습니다.

  • 이것은 openssh-server를 1:8.9p1-3으로 업그레이드합니다.

    이전 OpenSSH 클라이언트로 ssh-keyscan -t rsa를 사용하여 공개 키 정보를 얻는 것은 OpenSSH 8.7 릴리즈 노트에 나열된 폐기로 인해 더 이상 사용할 수 없습니다.

    해결책은 다른 키 유형을 사용하거나 클라이언트 OpenSSH를 버전 >= 8.7로 업그레이드하는 것입니다.

  • Praefect 구성을 새 구조로 마이그레이션하여 GitLab 16.0 이후에도 모든 praefect['..'] 설정이 계속 작동하도록 합니다.

  • Gitaly 구성을 새 구조로 마이그레이션하여 GitLab 16.0 이후에도 모든 gitaly['..'] 설정이 계속 작동하도록 합니다.

Geo 설치

Tier: Premium, Ultimate Offering: Self-Managed

Geo를 사용하는 설치에 적용되는 특정 정보:

  • 프로젝트 가져오기 중 일부 프로젝트가 생성될 때 위키 리포지토리를 초기화하지 않습니다. 세부 정보 및 해결책 참조.
  • 보조 사이트에서 LFS 객체를 클론할 때 보조 사이트가 완전히 동기화되었더라도 기본 사이트에서 다운로드합니다. 세부 정보 및 해결책 참조.

Gitaly 구성 구조 변경

리눅스 패키지에서의 Gitaly 구성 구조는 GitLab 16.0에서 변경되어 self-compiled 설치에서 사용되는 Gitaly 구성 구조와 일관성을 갖도록 되었습니다.

이 변경으로 인해 gitaly['configuration'] 하위의 단일 해시가 대부분의 Gitaly 구성을 보유하게 됩니다. 일부 gitaly['..'] 구성 옵션은 GitLab 16.0 이후에도 계속 사용됩니다:

  • enable
  • dir
  • bin_path
  • env_directory
  • env
  • open_files_ulimit
  • consul_service_name
  • consul_service_meta

기존 구성을 새로운 구조로 이동하여 마이그레이션하십시오. git_data_dirs은 GitLab 17.0까지 지원됩니다. 새 구조는 GitLab 15.10부터 지원됩니다.

새 구조로 마이그레이션

경고: Gitaly 클러스터를 실행 중인 경우, 먼저 Praefect를 새 구성 구조로 마이그레이션하십시오. 이 변경이 테스트된 후 Gitaly 노드를 진행하십시오. Gitaly가 구성 오류로 삭제되면 리포지토리 검증 이 작동하도록 필요한 메타데이터를 삭제할 수 있습니다. 구성 실수에 대비하여 Praefect에서 일시적으로 리포지토리 검증을 비활성화하십시오.

  1. Gitaly 클러스터를 실행 중이면 모든 Praefect 노드에서 리포지토리 검증이 비활성화되었는지 확인하십시오. verification_interval: 0을 구성하고 gitlab-ctl reconfigure로 적용합니다.
  2. 새 구조를 구성할 때
    • ...을 이전 키의 값으로 바꿉니다.
    • storage를 구성할 때 git_data_dirs를 대체하려면 경로에 /repositories를 추가해야 합니다. 다음에 설명된 대로 문서화하여야 합니다. 이것을 빠트리면 구성이 수정될 때까지 Git 리포지토리에 접근할 수 없습니다. 이러한 구성 오류로 인해 메타데이터 삭제가 발생하며, 이것이 리포지토리 검증을 비활성화하는 이유입니다.
    • 이전에 값을 구성하지 않은 키는 건너뛰십시오.
    • 모든 해시 키에 대해 꼬리 쉼표를 추가하는 것이 좋습니다. 따라서 키가 재정렬되거나 추가 키가 추가될 때 해시가 유효한 상태를 유지합니다.
  3. gitlab-ctl reconfigure를 사용하여 변경 사항을 적용하십시오.
  4. GitLab에서 Git 리포지토리 기능을 테스트하십시오.
  5. 마이그레이션한 후 이전 키를 구성에서 제거한 다음 gitlab-ctl reconfigure를 다시 실행하십시오.
  6. Gitaly 클러스터를 실행 중이면 권장 사항입니다. Praefect 리포지토리 검증을 다시 활성화 하려면 verification_interval: 0을 제거합니다.

새 구조는 이하에서 설명하고 이전 키는 새 키 위에 설명됩니다. 

gitaly['configuration'] = {
  # gitaly['socket_path']
  socket_path: ...,
  # gitaly['runtime_dir']
  runtime_dir: ...,
  # gitaly['listen_addr']
  listen_addr: ...,
  # gitaly['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # gitaly['tls_listen_addr']
  tls_listen_addr: ...,
  tls: {
    # gitaly['certificate_path']
    certificate_path: ...,
    # gitaly['key_path']
    key_path: ...,
  },
  # gitaly['graceful_restart_timeout']
  graceful_restart_timeout: ...,
  logging: {
    # gitaly['logging_level']
    level: ...,
    # gitaly['logging_format']
    format: ...,
    # gitaly['logging_sentry_dsn']
    sentry_dsn: ...,
    # gitaly['logging_ruby_sentry_dsn']
    ruby_sentry_dsn: ...,
    # gitaly['logging_sentry_environment']
    sentry_environment: ...,
    # gitaly['log_directory']
    dir: ...,
  },
  prometheus: {
    # gitaly['prometheus_grpc_latency_buckets']. The old value was configured as a string
    # such as '[0, 1, 2]'. The new value must be an array like [0, 1, 2].
    grpc_latency_buckets: ...,
  },
  auth: {
    # gitaly['auth_token']
    token: ...,
    # gitaly['auth_transitioning']
    transitioning: ...,
  },
  git: {
    # gitaly['git_catfile_cache_size']
    catfile_cache_size: ...,
    # gitaly['git_bin_path']
    bin_path: ...,
    # gitaly['use_bundled_git']
    use_bundled_binaries: ...,
    # gitaly['gpg_signing_key_path']
    signing_key: ...,
    # gitaly['gitconfig']. 이것은 여전히 배열입니다만 요소의 유형이 변경되었습니다.
    config: [
      {
        # 이전에 요소에는 'section'과 'subsection' 외에도 'key'가 포함되어 있었습니다. 이제
        # 이들은 모두 'key'로 연결되어야 하며, 점으로 구분되어야 합니다. 예를 들어,
        # {section: 'first', subsection: 'middle', key: 'last', value: 'value'}는
        # {key: 'first.middle.last', value: 'value'}로 되어야 합니다.
        key: ...,
        value: ...,
      },
    ],
  },
  # 이전에 gitaly['storage'] 또는 'git_data_dirs'를 통해 저장소를 구성할 수 있었습니다.
  # 관련 구성을 아래 지침에 따라 마이그레이션하십시오.
  # 'git_data_dirs'의 경우 'path'만을 gitaly['configuration']로 이동하고 나머지는 그대로 둡니다.
  storage: [
    {
      # gitaly['storage'][<index>]['name']
      #
      # git_data_dirs[<name>]. 저장소 이름은 맵의 키로 구성되었습니다.
      name: ...,
      # gitaly['storage'][<index>]['path']
      #
      # git_data_dirs[<name>]['path']. 'git_data_dirs[<name>]['path']' 값 사용하고 '/repositories'를 추가하십시오.
      #
      # 예를 들어, 'git_data_dirs'의 경로가 '/var/opt/gitlab/git-data'인 경우, '/var/opt/gitlab/git-data/repositories'를 사용하십시오.
      # '/repositories' 확장은 'git_data_dirs'에서 구성된 경로에 자동으로 추가됩니다.
      path: ...,
    },
  ],
  hooks: {
    # gitaly['custom_hooks_dir']
    custom_hooks_dir: ...,
  },
  daily_maintenance: {
    # gitaly['daily_maintenance_disabled']
    disabled: ...,
    # gitaly['daily_maintenance_start_hour']
    start_hour: ...,
    # gitaly['daily_maintenance_start_minute']
    start_minute: ...,
    # gitaly['daily_maintenance_duration']
    duration: ...,
    # gitaly['daily_maintenance_storages']
    storages: ...,
  },
  cgroups: {
    # gitaly['cgroups_mountpoint']
    mountpoint: ...,
    # gitaly['cgroups_hierarchy_root']
    hierarchy_root: ...,
    # gitaly['cgroups_memory_bytes']
    memory_bytes: ...,
    # gitaly['cgroups_cpu_shares']
    cpu_shares: ...,
    repositories: {
      # gitaly['cgroups_repositories_count']
      count: ...,
      # gitaly['cgroups_repositories_memory_bytes']
      memory_bytes: ...,
      # gitaly['cgroups_repositories_cpu_shares']
      cpu_shares: ...,
    }
  },
  # gitaly['concurrency']. 구조는 같지만 배열 요소의 문자열 키는 다른 곳처럼 심볼로 바뀌어야 합니다. {'key' => 'value'}는 {key: 'value'}로 바꾸십시오.
  concurrency: ...,
  # gitaly['rate_limiting']. 구조는 같지만 배열 요소의 문자열 키는 다른 곳처럼 심볼로 바뀌어야 합니다. {'key' => 'value'}는 {key: 'value'}로 바꾸십시오.
  rate_limiting: ...,
  pack_objects_cache: {
    # gitaly['pack_objects_cache_enabled']
    enabled: ...,
    # gitaly['pack_objects_cache_dir']
    dir: ...,
    # gitaly['pack_objects_cache_max_age']
    max_age: ...,
  }
}

Praefect 구성 구조 변경

리눅스 패키지에서 Praefect 구성 구조는 변경되어 GitLab 16.0에서 자체 컴파일된 설치에 사용된 Praefect 구성 구조와 일관성을 유지합니다.

이 변경으로 praefect['configuration'] 아래의 단일 해시가 대부분의 Praefect 구성을 보유합니다. 일부 praefect['..'] 구성 옵션은 GitLab 16.0 이후에도 계속 사용됩니다:

  • enable
  • dir
  • log_directory
  • env_directory
  • env
  • wrapper_path
  • auto_migrate
  • consul_service_name

기존 구성을 새 구조로 이동하여 마이그레이션하십시오. 새 구조는 GitLab 15.9에서 지원됩니다.

새 구조로 마이그레이션

경고: 우선 Praefect를 새 구성 구조로 마이그레이션하십시오. 이 변경을 테스트한 후, Gitaly 노드를 계속 진행하십시오. Gitaly가 구성 구조의 일부로 잘못 구성된 경우 리포지토리 검사 는 Gitaly 클러스터의 작동에 필요한 메타데이터를 삭제할 수 있습니다. 구성 실수에 대비하여 Praefect에서 임시로 리포지토리 검사를 비활성화하십시오.

  1. 구성에 새 구조를 적용할 때:
    • ...을 이전 키의 값을으로 대체하십시오.
    • 아래에 표시된대로 verification_interval: 0를 사용하여 리포지토리 검사를 비활성화하십시오.
    • 이전에 값을 구성하지 않은 키를 건너뛰십시오.
    • 모든 해시 키에 trailing 쉼표를 추가하여 키가 다시 정렬되거나 추가 키가 추가되어도 해시가 유효하도록 하십시오.
  2. gitlab-ctl reconfigure를 사용하여 변경 사항을 적용하십시오.
  3. GitLab에서 Git 리포지토리 기능을 테스트하십시오.
  4. 마이그레이션이 완료되면 이전 키를 구성에서 제거한 다음 gitlab-ctl reconfigure를 다시 실행하십시오.

새 구조는 새 키 위에 설명된 이전 키를 포함하는 주석과 함께 아래에 문서화되어 있습니다. 

praefect['configuration'] = {
  # praefect['listen_addr']
  listen_addr: ...,
  # praefect['socket_path']
  socket_path: ...,
  # praefect['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # praefect['tls_listen_addr']
  tls_listen_addr: ...,
  # praefect['separate_database_metrics']
  prometheus_exclude_database_from_default_metrics: ...,
  auth: {
    # praefect['auth_token']
    token: ...,
    # praefect['auth_transitioning']
    transitioning: ...,
  },
  logging: {
    # praefect['logging_format']
    format: ...,
    # praefect['logging_level']
    level: ...,
  },
  failover: {
    # praefect['failover_enabled']
    enabled: ...,
  },
  background_verification: {
    # praefect['background_verification_delete_invalid_records']
    delete_invalid_records: ...,
    # praefect['background_verification_verification_interval']
    #
    # 중요:
    # Praefect 재구성의 일부로이 기능을 비활성화하십시오.
    # 위에서 읽으십시오.
    #
    verification_interval: 0,
  },
  reconciliation: {
    # praefect['reconciliation_scheduling_interval']
    scheduling_interval: ...,
    # praefect['reconciliation_histogram_buckets']. 이전 값을 '[0, 1, 2]'와 같이 문자열로 구성했습니다.
    # 새 값은 [0, 1, 2]와 같은 배열이어야 합니다.
    histogram_buckets: ...,
  },
  tls: {
    # praefect['certificate_path']
    certificate_path: ...,
   # praefect['key_path']
    key_path: ...,
  },
  database: {
    # praefect['database_host']
    host: ...,
    # praefect['database_port']
    port: ...,
    # praefect['database_user']
    user: ...,
    # praefect['database_password']
    password: ...,
    # praefect['database_dbname']
    dbname: ...,
    # praefect['database_sslmode']
    sslmode: ...,
    # praefect['database_sslcert']
    sslcert: ...,
    # praefect['database_sslkey']
    sslkey: ...,
    # praefect['database_sslrootcert']
    sslrootcert: ...,
    session_pooled: {
      # praefect['database_direct_host']
      host: ...,
      # praefect['database_direct_port']
      port: ...,
      # praefect['database_direct_user']
      user: ...,
      # praefect['database_direct_password']
      password: ...,
      # praefect['database_direct_dbname']
      dbname: ...,
      # praefect['database_direct_sslmode']
      sslmode: ...,
      # praefect['database_direct_sslcert']
      sslcert: ...,
      # praefect['database_direct_sslkey']
      sslkey: ...,
      # praefect['database_direct_sslrootcert']
      sslrootcert: ...,
    }
  },
  sentry: {
    # praefect['sentry_dsn']
    sentry_dsn: ...,
    # praefect['sentry_environment']
    sentry_environment: ...,
  },
  prometheus: {
    # praefect['prometheus_grpc_latency_buckets']. 이전 값은 '[0, 1, 2]'와 같은 문자열로 구성되었습니다.
    # 새 값은 [0, 1, 2]와 같은 배열이어야 합니다.
    grpc_latency_buckets: ...,
  },
  # praefect['graceful_stop_timeout']
  graceful_stop_timeout: ...,
  # praefect['virtual_storages']. 이전 값은 해시 맵이지만 새 값은 배열입니다.
  virtual_storage: [
    {
      # praefect['virtual_storages'][가상 저장소 이름]. 이전에 이름은 '가상 저장소' 해시의 키였습니다.
      name: ...,
      # praefect['virtual_storages'][가상 저장소 이름]['nodes'][노드 이름]. 이전 값은 해시 맵이지만 새 값은 배열입니다.
      node: [
        {
          # praefect['virtual_storages'][가상 저장소 이름]['nodes'][노드 이름]. 노드 이름 키를 저장소로 사용합니다.
          storage: ...,
          # praefect['virtual_storages'][가상 저장소 이름]['nodes'][노드 이름]['address']
          address: ...,
          # praefect['virtual_storages'][가상 저장소 이름]['nodes'][노드 이름]['token']
          token: ...,
        },
      ],
    }
  ]
}


## 긴 실행 사용자 유형 데이터 변경

GitLab 16.0은 `users` 테이블에 많은 레코드를 가진 대규모 GitLab 인스턴스에 대한 필수 업데이트입니다.

장벽은 **30,000명의 사용자**로, 다음을 포함합니다:

- 활성, 차단, 승인 대기 중인 개발자 및 기타 사용자.
- 프로젝트 및 그룹 액세스 토큰을 위한 봇 계정.

GitLab 16.0에서는 [일괄 배경 마이그레이션](../background_migrations.md#batched-background-migrations)을 도입하여
[`user_type` 값을 `NULL`에서 `0`으로 마이그레이션](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115849)했습니다. 이 마이그레이션은 대규모 GitLab 인스턴스에서 완료되기까지 여러 날이 걸릴 수 있습니다. 16.1.0 이상으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

GitLab 16.1에서는 `FinalizeUserTypeMigration` 마이그레이션을 도입하여
16.0 `MigrateHumanUserType` 배경 마이그레이션이 완료되도록 보장하고, 완료되지 않은 경우 업그레이드 중에 16.0 변경을 동기적으로 실행합니다.

GitLab 16.2는 [`NOT NULL` 데이터베이스 제약조건을 구현](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122454)하여 16.0 마이그레이션이 완료되지 않았을 경우 실패합니다. 

16.0이 건너뛰어졌거나(또는 16.0 마이그레이션이 완료되지 않은 경우), 이후의
Linux 패키지(Omnibus) 및 Docker 업그레이드가 1시간 후에 실패할 수 있습니다:

```plaintext
FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

이 문제에 대한 정방향 제안이 있습니다.

이 문제에 대한 임시 해결책이 완료될 동안, GitLab은 데이터베이스 변경이 완료되었을 때 ‘500’ 오류를 생성할 수 있으므로 사용할 수 없는 상태에 있습니다. 이 오류는 Sidekiq와 Puma가 데이터베이스 스키마와 호환되지 않는 어플리케이션 코드를 실행하고 있기 때문에 발생합니다.

이 임시 해결책 과정이 끝나면, Sidekiq와 Puma가 해당 문제를 해결하기 위해 재시작됩니다.

16.2 이상으로 업그레이드 시 정의되지 않은 열 오류

GitLab 15.11의 버그로 인해 자체 호스팅된 인스턴스에서 데이터베이스 변경이 잘못 비활성화되었습니다. 자세한 정보는 issue 408835를 참조하세요.

만약 GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드된 경우 데이터베이스 스키마가 올바르지 않아 GitLab 16.2 이상으로 업그레이드가 오류로 실패합니다. 데이터베이스 변경은 이전 수정 사항이 있어야합니다: 

PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

GitLab 15.11.3은 이 버그에 대한 수정을 적용했지만, 이미 이전 15.11 릴리스를 실행 중인 인스턴스에서는 문제를 해결하지 않습니다.

인스턴스가 영향을 받았는지 확실하지 않은 경우, 데이터베이스 콘솔에서 다음 열을 확인하세요: 

select pg_typeof (id_convert_to_bigint) from public.ci_build_needs limit 1;

이 주요한 문제에 대한 임시 해결책이 필요한 경우, 이 쿼리가 실패합니다: 

ERROR:  column "id_convert_to_bigintd" does not exist
LINE 1: select pg_typeof (id_convert_to_bigintd) from public.ci_buil...

영향을 받지 않은 인스턴스는 다음과 같이 반환합니다: 

 pg_typeof
-----------
 bigint

이 문제에 대한 임시 해결책은 GitLab 인스턴스의 데이터베이스 스키마에 따라 다릅니다:

설치 버전 임시 해결
15.9 이하 15.9
15.10 15.10
15.11 15.11

대부분의 인스턴스는 15.9 프로시저를 사용해야 합니다. 매우 새로운 인스턴스만 15.10 또는 15.11 프로시저를 필요로 합니다. 백업과 복원을 사용하여 GitLab을 마이그레이션한 경우, 데이터베이스 스키마는 원본 인스턴스에서 가져옵니다. 소스 인스턴스에 따라 임시 해결책을 선택하세요.

다음 섹션의 명령은 Linux 패키지 설치용이며, 다른 설치 유형에 대해 다릅니다:

Docker
  • sudo를 생략합니다.

  • GitLab 컨테이너에 셸을 실행하고 동일한 명령을 실행합니다: 

    docker exec -it <container-id> bash
Self-compiled (source)
Helm chart (Kubernetes)

해결책: 15.9 이전에 생성된 인스턴스 

# 스키마 복원
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version IN ('20230130175512', '20230130104819');"
sudo gitlab-rake db:migrate:up VERSION=20230130175512
sudo gitlab-rake db:migrate:up VERSION=20230130104819

# 백그라운드 마이그레이션 재스케줄링
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:down VERSION=20230130110855
sudo gitlab-rake db:migrate:up VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130110855

해결책: 15.10에 생성된 인스턴스 

# sent_notifications를 위한 스키마 복원
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version = '20230130175512';"
sudo gitlab-rake db:migrate:up VERSION=20230130175512

# sent_notifications를 위한 백그라운드 마이그레이션 재스케줄링
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130202201

# ci_build_needs를 위한 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"

해결책: 15.11에 생성된 인스턴스 

# sent_notifications를 위한 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230411153310
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230411153310');"

# ci_build_needs를 위한 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"