데이터베이스 설정

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

GitLab은 PostgreSQL 데이터베이스 관리 시스템만 지원합니다.

따라서 Linux 패키지 설치와 함께 사용할 데이터베이스 서버에는 두 가지 옵션이 있습니다:

Linux 패키지 설치에 포함된 패키지형 PostgreSQL 서버 사용(구성 필요 없음, 권장).
외부 PostgreSQL 서버 사용.

Linux 패키지에 함께 제공되는 PostgreSQL 데이터베이스 서비스 사용

다시 구성 및 PostgreSQL 재시작

일반적으로 Linux 패키지 설치는 해당 서비스의 구성 설정이 gitlab.rb 파일에서 변경되었을 경우 다시 구성하면 해당 서비스를 다시 시작합니다. PostgreSQL은 일부 설정이 다시 로드(HUP)할 때 즉시 적용되는 독특한 특성을 가지고 있습니다. 또 다른 일부 설정은 PostgreSQL을 다시 시작해야만 적용됩니다. 이러한 이유로 PostgreSQL을 언제 다시 시작할지를 관리자가 더 많은 제어를 원하기 때문에 Linux 패키지 설치는 다시 구성 시 PostgreSQL을 재시작하는 것이 아니라 다시 로드하도록 구성되어 있습니다. 따라서 만약 다시 시작이 필요한 PostgreSQL 설정을 수정하는 경우, 다시 구성 후 PostgreSQL을 수동으로 다시 시작해야 합니다.

GitLab 구성 템플릿에는 어떤 PostgreSQL 설정이 재시작을 필요로 하는 지, 단독으로 다시 로드할 수 있는지가 명시되어 있습니다. 또한 데이터베이스에서 다음과 같은 쿼리를 실행하여 개별 설정이 다시 시작을 필요로 하는 지 확인할 수 있습니다. sudo gitlab-psql로 데이터베이스 콘솔을 시작한 후 아래 쿼리의 <setting name>을 수정할 설정으로 대체하세요.

SELECT name,setting FROM pg_settings WHERE context = 'postmaster' AND name = '<setting name>';

설정을 변경하면 다시 시작이 필요한 경우, 해당 쿼리는 실행 중인 PostgreSQL 인스턴스에서 설정의 이름과 현재 값이 반환됩니다.

PostgreSQL 버전 변경 시 자동 재시작

기본적으로 Linux 패키지 설치는 기반 버전이 변경되면 자동으로 PostgreSQL을 다시 시작합니다. 이 동작은 postgresql 및 geo-postgresql에 대해 사용 가능한 auto_restart_on_version_change 설정을 통해 제어할 수 있습니다.

PostgreSQL 버전 변경 시 자동 재시작을 비활성화하려면:

/etc/gitlab/gitlab.rb를 편집하여 다음 라인을 추가하세요:

# For PostgreSQL/Patroni
postgresql['auto_restart_on_version_change'] = false

# For Geo PostgreSQL
geo_postgresql['auto_restart_on_version_change'] = false

GitLab을 다시 구성하세요:
```
sudo gitlab-ctl reconfigure
```

참고: 기반 버전이 변경될 때 PostgreSQL을 다시 시작하는 것이 권장되며, 필요한 라이브러리를 로드하는 데 관련된 오류와 같은 오류를 피하기 위함입니다.

SSL 구성

Linux 패키지 설치는 기본적으로 PostgreSQL 서버에서 SSL을 자동으로 활성화하지만, 기본적으로 암호화된 및 암호화되지 않은 연결을 모두 허용합니다. SSL을 강제로 사용하려면 pg_hba.conf에서 hostssl 구성을 사용해야 합니다. 자세한 내용은 pg_hba.conf 문서를 참조하세요.

SSL 지원에는 다음 파일이 필요합니다:

데이터베이스의 공개 SSL 인증서(server.crt).
SSL 인증서에 대한 해당 개인 키(server.key).
서버의 SSL 인증서를 유효하게 하는 루트 인증서 번들(root.crt). Linux 패키지 설치는 기본적으로 /opt/gitlab/embedded/ssl/certs/cacert.pem에 포함된 임베디드 인증서 번들을 사용합니다. 이는 자체 서명된 인증서에는 필요하지 않습니다.

Linux 패키지 설치는 사용을 위해 10년 짜리 자체 서명된 인증서 및 개인 키를 생성합니다. CA로 서명된 인증서를 사용하거나 자체 서명된 인증서로 대체하려면 다음 단계를 사용하세요.

이러한 파일의 위치는 구성 가능하지만, 개인 키는 반드시 gitlab-psql 사용자가 읽을 수 있어야 합니다. Linux 패키지 설치는 파일의 권한을 관리해주지만, 경로가 사용자 정의된 경우 gitlab-psql이 파일을 액세스할 수 있도록 해야 합니다.

더 많은 세부 사항은 PostgreSQL 문서를 참조하세요.

server.crt 및 server.key는 GitLab에 액세스하기 위해 사용되는 기본 SSL 인증서와는 다를 수 있습니다. 예를 들어, 데이터베이스의 외부 호스트 이름이 database.example.com이고 외부 GitLab 호스트 이름이 gitlab.example.com인 경우 *.example.com에 대한 와일드카드 인증서 또는 두 개의 다른 SSL 인증서가 필요합니다.

ssl_cert_file, ssl_key_file, 및 ssl_ca_file 파일은 데이터베이스가 인증서, 키, 및 번들을 어디에서 찾아야 하는지를 PostgreSQL에 알려줍니다. 이러한 변경 사항은 postgresql.conf에 적용됩니다. internal_certificate와 internal_key 지시문은 이러한 파일의 내용을 채우는 데 사용됩니다. 내용은 직접 추가하거나 다음 예제에 표시된대로 파일에서 로드할 수 있습니다.

위의 파일을 보유한 후에 SSL을 활성화하세요:

/etc/gitlab/gitlab.rb를 편집하세요:

postgresql['ssl_cert_file'] = '/custom/path/to/server.crt'
postgresql['ssl_key_file'] = '/custom/path/to/server.key'
postgresql['ssl_ca_file'] = '/custom/path/to/bundle.pem'
postgresql['internal_certificate'] = File.read('/custom/path/to/server.crt')
postgresql['internal_key'] = File.read('/custom/path/to/server.key')

상대 경로는 기본적으로 PostgreSQL 데이터 디렉터리(/var/opt/gitlab/postgresql/data)에서 시작됩니다.

GitLab 다시 구성하여 구성 변경을 적용하세요.
변경 사항이 적용되도록 PostgreSQL을 다시 시작하세요:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 시작하지 않는 경우, 자세한 내용은 로그(예: /var/log/gitlab/postgresql/current)를 확인하세요.

SSL 필요

/etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
gitlab_rails['db_sslmode'] = 'require'
```
변경 사항을 적용하려면 GitLab 다시 구성하세요.
변경 사항이 적용되도록 PostgreSQL을 다시 시작하세요:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 시작하지 않는 경우, 자세한 내용은 로그(예: /var/log/gitlab/postgresql/current)를 확인하세요.

SSL 비활성화

/etc/gitlab/gitlab.rb에 다음을 추가하십시오.:
```
postgresql['ssl'] = 'off'
```
구성 변경을 적용하려면 GitLab 재구성을(를) 실행하십시오.
변경 사항이 적용되려면 PostgreSQL을(를) 재시작하십시오:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 시작되지 않는 경우 더 많은 세부 정보를 확인하려면 로그(예: /var/log/gitlab/postgresql/current)를 확인하십시오.

SSL 사용 여부 확인

클라이언트가 SSL을 사용하는지 확인하려면 다음을 실행할 수 있습니다:

sudo gitlab-rails dbconsole --database main

시작할 때 다음과 같은 배너가 표시되어야 합니다:

psql (13.14)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: on)
Type "help" for help.

클라이언트가 SSL을 사용하는지 확인하려면 다음 SQL 쿼리를 실행하십시오:

SELECT * FROM pg_stat_ssl;

예를 들어:

gitlabhq_production=> select * from pg_stat_ssl;
 pid  | ssl | version |         cipher         | bits | compression |  clientdn
------+-----+---------+------------------------+------+-------------+------------
| f   |         |                        |      |             |
| f   |         |                        |      |             |
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| f   |         |                        |      |             |
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           |
| t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
| f   |         |                        |      |             |
| f   |         |                        |      |             |
| f   |         |                        |      |             |
(16 rows)

ssl 열 아래에 t가 나열된 행은 활성화되어 있습니다.
clientdn에 값이 있는 행은 cert 인증 방법을 사용 중입니다.

SSL 클라이언트 인증 구성

SSL 클라이언트 인증서를 사용하여 데이터베이스 서버에 인증할 수 있습니다. 인증서를 생성하는 것은 omnibus-gitlab의 범위를 벗어나는 작업입니다. 그러나 기존의 SSL 인증서 관리 솔루션을 사용하고 있는 사용자는 이를 사용할 수 있습니다.

데이터베이스 서버 구성

서버용 인증서와 키를 생성하고, 공통 이름은 서버의 DNS 이름과 동일해야 합니다.
서버 인증서, 키 및 CA 파일을 PostgreSQL 서버에 복사하고, 권한이 올바른지 확인하십시오.
1. 인증서는 데이터베이스 사용자(기본값: gitlab-psql)가 소유해야 합니다.
2. 키 파일은 데이터베이스 사용자가 소유해야 하며 권한은 0400이어야 합니다.
3. CA 파일은 데이터베이스 사용자가 소유해야 하며, 권한은 0400이어야 합니다.
노트: 이러한 파일에는 server.crt 또는 server.key라는 파일 이름을 사용하지 마십시오. 이러한 파일 이름은 omnibus-gitlab의 내부 사용을 위해 예약되어 있습니다.
다음이 gitlab.rb에 설정되어 있는지 확인하십시오.:
```
postgresql['ssl_cert_file'] = '인증서_경로'
postgresql['ssl_key_file'] = '키_경로'
postgresql['ssl_ca_file'] = 'CA_파일_경로'
postgresql['listen_address'] = 'IP_주소'
postgresql['cert_auth_addresses'] = {
'IP_주소' => {
  'database' => 'gitlabhq_production',
  'user' => 'gitlab'
}
```
listen_address를 클라이언트가 데이터베이스에 연결할 때 사용할 서버의 IP 주소로 설정하십시오. cert_auth_addresses에는 데이터베이스에 연결할 수 있는 IP 주소 및 사용자와 데이터베이스가 포함된 목록이 있어야 합니다. IP 주소 범위를 지정할 때 cert_auth_addresses의 키를 지정할 때 CIDR 표기법을 사용할 수 있습니다.
새 설정이 적용되도록 gitlab-ctl reconfigure 및 gitlab-ctl restart postgresql을(를) 실행하십시오.

Rails 클라이언트 구성

서버에 연결하려면, commonName이 gitlab로 설정된 인증서 및 키가 필요합니다. 이 인증서는 데이터베이스 서버의 ssl_ca_file에 지정된 CA 파일에서 신뢰할 수 있는 인증 기관에 의해 서명된 것이어야 합니다.

gitlab.rb 구성

gitlab_rails['db_host'] = '데이터베이스_서버의_IP_주소_또는_호스트_이름'
gitlab_rails['db_sslcert'] = '인증서_파일_경로'
gitlab_rails['db_sslkey'] = '키_파일_경로'
gitlab_rails['db_rootcert'] = 'CA_파일_경로'

새 설정을 사용하도록 레일스 클라이언트를 위해 gitlab-ctl reconfigure를 실행하십시오.
인증이 작동하는지 확인하려면 SSL 사용 여부 확인 단계를 따르십시오.

패키지화된 PostgreSQL 서버를 TCP/IP로 수신 대기하도록 구성

패키지화된 PostgreSQL 서버를 TCP/IP 연결을 위해 구성할 수 있으며, 일부 중요하지 않은 스크립트들은 UNIX 소켓을 기대하고 문제가 발생할 수 있습니다.

데이터베이스 서비스에서 TCP/IP 사용을 구성하려면 gitlab.rb의 postgresql 및 gitlab_rails 섹션을 모두 변경하십시오.

PostgreSQL 블록 구성

다음의 설정이 postgresql 블록에 영향을 줍니다:

listen_address: PostgreSQL이 수신 대기할 주소를 제어합니다.
port: PostgreSQL이 수신 대기하는 포트를 제어합니다. 기본값은 5432입니다.
md5_auth_cidr_addresses: 암호로 인증한 후 서버에 연결할 수 있는 CIDR 주소 블록 목록입니다.
trust_auth_cidr_addresses: 어떠한 인증도 필요하지 않고 서버에 연결할 수 있는 CIDR 주소 블록 목록입니다. GitLab Rails 또는 Sidekiq과 같이 연결해야 하는 노드로부터의 연결만 허용하도록 이 설정을 지정해야 합니다. 이는 동일한 노드에 배포했을 때 로컬 연결 또는 Postgres Exporter와 같은 구성요소에서의 연결을 포함합니다(127.0.0.1/32).
sql_user: MD5 인증에 대한 예상 사용자 이름을 제어합니다. 이는 기본적으로 gitlab으로, 필수적인 설정은 아닙니다.
sql_user_password: PostgreSQL이 MD5 인증으로 수락할 암호를 설정합니다.

/etc/gitlab/gitlab.rb 파일을 편집합니다:

postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432
postgresql['md5_auth_cidr_addresses'] = %w()
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/24)
postgresql['sql_user'] = "gitlab"

##! SQL_USER_PASSWORD_HASH는 `gitlab-ctl pg-password-md5 'gitlab'` 명령을 사용하여 생성할 수 있습니다.
##! 여기서 'gitlab'은 GitLab에 연결하는 SQL 사용자의 이름이며, 비밀번호를 입력하면 됩니다. 이 비밀번호는 'securesqlpassword'와 같이 데이터베이스와의 인증에 사용할 다른 클라이언트에 의해 사용됩니다.
postgresql['sql_user_password'] = "SQL_USER_PASSWORD_HASH"

# trust_auth_cidr_addresses 및 md5_auth_cidr_addresses에 정의된 모든 연결에 대해 ssl을 강제하도록 설정
postgresql['hostssl'] = true

GitLab을 다시 구성하고 PostgreSQL을 다시 시작합니다:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart postgresql

네트워크를 통해 연결할 모든 클라이언트 또는 GitLab 서비스는 PostgreSQL 서버에 연결할 때 sql_user 값을 제공해야 하며, md5_auth_cidr_addresses에서 제공된 네트워크 블록에 위치해야 합니다.

GitLab Rails 블록 구성

gitlab-rails 응용 프로그램을 PostgreSQL 데이터베이스에 네트워크를 통해 연결하도록 구성하려면 여러 가지 설정을 구성해야 합니다:

db_host: 데이터베이스 서버의 IP 주소로 설정되어야 합니다. 만약 PostgreSQL 서비스와 동일한 인스턴스에 있다면 127.0.0.1일 수 있으며 암호 인증이 필요하지 않습니다.
db_port: 연결할 PostgreSQL 서버의 포트를 설정하며, db_host가 설정된 경우 반드시 설정되어야 합니다.
db_username: PostgreSQL에 연결하기 위해 사용될 사용자 이름을 구성합니다. 이는 기본적으로 gitlab로 설정되어 있습니다.
db_password: TCP/IP를 통해 PostgreSQL에 연결하며, postgresql['md5_auth_cidr_addresses'] 설정의 인스턴스에서 필요한 경우 제공되어야 합니다. 127.0.0.1에 연결하고 postgresql['trust_auth_cidr_addresses']를 구성해 두었다면 필요하지 않습니다.

/etc/gitlab/gitlab.rb 파일을 편집합니다:

gitlab_rails['db_host'] = '127.0.0.1'
gitlab_rails['db_port'] = 5432
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "securesqlpassword"

GitLab을 다시 구성하고 PostgreSQL을 다시 시작합니다:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart postgresql

설정 적용 및 서비스 다시 시작

이전 변경 사항을 적용하려면 관리자는 gitlab-ctl reconfigure를 실행해야 합니다. TCP 수신 대기와 관련하여 이슈가 발생할 경우 gitlab-ctl restart postgresql 명령어로 직접 서비스를 다시 시작해 보세요.

리눅스 패키지의 일부 스크립트(예: gitlab-psql)는 PostgreSQL과의 연결 처리를 UNIX 소켓을 통해 예상하며 제대로 작동하지 않을 수 있습니다. UNIX 소켓을 비활성화하지 않고 TCP/IP를 활성화할 수 있습니다.

다른 클라이언트에서의 액세스를 테스트하려면 다음을 실행할 수 있습니다:

sudo gitlab-rails dbconsole --database main

PostgreSQL WAL(Write Ahead Log) 아카이빙 활성화

기본적으로 패키지화된 PostgreSQL의 WAL 아카이빙이 활성화되어 있지 않습니다. WAL 아카이빙을 활성화하고자 할 때 다음 사항을 고려하십시오:

WAL 수준은 ‘replica’ 이상이어야 합니다 (9.6+ 옵션은 minimal, replica, 또는 logical입니다)
WAL 수준을 높이면 일반 작업에서 사용되는 저장 공간의 양이 증가합니다

WAL 아카이빙을 활성화하려면 다음을 수행하십시오:

/etc/gitlab/gitlab.rb 파일을 편집합니다:

# 복제 설정
postgresql['sql_replication_user'] = "gitlab_replicator"
postgresql['wal_level'] = "replica"
    ...
    ...
# 백업/아카이브 설정
postgresql['archive_mode'] = "on"
postgresql['archive_command'] = "/your/wal/archiver/here"
postgresql['archive_timeout'] = "60"

변경 사항이 적용되려면 GitLab을 다시 구성하십시오. 이로써 데이터베이스가 재시작됩니다.

다른 디렉토리에 PostgreSQL 데이터 저장

기본적으로 모든 것은 postgresql['dir'] 속성에 의해 제어되며 /var/opt/gitlab/postgresql 하위에 저장됩니다.

여기에는 다음이 포함됩니다:

데이터베이스 소켓은 /var/opt/gitlab/postgresql/.s.PGSQL.5432이 될 것입니다. 이것은 postgresql['unix_socket_directory']에 의해 제어됩니다.
gitlab-psql 시스템 사용자의 HOME 디렉토리가 여기로 설정됩니다. 이것은 postgresql['home']에 의해 제어됩니다.
실제 데이터는 /var/opt/gitlab/postgresql/data에 저장될 것입니다.

PostgreSQL 데이터의 위치를 변경하려면

경고: 기존 데이터베이스가 있는 경우 먼저 데이터를 새 위치로 이동해야 합니다.

경고: 이것은 강제적인 작업입니다. 기존 설치에서 다운타임 없이 수행할 수 없습니다.

이전 설치인 경우 GitLab을 중지하십시오: gitlab-ctl stop.
postgresql['dir']를 원하는 위치로 업데이트하십시오.
gitlab-ctl reconfigure를 실행하십시오.
GitLab을 시작하십시오 gitlab-ctl start.

패키지된 PostgreSQL 서버 업그레이드

Linux 패키지는 패키지에 포함된 PostgreSQL 서버를 나중 버전으로 업데이트하기 위해 gitlab-ctl pg-upgrade 명령을 제공합니다 (패키지에 포함된 경우). 이것은 패키지 업그레이드 중에 PostgreSQL을 기본으로 제공된 버전으로 업데이트합니다. 특별히 자동 PostgreSQL 업그레이드에서 제외하지 않는 한, 이것을 수행합니다.

새로운 버전으로 GitLab을 업그레이드하기 전에, Linux 패키지의 버전별 변경 사항을 참조하여 다음 사항을 확인하십시오:

데이터베이스 버전이 변경된 경우.
업그레이드가 필요한 경우.

경고: 업그레이드 전에 명령을 실행하기 전에 이 섹션을 완전히 읽는 것이 중요합니다. 단일 노드 설치의 경우, 이 업그레이드는 데이터베이스가 수행 중인 동안 다운타임이 필요합니다. 시간은 데이터베이스 크기에 따라 다릅니다.

참고: 업그레이드 중에 문제가 발생하면, 완전한 설명과 함께 이슈를 일으켜 omnibus-gitlab issue tracker에 등록하십시오.

PostgreSQL 버전을 업그레이드하기 전에 다음이 충족되었는지 확인하십시오:

현재 PostgreSQL 버전을 지원하는 GitLab의 최신 버전을 실행 중입니다.
최근에 업그레이드했다면, 계속 진행하기 전에 sudo gitlab-ctl reconfigure를 성공적으로 실행했습니다.
데이터베이스의 두 개 복사본에 충분한 디스크 공간이 있습니다. 충분한 여유 공간이 없으면 업그레이드를 시도하지 마십시오.
- sudo du -sh /var/opt/gitlab/postgresql/data를 사용하여 데이터베이스 크기를 확인하십시오 (또는 데이터베이스 경로를 업데이트하십시오).
- sudo df -h를 사용하여 사용 가능한 공간을 확인하십시오. 데이터베이스가 있는 파티션에 충분한 공간이 없는 경우, 명령에 --tmp-dir $DIR 인자를 전달하십시오. 업그레이드 작업에는 사용 가능한 디스크 공간을 확인하고 요구 사항이 충족되지 않으면 업그레이드를 중단하는 것이 포함됩니다.

위의 체크리스트를 충족했다면 다음과 같이 업그레이드를 계속할 수 있습니다:

sudo gitlab-ctl pg-upgrade

특정한 PostgreSQL 버전으로 업그레이드하려면 -V 플래그를 사용하여 버전을 추가하십시오. 예를 들어, PostgreSQL 16으로 업그레이드하려면:

sudo gitlab-ctl pg-upgrade -V 16

참고: pg-upgrade는 인자를 사용할 수 있습니다; 예를 들어, 기본 명령 실행에 대한 타임아웃을 설정할 수 있습니다 (--timeout=1d2h3m4s5ms). 전체 목록을 보려면 gitlab-ctl pg-upgrade -h를 실행하십시오.

gitlab-ctl pg-upgrade는 다음 단계를 수행합니다:

데이터베이스가 알려진 좋은 상태에 있는지 확인합니다.
충분한 여유 디스크 공간이 있는지 확인하고, 그렇지 않은 경우 중단합니다. --skip-disk-check 플래그를 추가하여 이 단계를 건너뛸 수 있습니다.
기존 데이터베이스 및 불필요한 서비스를 중지하고 GitLab이 배치 페이지를 이용하도록 합니다.
PostgreSQL을 최신 버전의 데이터베이스를 가리키도록 /opt/gitlab/embedded/bin/의 심볼릭 링크를 변경합니다.
새로운 데이터베이스에 기존 데이터베이스와 일치하는 로캘로 비어있는 새 데이터베이스를 포함한 새 디렉토리를 생성합니다.
pg_upgrade 도구를 사용하여 이전 데이터베이스에서 새 데이터베이스로 데이터를 복사합니다.
이전 데이터베이스를 제거합니다.
새 데이터베이스를 예상 위치로 이동합니다.
필요한 구성 변경을 위해 sudo gitlab-ctl reconfigure를 호출하고, 새 데이터베이스 서버를 시작합니다.
데이터베이스 통계를 생성하기 위해 ANALYZE를 실행합니다.
나머지 서비스를 시작하고 배치 페이지를 제거합니다.
이 과정 중에 오류가 발견되면, 이전 데이터베이스 버전으로 되돌립니다.

업그레이드가 완료되면 모든 것이 예상대로 작동하는지 확인하십시오.

ANALYZE 단계를 실행하는 중에 출력에 오류가 있는 경우, 업그레이드는 여전히 작동하지만 데이터베이스 통계가 생성될 때까지 데이터베이스 성능이 나쁠 수 있습니다. 수동으로 ANALYZE를 실행해야 할지 여부를 결정하기 위해 gitlab-psql을 사용하십시오:

sudo gitlab-psql -c "SELECT relname, last_analyze, last_autoanalyze FROM pg_stat_user_tables WHERE last_analyze IS NULL AND last_autoanalyze IS NULL;"

위의 쿼리가 어떤 행을 반환했다면, ANALYZE를 수동으로 실행할 수 있습니다:

sudo gitlab-psql -c 'SET statement_timeout = 0; ANALYZE VERBOSE;'

ANALYZE 명령의 실행 시간은 데이터베이스 크기에 따라 상당히 다를 수 있습니다. 이 작업의 진행 상황을 모니터링하기 위해 다른 콘솔 세션에서 주기적으로 다음 쿼리를 실행할 수 있습니다. tables_remaining 열이 서서히 0에 도달해야 합니다:

sudo gitlab-psql -c "
SELECT
    COUNT(*) AS total_tables,
    SUM(CASE WHEN last_analyze IS NULL OR last_analyze < (NOW() - INTERVAL '2 hours') THEN 1 ELSE 0 END) AS tables_remaining
FROM pg_stat_user_tables;
"

여러분의 GitLab 인스턴스가 올바르게 작동하는 것을 확인한 후에, 이전 데이터베이스 파일을 정리할 수 있습니다:

sudo rm -rf /var/opt/gitlab/postgresql/data.<old_version>
sudo rm -f /var/opt/gitlab/postgresql-version.old

GitLab 버전별로 제공되는 PostgreSQL 버전의 자세한 내용은 Linux 패키지와 함께 제공되는 PostgreSQL 버전에서 찾을 수 있습니다.

자동 PostgreSQL 업그레이드 비활성화

GitLab 패키지 업그레이드 중 자동 PostgreSQL 업그레이드를 비활성화하려면 다음을 실행하세요:

sudo touch /etc/gitlab/disable-postgresql-upgrade

패키지화된 PostgreSQL 서버를 이전 버전으로 되돌리기

경고: 이 작업은 현재 데이터베이스를 이전 업그레이드 직전의 상태로 되돌립니다. 다운그레이드를 시도하기 전에 백업을 만들어 두세요.

여러 PostgreSQL 버전을 함께 제공하는 GitLab 버전에서는 gitlab-ctl revert-pg-upgrade 명령을 사용하여 이미 업그레이드된 PostgreSQL 버전을 이전 버전으로 내릴 수 있습니다. 이 명령은 -V 플래그도 지원하여 패키지에 두 개 이상의 PostgreSQL 버전이 제공되는 시나리오에서 대상 버전을 지정할 수 있습니다 (예: GitLab 12.8의 경우, PostgreSQL 9.6.x, 10.x 및 11.x가 제공된 경우).

대상 PostgreSQL 버전을 14로 지정하려면:

gitlab-ctl revert-pg-upgrade -V 14

대상 버전이 지정되지 않으면, 사용 가능한 경우 /var/opt/gitlab/postgresql-version.old의 버전이 사용됩니다. 그렇지 않으면 GitLab과 함께 제공된 기본 버전으로 돌아갑니다.

하나의 PostgreSQL 버전만을 제공하는 다른 GitLab 버전에서는 PostgreSQL 버전을 다운그레이드할 수 없습니다. 이 경우 이를 위해 GitLab을 이전 버전으로 다운그레이드해야 합니다.

여러 데이터베이스 연결 구성

gitlab:db:decomposition:connection_status 레이크 작업은 GitLab 15.11에 도입되었습니다.
단일 데이터베이스 지원은 GitLab 18.0에서 제거될 예정입니다.

GitLab 16.0부터 GitLab은 같은 PostgreSQL 데이터베이스를 가리키는 두 개의 데이터베이스 연결을 사용하도록 기본 설정되어 있습니다.

GitLab 16.0으로 업그레이드하기 전에, PostgreSQL max_connections 설정이 충분히 높아서 사용 가능한 연결의 50% 이상이 사용되지 않은 것을 확인하세요. 예를 들어, max_connections가 100으로 설정되어 있고 사용중인 연결이 75개라면, 최소 150까지 max_connections를 증가해야 합니다. 왜냐하면 업그레이드 후 사용 중인 연결이 150으로 두 배로 증가하기 때문입니다.

이를 확인하려면 다음 레이크 작업을 실행할 수 있습니다:

sudo gitlab-rake gitlab:db:decomposition:connection_status

작업에서 max_connections가 충분히 높음을 나타내면, 업그레이드를 진행할 수 있습니다.

패키지화되지 않은 PostgreSQL 데이터베이스 관리 서버 사용

기본적으로 GitLab은 Linux 패키지에 포함된 PostgreSQL 서버를 사용하도록 구성되어 있습니다. 외부 PostgreSQL 인스턴스를 사용하도록 다시 구성할 수도 있습니다.

경고: 패키지화되지 않은 PostgreSQL 서버를 사용하는 경우, PostgreSQL이 데이터베이스 요구 사항 문서에 따라 설정되어 있는지 확인해야 합니다.

/etc/gitlab/gitlab.rb 파일을 편집하세요:
```
# 내장된 Postgres 비활성화
postgresql['enable'] = false

# database.yml의 연결 세부 정보 입력
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
gitlab_rails['db_host'] = '127.0.0.1'
gitlab_rails['db_port'] = 5432
gitlab_rails['db_username'] = 'USERNAME'
gitlab_rails['db_password'] = 'PASSWORD'
```
이러한 줄의 맨 앞에 있는 # 주석 문자를 제거하는 것을 잊지 마세요.
주의할 점:
- /etc/gitlab/gitlab.rb 파일은 평문 암호를 포함하고 있기 때문에 파일 권한이 0600이어야 합니다.
- PostgreSQL은 여러 주소에서 수신할 수 있습니다.
  gitlab_rails['db_host']에 여러 주소를 사용하는 경우 쉼표로 구분하고, 목록에서 첫 번째 주소가 연결에 사용됩니다.
구성 변경 사항이 적용되려면 GitLab을 다시 구성하세요.
데이터베이스를 초기화하세요.

패키지화되지 않은 PostgreSQL의 UNIX 소켓 구성

GitLab이 번들로 제공된 것이 아닌 시스템의 PostgreSQL 서버(설치된 GitLab과 동일한 시스템에 설치됨)를 GitLab 번들 대신 사용하려면 UNIX 소켓을 사용할 수 있습니다:

/etc/gitlab/gitlab.rb 파일을 편집하세요:

# 내장된 Postgres 비활성화
postgresql['enable'] = false

# database.yml의 연결 세부 정보 입력
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
# 소켓이 위치하는 경로
gitlab_rails['db_host'] = '/var/run/postgresql/'

구성 변경 사항이 적용되려면 GitLab을 다시 구성하세요:
```
sudo gitlab-ctl-reconfigure
```

SSL 구성

SSL 필요

/etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
gitlab_rails['db_sslmode'] = 'require'
```
구성 변경 사항을 적용하려면 GitLab을 다시 구성하세요.
변경 사항이 적용되려면 PostgreSQL을 다시 시작하세요:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 시작되지 않는 경우, 자세한 내용은 로그(예: /var/log/gitlab/postgresql/current)를 확인하세요.

SSL 필요 및 CA 번들에 대한 서버 인증서 확인

PostgreSQL은 스푸핑을 방지하기 위해 SSL을 필요로하도록 구성되고, 서버 인증서를 CA 번들에 대해 확인할 수 있습니다. gitlab_rails['db_sslrootcert']에 지정된 CA 번들에는 루트 및 중간 인증서가 모두 포함되어야 합니다.

/etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
gitlab_rails['db_sslmode'] = "verify-full"
gitlab_rails['db_sslrootcert'] = "<your_ca-bundle.pem의_전체_경로>"
```
PostgreSQL 서버에 Amazon RDS를 사용하는 경우, gitlab_rails['db_sslrootcert']에 combined CA bundle을 다운로드하여 사용하세요. 관련 정보는 AWS의 using SSL/TLS to Encrypt a Connection to a DB Instance 문서에서 확인할 수 있습니다.
구성 변경 사항을 적용하려면 GitLab을 다시 구성하세요.
변경 사항이 적용되려면 PostgreSQL을 다시 시작하세요:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 시작되지 않는 경우, 자세한 내용은 로그(예: /var/log/gitlab/postgresql/current)를 확인하세요.

비 패키지화된 PostgreSQL 데이터베이스의 백업 및 복원

백업 및 복원 명령을 사용할 때 GitLab은 패키지로 제공된 pg_dump 명령을 사용하여 데이터베이스 백업 파일을 생성하고 패키지로 제공된 psql 명령을 사용하여 백업을 복원하려고 시도합니다. 이 작업은 올바른 버전일 경우에만 작동합니다. 패키지 버전의 pg_dump 및 psql 버전을 확인하세요.

/opt/gitlab/embedded/bin/pg_dump --version
/opt/gitlab/embedded/bin/psql --version

패키지화되지 않은 외부 PostgreSQL의 버전과 다른 경우, 백업 명령을 실행할 때 다음과 같은 오류 출력을 만날 수 있습니다.

PostgreSQL 데이터베이스 gitlabhq_production을 덤프하는 중... pg_dump: 오류: 서버 버전: 13.3; pg_dump 버전: 12.6
pg_dump: 오류: 서버 버전 불일치로 인한 중단

이 예에서는 PostgreSQL 버전 13.3을 사용하는 GitLab 14.1에서 오류가 발생하며 기본 쉽게 설치된 PostgreSQL 버전인 12.6이 아닙니다.

이 경우 데이터베이스 버전과 일치하는 툴을 설치한 다음 아래 단계를 따르셔야 합니다. PostgreSQL 클라이언트 툴을 설치하는 여러 가지 방법이 있습니다. 옵션을 확인하세요. https://www.postgresql.org/download/

올바른 psql 및 pg_dump 툴이 시스템에 설치된 경우, 다음 단계를 따르시고 새 툴을 설치한 위치로 올바른 경로를 사용하세요:

패키지화되지 않은 버전에 심볼릭 링크 추가:

ln -s /path/to/new/pg_dump /path/to/new/psql /opt/gitlab/bin/

버전 확인:
```
/opt/gitlab/bin/pg_dump --version
/opt/gitlab/bin/psql --version
```
이제 이 버전은 패키지화되지 않은 외부 PostgreSQL과 일치해야 합니다.

이 작업이 완료된 후, 백업 및 복원 작업이 올바른 실행 파일을 사용하도록 확인하세요.

비 패키지화된 PostgreSQL 데이터베이스 업그레이드

데이터베이스와 연결된 모든 프로세스(Puma, Sidekiq)를 중지한 후 외부 데이터베이스를 업그레이드할 수 있습니다:

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

업그레이드를 진행하기 전에 다음을 확인하세요:

GitLab 릴리스와 PostgreSQL 버전의 호환성을 확인하세요:
- 최소 PostgreSQL 버전 필요 사항을 독해하세요.
- Linux 패키지와 함께 제공된 PostgreSQL 버전의 중요 변경 사항을 알아보세요: Linux 패키지는 함께 제공된 PostgreSQL의 메이저 릴리스와 호환성이 테스트됩니다.
GitLab 백업 또는 복원을 사용할 때 반드시 동일한 GitLab 버전을 유지해야 합니다. 나중에 GitLab 버전을 업그레이드할 계획이 있다면 우선 PostgreSQL을 업그레이드하세요.
백업 및 복원 명령을 사용하여 데이터베이스를 PostgreSQL의 이후 버전으로 백업하고 복원할 수 있습니다.
Linux 패키지 릴리스와 함께 제공되지 않는 postgresql['version']이 명시된 경우, 호환성 테이블의 기본 버전이 PostgreSQL 백업/복원 바이너리의 활성 상태를 결정합니다.

다음 예시는 PostgreSQL 13에서 PostgreSQL 14로 업그레이드하는 과정을 보여주며 다운타임이 필요합니다:

데이터베이스 요구 사항에 따라 설정된 새 PostgreSQL 14 데이터베이스 서버를 설정합니다.
GitLab Rails 인스턴스에서 호환되는 버전의 pg_dump 및 pg_restore가 사용되고 있는지 확인하세요. GitLab 구성을 수정하려면 /etc/gitlab/gitlab.rb을 편집하고 postgresql['version'] 값을 지정하세요:
```
postgresql['version'] = 14
```
GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```
GitLab을 중지하세요 (이 단계는 다운타임을 유발합니다):
```
sudo gitlab-ctl stop
```

경고: 백업 명령은 추가 매개변수가 필요합니다. 인스톨레이션이 PgBouncer를 사용하는 경우.

백업 Rake 태스크를 실행하여 데이터베이스만 백업하는 SKIP 옵션을 사용하세요. 백업 파일 이름을 메모해두세요. 복원 시 사용할 것입니다.
```
sudo gitlab-backup create SKIP=repositories,uploads,builds,artifacts,lfs,pages,registry
```
PostgreSQL 13 데이터베이스 호스트를 종료합니다.
/etc/gitlab/gitlab.rb을 편집하고 gitlab_rails['db_host'] 설정을 업데이트하여 PostgreSQL 데이터베이스 14 호스트를 가리키도록 합니다.
GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```
경고: 백업 명령은 추가 매개변수가 필요합니다. 인스톨레이션이 PgBouncer를 사용하는 경우.
이전에 생성된 데이터베이스 백업 파일을 사용하여 데이터베이스를 복원하고 “이 작업은 이제 authorized_keys 파일을 다시 빌드합니다”라는 질문에 “no”로 응답하세요:
```
# 백업 타임스탬프 사용 https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html#backup-timestamp
sudo gitlab-backup restore BACKUP=<백업-타임스탬프>
```
GitLab을 시작하세요:
```
sudo gitlab-ctl start
```
PostgreSQL을 새 메이저 버전으로 업그레이드한 후 쿼리 계획을 효율적으로 선택하고 데이터베이스 서버 CPU 부하를 줄이기 위해 테이블 통계를 다시 생성하세요.
pg_upgrade를 사용하여 “인플레이스”로 업그레이드한 경우 PostgreSQL 데이터베이스 콘솔에서 다음 쿼리를 실행하세요:
```
SET statement_timeout = 0; ANALYZE VERBOSE;
```
ANALYZE 명령의 실행 시간은 데이터베이스 크기에 따라 상당히 다를 수 있습니다. 이 작업의 진행 상황을 모니터링하기 위해 다른 PostgreSQL 데이터베이스 콘솔에서 주기적으로 다음 쿼리를 실행할 수 있습니다. tables_remaining 열은 점진적으로 0에 도달해야 합니다:
```
SELECT
  COUNT(*) AS total_tables,
  SUM(CASE WHEN last_analyze IS NULL OR last_analyze < (NOW() - INTERVAL '2 hours') THEN 1 ELSE 0 END) AS tables_remaining
FROM pg_stat_user_tables;
```
pg_dump 및 pg_restore를 사용하여 업그레이드한 경우 PostgreSQL 데이터베이스 콘솔에서 다음 쿼리를 실행하세요:
```
SET statement_timeout = 0; VACUUM VERBOSE ANALYZE;
```

데이터베이스 초기화 (처음 설치시에만)

경고: 이 명령은 파괴적입니다. 기존 데이터베이스에서 실행하지 마십시오.

Linux 패키지 설치는 외부 데이터베이스를 초기화하지 않습니다. 다음 명령을 실행하여 스키마를 가져와 첫 번째 관리자 사용자를 생성하십시오:

# 'git' 사용자인 경우 'sudo'를 제거하세요
sudo gitlab-rake gitlab:setup

기본 root 사용자의 암호를 지정하려면 gitlab:setup 명령을 실행하기 전에 /etc/gitlab/gitlab.rb의 initial_root_password 설정을 지정하십시오:

gitlab_rails['initial_root_password'] = '비표준암호'

공유 GitLab 러너의 초기 등록 토큰을 지정하려면 gitlab:setup 명령을 실행하기 전에 /etc/gitlab/gitlab.rb에서 initial_shared_runners_registration_token 설정을 지정하십시오:

gitlab_rails['initial_shared_runners_registration_token'] = '토큰'

패키지된 PostgreSQL 버전 고정 (처음 설치시에만)

Linux 패키지는 다른 PostgreSQL 버전과 함께 제공되며, 지정하지 않은 경우 기본 버전을 초기화합니다.

PostgreSQL을 기본 버전이 아닌 다른 버전으로 초기화하려면 초기 재구성 전에 /etc/gitlab/gitlab.rb에 postgresql['version']을 패키지된 PostgreSQL 버전(packaged PostgreSQL versions)의 주 버전 중 하나로 설정할 수 있습니다. 예를 들어, GitLab 15.0에서는 기본값인 PostgreSQL 13 대신 PostgreSQL 12를 사용하려면 postgresql['version'] = 12를 사용합니다.

경고: 초기 재구성 후에도 Linux 패키지와 함께 제공된 PostgreSQL을 사용하면 데이터 디렉토리가 다른 PostgreSQL 버전에서 초기화되었음을 알리는 오류가 발생합니다. 만약 이를 만나면 패키지된 PostgreSQL 서버를 이전 버전으로 되돌리세요를 참조하세요.

이전에 GitLab이 설치된 환경에 처음 설치를 수행하고 고정된 PostgreSQL 버전을 사용하는 경우 먼저 PostgreSQL과 관련된 폴더가 삭제되었는지 확인하고 인스턴스에서 실행 중인 PostgreSQL 프로세스가 없는지 확인하십시오.

GitLab Rails에 민감한 데이터 구성 제공 (일반 텍스트 저장 없음)

더 많은 정보는 구성 문서의 예제를 참조하십시오.

데이터베이스 애플리케이션 설정

자동 데이터베이스 마이그레이션 비활성화

여러 GitLab 서버에서 데이터베이스를 공유하는 경우 재구성 중에 마이그레이션 단계를 수행하는 호스트의 수를 제한해야 합니다.

gitlab.rb를 편집하여 다음을 추가하십시오:

# 지정된 배포 노드를 제외한 모든 호스트에서 자동 데이터베이스 마이그레이션을 활성화 또는 비활성화합니다.
gitlab_rails['auto_migrate'] = false

/etc/gitlab/gitlab.rb는 평문 암호를 포함하고 있기 때문에 파일 권한이 0600이어야 합니다.

위의 구성을 가진 호스트가 다음에 재구성되면 마이그레이션 단계가 수행되지 않습니다.

업그레이드 후 스키마 관련된 에러를 피하기 위해 배포 노드로 표시된 호스트는 업그레이드 중에 gitlab_rails['auto_migrate'] = true를 가져야합니다.

클라이언트 statement_timeout 설정

데이터베이스 트랜잭션이 완료되기 전에 Rails가 대기하는 시간은 이제 gitlab_rails['db_statement_timeout'] 설정으로 조정할 수 있습니다. 기본적으로 이 설정은 사용되지 않습니다.

/etc/gitlab/gitlab.rb를 편집하십시오:

gitlab_rails['db_statement_timeout'] = 45000

이 경우 클라이언트의 statement_timeout은 45초로 설정됩니다. 값은 밀리초 단위로 지정됩니다.

연결 시간 초과 설정

PostgreSQL 연결 시도가 성공하기 전에 Rails가 기다리는 시간을 gitlab_rails['db_connect_timeout'] 설정으로 조정할 수 있습니다. 기본적으로 이 설정은 사용되지 않습니다:

/etc/gitlab/gitlab.rb를 편집하십시오:
```
gitlab_rails['db_connect_timeout'] = 5
```
GitLab을 재구성하십시오:
```
sudo gitlab-ctl reconfigure
```

이 경우 클라이언트의 connect_timeout은 5초로 설정됩니다. 값은 초 단위로 지정됩니다. 최소값은 2초이며, <= 0으로 설정하거나 이 설정을 지정하지 않으면 타임아웃이 비활성화됩니다.

TCP 제어 설정

Rails PostgreSQL 어댑터는 성능을 개선하기 위해 조정할 수 있는 일련의 TCP 연결 제어를 제공합니다. 각 매개변수에 대한 자세한 정보는 PostgreSQL 상류 문서를 참조하십시오.

Linux 패키지는 이러한 값을 기본으로 설정하지 않고 PostgreSQL 어댑터에서 제공하는 기본값을 사용합니다. 아래 테이블에 나열된 매개변수를 gitlab.rb에서 재정의한 다음 gitlab-ctl reconfigure를 실행하여 이를 재구성합니다.

PostgreSQL 매개변수	`gitlab.rb` 매개변수
`keepalives`	`gitlab_rails['db_keepalives']`
`keepalives_idle`	`gitlab_rails['db_keepalives_idle']`
`keepalives_interval`	`gitlab_rails['db_keepalives_interval']`
`keepalives_count`	`gitlab_rails['db_keepalives_count']`
`tcp_user_timeout`	`gitlab_rails['db_tcp_user_timeout']`

자동 데이터베이스 재인덱싱

경고: 이 기능은 기본적으로 활성화되지 않은 실험적인 기능입니다.

데이터베이스 인덱스를 백그라운드에서 다시 작성하는 것(“재인덱싱”이라고 함)은 물론 쌓인 공간을 제거하고 건강하고 효율적인 인덱스를 유지하는 데 도움이 됩니다.

이 재인덱싱 작업은 cronjob을 통해 정기적으로 시작될 수 있습니다. cronjob을 구성하려면 gitlab_rails['database_reindexing']['enable']을 true로 설정하면 됩니다.

다중 노드 환경에서 이 기능은 응용 프로그램 호스트에서만 활성화되어야 합니다. 재인덱싱 프로세스는 PgBouncer를 통과할 수 없으며 직접 데이터베이스 연결을 가져야합니다.

기본적으로 이 기능은 주말(아마도 트래픽이 적은 시간)에 매 시간마다 시작됩니다.

다음 설정을 보다 구체적으로 정제하여 일정을 변경할 수 있습니다:

/etc/gitlab/gitlab.rb를 편집하십시오:

gitlab_rails['database_reindexing']['hour'] = '*'
gitlab_rails['database_reindexing']['minute'] = 0
gitlab_rails['database_reindexing']['month'] = '*'
gitlab_rails['database_reindexing']['day_of_month'] = '*'
gitlab_rails['database_reindexing']['day_of_week'] = '0,6'

GitLab을 재구성하십시오:
```
sudo gitlab-ctl reconfigure
```

HA/Geo 클러스터에 배포된 패키지화된 PostgreSQL

GitLab HA 클러스터 업그레이드

Patroni 클러스터에서 PostgreSQL 버전을 업그레이드하려면 Patroni 클러스터에서 PostgreSQL 주요 버전 업그레이드를 참조하세요.

GitLab HA Repmgr 클러스터 업그레이드

참고: PostgreSQL 12로 업그레이드하는 경우, 먼저 Repmgr에서 Patroni로 전환해야 합니다. Repmgr에서 Patroni로 전환을 참조하세요.

이 지침은 Repmgr을 사용할 때 이전 GitLab 클러스터를 PostgreSQL 11로 업그레이드하는 경우에 제공됩니다.

만약 PostgreSQL이 고가용성으로 구성된 경우, pg-upgrade를 모든 PostgreSQL 노드에서 실행해야 합니다. 다른 노드는 건너뛸 수 있지만 데이터베이스 노드와 동일한 GitLab 버전이여야 합니다.

다음과 같은 단계를 따라 데이터베이스 노드를 업그레이드하세요:

주 노드보다 보조 노드를 먼저 업그레이드해야 합니다.
1. 보조 노드에서 /etc/gitlab/gitlab.rb 파일을 편집하여 다음을 포함시킵니다:
```
# X를 DB 노드 수 + 1로 교체하세요
postgresql['max_replication_slots'] = X
```
2. 설정을 업데이트하려면 gitlab-ctl reconfigure를 실행하세요.
3. 새 구성으로 PostgreSQL을 재시작하려면 sudo gitlab-ctl restart postgresql를 실행하세요.
4. PostgreSQL 보조 노드에서 pg-upgrade를 실행하면 해당 노드가 클러스터에서 제거됩니다.
5. 보조 노드를 pg-upgrade해도 새 버전과 일치하도록 기존 데이터가 업데이트되지 않으며 해당 데이터는 주 노드의 데이터에 의해 대체됩니다. 그러나 기존 데이터는 백업 위치로 이동합니다.
모든 보조 노드를 업그레이드한 후 주 노드에서 pg-upgrade를 실행하세요.
1. 주 노드에서 /etc/gitlab/gitlab.rb 파일을 편집하여 다음을 포함시킵니다:
```
# X를 DB 노드 수 + 1로 교체하세요
postgresql['max_replication_slots'] = X
```
2. 설정을 업데이트하려면 gitlab-ctl reconfigure를 실행하세요.
3. 새 구성으로 PostgreSQL을 재시작하려면 sudo gitlab-ctl restart postgresql를 실행하세요.
4. 주 노드에서 pg-upgrade를 실행하면 기존 데이터가 새 PostgreSQL 버전과 일치하도록 업데이트됩니다.
각각의 보조 노드에서 다음 명령을 실행하여 보조 노드를 다시 만드세요
```
gitlab-ctl repmgr standby setup MASTER_NODE_NAME
```
Repmgr 클러스터가 원래 상태로 돌아왔는지 확인하세요
```
gitlab-ctl repmgr cluster show
```

HA 클러스터에서의 업그레이드 문제 해결

만약 이전에 번들 포함된 PostgreSQL이 HA 설정으로 노드에서 실행 중이었다면, 이전 데이터 디렉터리가 남아 있을 수 있습니다. 이로 인해 gitlab-ctl reconfigure가 해당 노드에서 사용하는 PostgreSQL 유틸리티의 버전을 낮추게 됩니다. 이를 방지하려면 해당 디렉터리를 이동(또는 제거)하여야 합니다:

mv /var/opt/gitlab/postgresql/data/ /var/opt/gitlab/postgresql/data.$(date +%s)

gitlab-ctl repmgr standby setup MASTER_NODE_NAME을 사용하여 보조 노드를 재생성할 때 다음과 같은 오류가 발생하는 경우, /etc/gitlab/gitlab.rb에 postgresql['max_replication_slots'] = X (여기서 X는 DB 노드 수 + 1의 값)가 포함되어 있는지 확인하세요.

pg_basebackup: could not create temporary replication slot "pg_basebackup_12345": ERROR:  all replication slots are in use
HINT:  Free one or increase max_replication_slots.

Geo 인스턴스 업그레이드

Geo는 기본적으로 PostgreSQL 스트리밍 복제에 의존하기 때문에 GitLab 또는 PostgreSQL을 업그레이드할 때 추가 고려 사항이 있습니다.

Geo에서 PostgreSQL을 업그레이드할 때 주의할 점

경고: Geo를 사용할 때, PostgreSQL을 업그레이드하려면 모든 보조 노드에서 다운타임이 필요합니다.

Geo를 사용할 때, PostgreSQL을 모든 보조 노드에서 다운타임이 필요합니다. 이는 PostgreSQL 스트리밍 복제 방식 때문에 해당됩니다. 복제를 다시 초기화하려면 기존의 모든 데이터를 기본 노드에서 보조 노드로 복사해야 하므로 데이터베이스 크기와 사용 가능 대역폭에 따라 오랜 시간이 소요될 수 있습니다. 예를 들어, 30 Mbps의 전송 속도와 100GB의 데이터베이스 크기를 가지고 있을 때, 동기화는 약 8시간이 소요될 수 있습니다. 자세한 내용은 PostgreSQL 문서를 참조하세요.

Geo를 사용할 때 PostgreSQL을 업그레이드하는 방법

PostgreSQL을 업그레이드하려면, 복제 슬롯의 이름과 복제 사용자의 암호가 필요합니다.

Geo 기본 데이터베이스 노드에서 기존 복제 슬롯의 이름을 찾으려면 다음 명령을 실행하세요:
```
sudo gitlab-psql -qt -c 'select slot_name from pg_replication_slots'
```
여기서 slot_name을 찾을 수 없는 경우 또는 출력된 내용이 없는 경우, Geo 보조 노드가 정상적으로 동작하지 않을 수 있습니다. 이 경우 보조 노드가 정상적으로 동작하고 복제가 작동하는지 확인하세요.
쿼리가 비어 있다 하더라도, Geo 사이트 관리 영역에서 찾은 slot_name을 사용하여 보조 데이터베이스를 다시 초기화할 수 있습니다.
복제 사용자의 암호를 수집하세요. 이는 Geo 설치 단계 중 1단계. 기본 사이트 구성에서 설정되었습니다.
선택 사항입니다. 각 보조 사이트에서 복제 일시 중단하여 재해 복구(DR) 기능을 보호하세요.
Geo 기본 데이터베이스에서 PostgreSQL을 수동으로 업그레이드하세요. Geo 기본 데이터베이스 노드에서 다음을 실행하세요:
```
sudo gitlab-ctl pg-upgrade
```
주 데이터베이스가 업그레이드를 완료할 때까지 보조 데이터베이스를 대기시켜서 보조 데이터베이스가 백업으로 준비되도록 하세요. 그 후, 병렬로 추적 데이터베이스를 보조 데이터베이스와 함께 업그레이드할 수 있습니다.
Geo 보조 데이터베이스에서 및 추적 데이터베이스에서 PostgreSQL을 수동으로 업그레이드하세요. Geo 보조 데이터베이스에서 다음을 실행하세요:
```
sudo gitlab-ctl pg-upgrade
```
Geo 보조 데이터베이스에서 데이터베이스 복제를 다시 시작하는 명령을 사용하세요:
```
sudo gitlab-ctl replicate-geo-database --slot-name=SECONDARY_SLOT_NAME --host=PRIMARY_HOST_NAME --sslmode=verify-ca
```
이 명령을 실행하면 기본 노드의 복제 사용자 암호를 입력해야 합니다. SECONDARY_SLOT_NAME은 위에서 처음 단계에서 검색한 슬롯 이름으로 대체하세요.
Geo 보조 데이터베이스에서 GitLab 재구성하여 pg_hba.conf 파일을 업데이트해야 합니다. 이는 replicate-geo-database가 기본 사이트를 보조 사이트로 복제하기 때문입니다.
3단계에서 복제를 일시 중단한 경우, 각 보조에서 복제 다시 시작하여 puma, sidekiq 및 geo-logcursor를 재시작하세요.
```
sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
sudo gitlab-ctl restart geo-logcursor
```
https://your_primary_server/admin/geo/nodes로 이동하여 모든 노드가 정상인지 확인하세요.

PostgreSQL 데이터베이스 연결

만약 PostgreSQL 데이터베이스에 연결해야 한다면, 응용프로그램 사용자로 연결할 수 있습니다:

sudo gitlab-rails dbconsole --database main

문제 해결

`default_transaction_isolation`을 `read committed`로 설정

만약 production/sidekiq 로그에서 다음과 유사한 오류를 본다면:

ActiveRecord::StatementInvalid PG::TRSerializationFailure: ERROR:  could not serialize access due to concurrent update

당신의 데이터베이스의 default_transaction_isolation 구성이 GitLab 응용프로그램 요구 사항과 일치하지 않을 가능성이 있습니다. 이 구성은 PostgreSQL 데이터베이스에 연결하여 SHOW default_transaction_isolation;을 실행하여 확인할 수 있습니다. GitLab 응용프로그램은 read committed가 구성되어 있다고 예상합니다.

default_transaction_isolation 구성은 postgresql.conf 파일에 설정됩니다. 이 구성을 변경한 후에는 데이터베이스를 다시 시작/다시로드해야 합니다. 이 구성은 Linux 패키지에 포함된 패키지화된 PostgreSQL 서버에 기본적으로 제공됩니다.

`plpgsql.so` 라이브러리를 로드할 수 없음

데이터베이스 마이그레이션을 실행하거나 PostgreSQL/Patroni 로그에서 다음과 유사한 오류를 볼 수 있습니다:

ERROR:  could not load library "/opt/gitlab/embedded/postgresql/12/lib/plpgsql.so": /opt/gitlab/embedded/postgresql/12/lib/plpgsql.so: undefined symbol: EnsurePortalSnapshotExists

이 오류는 기존 버전이 변경된 후 PostgreSQL을 다시 시작하지 않아서 발생합니다. 이 오류를 해결하려면:

다음 중 하나의 명령을 실행하세요:

# PostgreSQL의 경우
sudo gitlab-ctl restart postgresql

# Patroni의 경우
sudo gitlab-ctl restart patroni

# 지오 PostgreSQL의 경우
sudo gitlab-ctl restart geo-postgresql

GitLab을 다시 구성하세요:
```
sudo gitlab-ctl reconfigure
```

데이터베이스 CPU 부하가 매우 높음

만약 데이터베이스 CPU 부하가 매우 높다면, 자동 중복 파이프라인 취소 설정에 의해 발생할 수 있습니다. 자세한 내용은 이슈 435250를 참조하세요.

이 문제를 해결하기 위해:

데이터베이스 서버에 더 많은 CPU 자원을 할당할 수 있습니다.
Sidekiq가 과부하인 경우, 프로젝트의 파이프라인 수가 매우 많은 경우 ci_cancel_redundant_pipelines 대기열에 더 많은 Sidekiq 프로세스를 추가해야 할 수 있습니다.
disable_cancel_redundant_pipelines_service 기능 플래그를 활성화하여 이 설정을 인스턴스 전역으로 비활성화하고 CPU 부하가 감소하는지 확인할 수 있습니다. 이렇게 하면 모든 프로젝트에서 해당 기능이 비활성화되며, 이는 자동으로 취소되지 않는 파이프라인에 의해 리소스 사용량이 증가할 수 있습니다.

데이터베이스 설정

Linux 패키지에 함께 제공되는 PostgreSQL 데이터베이스 서비스 사용

다시 구성 및 PostgreSQL 재시작

PostgreSQL 버전 변경 시 자동 재시작

SSL 구성

SSL 필요

SSL 비활성화

SSL 사용 여부 확인

SSL 클라이언트 인증 구성

데이터베이스 서버 구성

Rails 클라이언트 구성

패키지화된 PostgreSQL 서버를 TCP/IP로 수신 대기하도록 구성

PostgreSQL 블록 구성

GitLab Rails 블록 구성

설정 적용 및 서비스 다시 시작

PostgreSQL WAL(Write Ahead Log) 아카이빙 활성화

다른 디렉토리에 PostgreSQL 데이터 저장

패키지된 PostgreSQL 서버 업그레이드

자동 PostgreSQL 업그레이드 비활성화

패키지화된 PostgreSQL 서버를 이전 버전으로 되돌리기

여러 데이터베이스 연결 구성

패키지화되지 않은 PostgreSQL 데이터베이스 관리 서버 사용

패키지화되지 않은 PostgreSQL의 UNIX 소켓 구성

SSL 구성

SSL 필요

SSL 필요 및 CA 번들에 대한 서버 인증서 확인

비 패키지화된 PostgreSQL 데이터베이스의 백업 및 복원

비 패키지화된 PostgreSQL 데이터베이스 업그레이드

데이터베이스 초기화 (처음 설치시에만)

패키지된 PostgreSQL 버전 고정 (처음 설치시에만)

GitLab Rails에 민감한 데이터 구성 제공 (일반 텍스트 저장 없음)

데이터베이스 애플리케이션 설정

자동 데이터베이스 마이그레이션 비활성화

클라이언트 statement_timeout 설정

연결 시간 초과 설정

TCP 제어 설정

자동 데이터베이스 재인덱싱

HA/Geo 클러스터에 배포된 패키지화된 PostgreSQL

GitLab HA 클러스터 업그레이드

GitLab HA Repmgr 클러스터 업그레이드

HA 클러스터에서의 업그레이드 문제 해결

Geo 인스턴스 업그레이드

Geo에서 PostgreSQL을 업그레이드할 때 주의할 점

Geo를 사용할 때 PostgreSQL을 업그레이드하는 방법

PostgreSQL 데이터베이스 연결

문제 해결

default_transaction_isolation을 read committed로 설정

plpgsql.so 라이브러리를 로드할 수 없음

데이터베이스 CPU 부하가 매우 높음

도움말

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

도움받기

`default_transaction_isolation`을 `read committed`로 설정

`plpgsql.so` 라이브러리를 로드할 수 없음