15.11에서 업그레이드할 때 주의할 사항
- Linux 패키지 설치
16.10.0
- Linux 패키지 설치
16.9.0
- Geo 설치
16.8.0
- Geo 설치
16.7.0
- Linux 패키지 설치
- Geo 설치
16.6.0
- Geo 설치
16.5.0
- Linux 패키지 설치
- Geo 설치
16.4.0
- 자체 컴파일 설치
- Geo 설치
16.3.0
- Linux 패키지 설치
- Geo 설치
16.2.0
16.1.0
- 자체 컴파일 설치
- Geo 설치
  - 프로젝트 생성 시 초기화되지 않은 위키 리포지터리
16.0.0
16.2 이상으로 업그레이드 시 정의되지 않은 열 오류

GitLab 16 변경 사항

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

이 페이지에는 GitLab 16의 마이너 및 패치 버전에 대한 업그레이드 정보가 포함되어 있습니다. 다음과 같은 명령을 확인하십시오.

귀하의 설치 유형
현재 버전과 대상 버전 사이의 모든 버전

GitLab Helm 차트를 업그레이드하는 자세한 내용은 릴리스 노트: 7.0를 참조하십시오.

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

GitLab 16부터는 PostgreSQL 12가 지원되지 않습니다. GitLab 16.0 이상으로 업그레이드하기 전에 PostgreSQL을 적어도 버전 13.6으로 업그레이드하십시오.
GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드된 경우 데이터베이스 스키마가 잘못되었습니다. 16.x로 업그레이드하기 전에 일시적인 대책을 수행하십시오.
대부분의 설치는 16.3에서 시작해야 하므로 16.0, 16.1 및 16.2를 건너뛸 수 있습니다. 모든 경우에 이러한 중간 버전에 대한 노트를 검토해야 합니다.
일부 GitLab 설치는 사용되는 기능과 환경의 크기에 따라 해당 중간 버전에서 멈춰야 할 수도 있습니다.
- 16.0.8: 사용자 테이블에 많은 레코드가 있는 인스턴스입니다. 자세한 내용은 장시간 사용자 유형 데이터 변경을 참조하십시오.
- 16.1.5: NPM 패키지 레지스트리를 사용하는 인스턴스입니다.
- 16.2.8: 파이프라인 변수가 많은 인스턴스(히스토리적인 파이프라인 포함).
인스턴스가 영향을 받는 경우 이러한 중단 지점을 건너뛴다면:
- 업그레이드에 몇 시간이 걸릴 수 있습니다.
- 데이터베이스 변경이 완료될 때까지 인스턴스는 500 오류를 생성하며, 그 후에는 Puma와 Sidekiq을 다시 시작해야 합니다.
- Linux 패키지 설치의 경우 시간 초과가 발생하고 매뉴얼 대응이 필요합니다 완료하기 위한 데이터베이스 마이그레이션이 필요합니다.
GitLab 16.0에서 프로젝트 크기에 대한 제한을 강제로 변경했습니다. Self-managed에서 이러한 제한을 사용하는 경우, 제한에 도달한 프로젝트는 동일 그룹의 영향을 받지 않는 Git 리포지터리에 푸시할 때 오류 메시지가 발생합니다. 오류는 종종 0바이트의 제한(limit of 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 패키지 설치

GitLab 16로 업그레이드하기 전 Gitaly와 Praefect 구성 구조를 변경해야 합니다. 데이터 손실을 피하기 위해 먼저 Praefect를 다시 구성하고, 새 구성의 일환으로 메타데이터 확인을 비활성화하십시오. 자세히 읽기:
- Praefect 구성 구조 변경.
- Gitaly 구성 구조 변경.
/var/opt/gitlab/git-data/repositories 외의 위치에 Git 데이터를 저장하도록 Gitaly를 다시 구성하는 경우, 패키지화된 GitLab 16.0 이후에는 디렉터리 구조가 자동으로 생성되지 않습니다. 문제 자세히 보기 및 임시 방안을 읽으십시오.

16.10.0

Linux 패키지 설치

GitLab 16.10의 Linux 패키지 설치에는 Patroni의 새 주 버전인 버전 3.0.1로의 업그레이드가 포함됩니다.

만약 참조 아키텍처 중 하나를 사용하여 고가용성(HA) (3천 명 이상 사용자)을 활성화하고 있다면, Patroni를 사용하는 Linux 패키지 설치용 PostgreSQL 복제 및 장애 조치가 사용 중입니다.

이 경우, 다운 타임으로 멀티노드 업그레이드에 대한 자세한 내용을 읽어보세요.

버전 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에서 도입된 버그로 개인 스니펫이 2차 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.8 16.8.0 - 16.8.3 16.8.4
16.9 16.9.0 - 16.9.1 16.9.2

영향을 받는 마이너 릴리스	영향을 받는 패치 릴리스	수정된 버전
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은 더 이상 지원되지 않으므로 Redis 6.2 이상으로 업그레이드해야 합니다.

일반적으로 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 설치

GitLab 16.7 및 그 이후의 신규 설치에 대해 PostgreSQL 버전 14가 기본값으로 설정됩니다. 이미 존재하는 Geo 2차 사이트는 PostgreSQL 버전 14로 업그레이드할 수 없습니다. 자세한 정보는 이슈 7768를 참조하세요. 모든 Geo 사이트는 동일한 버전의 PostgreSQL을 실행해야 합니다. 16.7에서 16.8.1로 새로운 Geo 2차 사이트를 추가하려면 구성에 따라 다음 작업 중 하나를 수행해야 합니다:
- 첫 번째 Geo 2차 사이트를 추가하려면: 새로운 Geo 2차 사이트를 설정하기 전에 기본 사이트를 PostgreSQL 14로 업그레이드하세요. 기본 사이트가 이미 PostgreSQL 14를 실행 중인 경우 별도의 조치가 필요하지 않습니다.
- 기존의 하나 이상의 Geo 2차 사이트가 모두 PostgreSQL 13을 실행 중인 경우, 새로운 Geo 2차 사이트를 고정된 PostgreSQL 버전 13으로 설치하세요.
- 기존의 모든 사이트가 PostgreSQL 14를 실행 중인 경우: 별도의 조치가 필요하지 않습니다.
- 새로운 Geo 2차 사이트를 배포에 추가하기 전에 모든 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드하세요.

영향을 받는 릴리스:

영향을 받는 마이너 릴리스	영향을 받는 패치 릴리스	수정된 버전
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

조회된 개인 스니펫 데이터의 손실과 관련하여 기본 사이트와 2차 사이트 간 체크섬 불일치로 일부 컨테이너 레지스트리 이미지의 확인 실패가 발생할 수 있습니다. Issue 442667에서 자세한 내용을 확인할 수 있습니다. 데이터가 2차 사이트로 정확하게 복제되고 있지만 확인되지 않는 상황으로 직접적인 데이터 손실 위험이 없습니다. 현재 알려진 해결책이 없습니다.
영향을 받는 릴리스:

영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전

16.8 16.8.0 - 16.8.3 16.8.4
16.9 16.9.0 - 16.9.1 16.9.2

영향을 받는 마이너 릴리스	영향을 받는 패치 릴리스	수정된 버전
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 및 이전에 도입된 모든 데이터베이스 변경 사항이 모든 Self-managed 인스턴스에 적용되었음을 보장합니다. 이후에 종속 변경 내용은 GitLab 16.8 및 이후에 릴리스될 수 있습니다. Issue 429611에서 자세한 내용을 확인할 수 있습니다.

보통, PgBouncer가 있는 환경에서 백업을 수행하려면 GITLAB_BACKUP_으로 접두사가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 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

Linux 패키지 설치

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

GitLab 16.7부터 PostgreSQL 14가 Linux 패키지와 함께 기본 버전으로 설치됩니다. 패키지 업그레이드 중에 데이터베이스는 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를 실행 중이면 특별히 필요한 조치는 없습니다.
- 기존 1개 이상의 Geo 보조 사이트를 보유하고 새로운 Geo 보조 사이트를 추가 중인 경우:
  - 모든 기존 사이트가 PostgreSQL 13을 실행 중인 경우: 고정된 PostgreSQL 버전 13으로 새로운 Geo 보조 사이트를 설치하십시오.
  - 모든 기존 사이트가 PostgreSQL 14를 실행 중인 경우: 특별히 필요한 조치는 없습니다.
  - 기존 사이트를 모두 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드한 후에 기존의 기능에 새로운 Geo 보조 사이트를 추가하십시오.
기존 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트에서 검증 실패가 발생할 수 있습니다. 자세한 내용은 이 이슈에서 추적됩니다. 데이터가 보조 사이트로 올바르게 복제되고 있으므로 데이터 유실 가능성은 없습니다. 영향을 받은 프로젝트를 보조 Geo 사이트에서 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재는 알려진 해결 방법이 없습니다. 문제를 해결하고 있습니다.
영향을 받는 릴리스:

영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 릴리스

16.4 All 없음
16.5 All 없음
16.6 16.6.0 - 16.6.5 16.6.6
16.7 16.7.0 - 16.7.3 16.7.4

영향을 받는 마이너 릴리스	영향을 받는 패치 릴리스	수정된 릴리스
16.4	All	없음
16.5	All	없음
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	All	없음
16.6	All	없음
16.7	All	없음
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

이전 CI Environment destroy jobs may be spawned를 업그레이드한 후 GitLab 16.6에서 발생할 수 있습니다.

보통 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 설치

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

영향받는 마이너 릴리스 영향받는 패치 릴리스 수정된 릴리스

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.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 이상으로 업그레이드하면 문제가 해결됩니다.
unique_batched_background_migrations_queued_migration_version 인덱스가 16.5에서 도입되었으며, 포스트 배포 마이그레이션 DeleteOrphansScanFindingLicenseScanningApprovalRules2는 이 고유 제약을 깨뜨릴 수 있습니다. 이 문제에서 사용 가능한 해결책은 다음과 같은 오류를 수정합니다:
```
PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint
"unique_batched_background_migrations_queued_migration_version"
DETAIL:  Key (queued_migration_version)=(20230721095222) already exists.
```

영향 받는 릴리스:

영향받는 마이너 릴리스	영향받는 패치 릴리스	수정된 릴리스
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 패키지 설치

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 설치

특정 정보는 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에 Object storage verification가 추가되었습니다. 이슈로 인해 일부 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	16.4.0 - 16.4.2	16.4.3
16.5	16.5.0 - 16.5.1	16.5.2

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

영향 받는 소수 릴리스	영향 받는 패치 릴리스	수정 버전
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.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

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

;; `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] 시크릿 파일을 GitLab 시크릿 토큰에 대한 경로를 구성하세요.
2. 사용자 정의 후크가 있는 경우, 구성을 업데이트하여 [hooks] custom_hooks_dir를 서버 측 사용자 정의 후크에 대한 경로를 구성하세요.
3. [gitlab-shell] dir 구성을 제거하세요.

Geo 설치

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을 참조하세요.

Object storage verification가 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
동기화 상태가 대기 상태로 멈추는 문제는 영향 받는 항목의 복제가 영원히 멈추게하여 장애 발생 시 데이터 손실 위험을 초래합니다. 이는 주로 리포지터리 동기화에 영향을 줄 수 있지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실 위험을 피하기 위해 수정된 버전으로 업그레이드하는 것이 좋습니다.
영향 받는 릴리스:

영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정된 버전

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.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.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

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

영향 받는 마이너 릴리스	영향 받는 패치 릴리스	수정된 버전
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 이상으로 업데이트하십시오. 이는 GitLab 16.3.3 및 16.3.4의 데이터베이스 디스크 공간의 과도한 사용을 일으키는 issue 425971을 피합니다.
중복 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 인스턴스에서 오랜 시간이 걸릴 수 있습니다 (1건에서 5000만 행의 처리에 4시간이 소요된 경우가 있음). 오랜 업그레이드 다운타임을 피하기 위해 업그레이드 전에 마이그레이션이 성공적으로 완료되었는지 확인하십시오.
데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다:
```
select count(*) from ci_pipeline_variables;
```

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

영향을 받는 릴리스:

영향을 받는 마이너 릴리스	영향을 받는 패치 릴리스	수정된 버전
15.11	All	None
16.0	All	None
16.1	All	None
16.2	All	None
16.3	All	None
16.4	All	None
16.5	All	None
16.6	All	None
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에서 공지한 기본 도커 이미지가 업그레이드되어 OpenSSH 서버의 새 버전을 포함하고 있습니다. 새 버전의 의도하지 않은 결과로, 기본적으로 SSH RSA SHA-1 서명을 수락하지 않습니다. 이 문제는 매우 오래된 SSH 클라이언트를 사용하는 사용자에게만 영향을 미칠 것으로 예상됩니다.
SHA-1 서명이 사용 불가능한 문제를 피하려면 보안 상의 이유로 SHA-1 서명의 사용을 권장하지 않기 때문에 SSH 클라이언트를 업데이트해야 합니다.
사용자들이 즉시 SSH 클라이언트를 업그레이드하지 못하는 과도한 기간을 허용하기 위해, GitLab 16.3 이후는 Dockerfile에서 GITLAB_ALLOW_SHA1_RSA 환경 변수를 지원합니다. GITLAB_ALLOW_SHA1_RSA가 true로 설정된 경우, 이 지원이 다시 활성화됩니다.
우리는 보안 모범 사례를 실현하고 상위 버전 라이브러리를 따르기를 원하기 때문에, 이 환경 변수는 GitLab 17.0에서 지원이 중단될 때까지만 사용할 수 있습니다.
더 많은 정보는 다음을 참조하십시오:
- OpenSSH 8.8 릴리스 노트.
- 비공식 설명.
- omnibus-gitlab Merge Request 7035, 환경 변수를 도입합니다.

Geo 설치

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

Geo를 사용하여 Git 프로젝트를 가속화하는 원격 사용자의 Git 풀 요청이 주 서버로 프록시되는 문제가 있습니다. 해당 명령및 버전:
- 영향을 받는 버전:
  - 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를 참조하십시오.

issue 419370로 인해 보류 중 상태의 동기화 상태가 영구적으로 막혀 데이터 손실의 위험이 발생할 수 있습니다. 이는 주로 리포지터리 동기화에 영향을 미치지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실의 위험을 피하기 위해 수정된 버전으로 업그레이드하는 것이 좋습니다.
영향을 받는 릴리스:

영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전

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 내에서 이러한 누락된 리포지터리에 대한 잘못된 내부 상태로 인해 로그에서 오류가 발생하고 검증 진행 상태가 이러한 그룹 위키 리포지터리에 대해 실패한 상태로 표시됩니다.
문제의 세부 정보 및 해결 방법은 [issue #426571]]를 참조하십시오.
영향을 받는 릴리스:

영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전

16.3 All None
16.4 All None
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

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

16.2.0

Legacy 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:  relation "ci_build_needs"의 "id_convert_to_bigint" 열이 존재하지 않습니다
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...
```
자세한 내용 및 해결 방법은 세부 정보 및 해결 방법을 참조하십시오.

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:  relation "users"의 "check_0dd5948e38" 체크 제약 조건이 몇 가지 행에 의해 위배됨

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

GitLab 16.2 이상으로 업그레이드 후 다음 오류가 발생할 수 있습니다:
```
PG::NotNullViolation: ERROR:  relation "ci_sources_pipelines"의 "source_partition_id" 열에 null 값이 not-null 제약 조건을 위배합니다
```
이 문제를 해결하려면 Sidekiq 및 Puma 프로세스를 다시 시작해야 합니다.

일반적으로 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.2부터 PostgreSQL 13.11 및 14.8이 모두 리눅스 패키지와 함께 제공됩니다. 패키지 업그레이드 중에 데이터베이스가 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의 일부로 자동으로 다시 시작되지 않습니다. 따라서 사용자는 reconfigure 실행 후 새로운 Redis 버전을 사용하도록하기 위해 sudo gitlab-ctl restart redis를 매뉴얼으로 실행해야 합니다. 다시 시작이 수행될 때까지 설치된 Redis 버전이 실행 중인 버전과 다르다는 경고가 표시됩니다.
인스턴스가 Sentinel을 사용한 Redis HA를 가지고 있는 경우 Zero Downtime documentation에 나온 업그레이드 단계를 따르십시오.

자체 컴파일 설치

Gitaly에서는 Git 2.41.0 이상이 필요합니다. Gitaly에서 제공된 Git 버전을 사용해야 합니다.

Geo 설치

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

새로운 작업 artifacts는 JOB artifacts가 객체 리포지터리에 저장되도록 구성되어 있고 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.
- 영향을 받는 버전을 실행하는 동안, 동기화된 것으로 보이는 artifacts이 실제로는 이차 사이트에서 누락될 수 있습니다. 영향을 받은 artifacts는 16.1.5, 16.2.5, 16.3.1, 16.4.0 이상으로 업그레이드하면 자동으로 재동기화됩니다. 필요한 경우 영향을 받는 작업 artifacts를 매뉴얼으로 재동기화할 수 있습니다.

보조 사이트에서 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은 배치 배경 마이그레이션을 도입하여 merge_requests 테이블의 prepared_at 값을 백필하는 것을 백필합니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 여러 날이 소요될 수 있습니다. 마이그레이션이 성공적으로 완료된 것을 확인하고 16.1.0으로 업그레이드하기 전에 반드시 확인하십시오.
GitLab 16.1.0에는 배치 배경 마이그레이션인 MarkDuplicateNpmPackagesForDestruction를 통해 중복 NPM 패키지를 표시하는 기능이 포함되어있습니다. 해당 마이그레이션이 성공적으로 완료된 것을 확인하고 16.3.0 이상으로 업그레이드하기 전에 반드시 확인하십시오.
BackfillCiPipelineVariablesForBigintConversion 배경 마이그레이션이 EnsureBackfillBigintIdIsCompleted 배포 후 마이그레이션과 함께 완료되었습니다. GitLab 16.0.0은 배치 배경 마이그레이션을 도입하여 ci_pipeline_variables 테이블의 bigint id 값을 백필하는 것을 백필합니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 시간이 오래 걸릴 수 있습니다 (한 사례에서 4 시간 동안 5000만 행을 처리했습니다). 오래 지속되는 업그레이드 다운 타임을 피하기 위해 업그레이드하기 전에 마이그레이션이 성공적으로 완료된 것을 확인하십시오.
데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다:
```
select count(*) from ci_pipeline_variables;
```

자체 컴파일 설치

puma.rb 구성 파일에서 Puma 워커 킬러와 관련된 설정을 제거해야합니다. 왜냐하면 해당 내용이 제거되었기 때문입니다. 자세한 내용은 puma.rb.example 파일을 참조하십시오.

일반적으로 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

Geo 설치

Tier: Premium, Ultimate 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	전부	없음
16.0	전부	없음
16.1	16.1.0 - 16.1.2	16.1.3 이후

일부 프로젝트 가져오기는 프로젝트 생성 시 위키 리포지터리를 초기화하지 않습니다. 프로젝트 위키가 SSF로 마이그레이션된 이후, 누락된 위키 리포지터리가 검증 실패로 잘못 표시됩니다. 이는 실제 복제/검증 실패의 결과가 아니라 Geo 내의 이러한 누락된 리포지터리의 잘못된 내부 상태로, 로그 및 검증 진행에서 이러한 위키 리포지터리에 대해 실패한 상태로 보고되는 오류를 일으킵니다. 프로젝트를 가져오지 않은 경우에는 이 문제의 영향을 받지 않습니다.

16.0.0

/etc/gitlab/gitlab.rb 파일에 비 ASCII 문자가 있는 경우 Sidekiq가 충돌합니다. issue 412767의 해결 방법을 따라 수정할 수 있습니다.
Sidekiq 작업은 기본적으로 default 및 mailers 대기열로만 라우팅되며 그 결과로, 모든 Sidekiq 프로세스는 모든 대기열에서 작업이 처리되도록 대기합니다. 이 동작은 라우팅 규칙을 구성하지 않은 경우 적용되지 않습니다.
GitLab Docker 이미지를 실행하려면 Docker 20.10.10 이상이 필요합니다. 오래된 버전은 시작 시 오류를 발생시킵니다.
16.0부터 GitLab 자체 설치는 기본적으로 두 개의 데이터베이스 연결을 갖고 있으며, 이전에 하나였던 것보다 두 배의 PostgreSQL 연결 수를 갖습니다. 이 변경으로 GitLab의 자체 설치 버전은 GitLab.com과 유사하게 작동하게 되었으며, GitLab의 자체 설치 버전에서 CI 기능을 위한 별도의 데이터베이스 가능성을 향상시키기 위한 단계입니다. 16.0으로 업그레이드하기 전에 PostgreSQL의 최대 연결 수를 증가시켜야 하는지 확인하세요.
- 이 변경은 리눅스 패키지(Omnibus) 설치 방법, GitLab Helm 차트, GitLab Operator, GitLab Docker 이미지 및 자체 컴파일된 설치에 대한 적용됩니다.
- 두 번째 데이터베이스 연결은 다음과 같이 비활성화할 수 있습니다:
Azure 리포지터리를 사용하는 컨테이너 레지스트리에는 태그가 없는 경우가 있습니다. 중단 변경지침을 따라 수정할 수 있습니다.

보통 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

리눅스 패키지 설치

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

PostgreSQL 12에 대한 이진 파일이 제거되었습니다. 업그레이드하기 전에, 리눅스 패키지 설치의 관리자는 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 구성을 새 구조로 마이그레이션하여 모든 praefect['..'] 설정이 GitLab 16.0 및 이후에 계속 작동하도록 해야 합니다.
Gitaly 구성을 새 구조로 마이그레이션하여 모든 gitaly['..'] 설정이 GitLab 16.0 및 이후에 계속 작동하도록 해야 합니다.

Geo 설치

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

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

프로젝트 가져오기 중 일부는 프로젝트 생성 시 위키 리포지터리를 초기화하지 않습니다. 자세한 정보 및 해결책은 세부 정보 및 해결책을 참조하십시오.
보조 사이트에서 LFS 객체를 복제할 때 보조 사이트가 완전히 동기화되었더라도 기본 사이트에서 다운로드합니다. 자세한 내용 및 해결책은 세부 정보 및 해결책을 참조하십시오.

Gitaly 구성 구조 변경

리눅스 패키지 내의 Gitaly 구성 구조는 GitLab 16.0에서 변경되어 자체 컴파일된 설치에서 사용되는 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가 잘못 구성된 경우, 리포지터리 검증이 작동하도록 Gitaly 클러스터에 필요한 메타데이터를 삭제할 수 있습니다. 구성 오류를 방지하기 위해 Praefect에서 일시적으로 리포지터리 검증을 비활성화합니다.

Gitaly 클러스터를 실행 중인 경우, 모든 Praefect 노드에서 리포지터리 검증이 비활성화되었는지 확인합니다. verification_interval: 0를 구성하고 gitlab-ctl reconfigure로 적용합니다.
구성에 새 구조를 적용할 때
- ...를 이전 키의 값으로 대체합니다.
- storage를 구성할 때 git_data_dirs를 대체하려면 경로에 /repositories를 추가해야 합니다. 아래 설명 된대로 문서화된 것처럼. 이를 빠트리면 구성이 수정될 때까지 귀하의 Git 리포지터리에 액세스할 수 없습니다. 이러한 오구성은 메타데이터 삭제로 이어지며, 이는 리포지터리 검증 비활성화의 이유입니다.
- 이전에 값을 구성하지 않은 키를 건너뜁니다.
- 모든 해시 키에 대해 추가 키가 추가되어 재정렬되거나 키가 추가될 때 해시가 유효한 상태로 유지하려면 반드시 추가 쉼표를 포함하십시오.
gitlab-ctl reconfigure로 변경 사항을 적용합니다.
GitLab에서 Git 리포지터리 기능을 테스트합니다.
마이그레이션 후 이전 키를 구성에서 제거한 다음 gitlab-ctl reconfigure를 다시 실행하십시오.
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: ...,
  },
  # ...
}

Praefect 구성 구조 변경

Linux 패키지 내 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에서 일시적으로 리포지터리 확인을 비활성화하십시오.

구성에 새 구조를 적용할 때:
- ...를 이전 키의 값으로 대체합니다.
- 아래에 표시된 대로 verification_interval: 0를 사용하여 리포지터리 확인을 비활성화합니다.
- 이전에 값을 구성하지 않은 키는 건너뜁니다.
- 해시 키에 대한 추가 키가 추가되거나 순서가 다시 정렬될 때 해시가 유효하게 유지되도록 모든 해시 키에 후행 쉼표를 포함하는 것이 좋습니다.
gitlab-ctl reconfigure을 사용하여 변경을 적용하십시오.
GitLab에서 Git 리포지터리 기능을 테스트하십시오.
마이그레이션이 완료되면 구성에서 이전 키를 제거한 후 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'][가상 리포지터리 이름]. 이름이 이전에는 '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에서는 [`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에서는 [16.0 마이그레이션이 완료되지 않은 경우 실패하는 `NOT NULL` 데이터베이스 제약조건](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122454)이 구현되었습니다.

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

```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의 버그로 인해 Self-managed 인스턴스에서 데이터베이스 변경이 잘못되었습니다. 자세한 정보는 이슈 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 (소스)

sudo gitlab-rake 대신 sudo -u git -H bundle exec rake RAILS_ENV=production을 사용합니다.
당신의 PostgreSQL 데이터베이스 콘솔에서 SQL을 실행합니다.

Helm chart (쿠버네티스)

sudo를 생략합니다.
toolbox pod으로 쉘을 실행하여 Rake 명령을 실행합니다: gitlab-rake는 PATH에 없는 경우 /usr/local/bin에 있습니다.
- 자세한 내용은 쿠버네티스 치트 시트를 참조하십시오.
당신의 PostgreSQL 데이터베이스 콘솔에서 SQL을 실행합니다.

차선책: 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');"

GitLab 16 변경 사항

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

Linux 패키지 설치

16.10.0

Linux 패키지 설치

16.9.0

Geo 설치

16.8.0

Geo 설치

16.7.0

Linux 패키지 설치

Geo 설치

16.6.0

Geo 설치

16.5.0

Linux 패키지 설치

Geo 설치

16.4.0

자체 컴파일 설치

Geo 설치

16.3.0

Linux 패키지 설치

Geo 설치

16.2.0

리눅스 패키지 설치

자체 컴파일 설치

Geo 설치

보조 사이트에서 LFS 객체 복제시 보조가 완전히 동기화되었는데도 기본 사이트에서 다운로드하는 문제

16.1.0

자체 컴파일 설치

Geo 설치

프로젝트 생성 시 초기화되지 않은 위키 리포지터리

16.0.0

리눅스 패키지 설치

Geo 설치

Gitaly 구성 구조 변경

Praefect 구성 구조 변경

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

차선책: 15.9 이하로 생성된 인스턴스

임시 방편: 15.10으로 생성된 인스턴스

임시 방편: 15.11으로 생성된 인스턴스

도움말

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

도움받기