Linux 패키지에 함께 제공되는 PostgreSQL 데이터베이스 서비스 사용
패키지되지 않은 PostgreSQL 데이터베이스 관리 서버 사용
민감한 데이터 구성을 평문 저장 없이 GitLab Rails에 제공하기
데이터베이스용 애플리케이션 설정
자동 데이터베이스 재인덱싱
HA/Geo 클러스터에 배포된 패키지화된 PostgreSQL
PostgreSQL 데이터베이스 연결
문제 해결
- default_transaction_isolation을 read committed로 설정
- plpgsql.so 라이브러리를 불러올 수 없음

데이터베이스 설정

세부 정보: Tier: Free, Premium, Ultimate Offering: Self-Managed

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

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

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

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

재구성 및 PostgreSQL 재시작

일반적으로 Linux 패키지 설치는 gitlab.rb 파일에서 해당 서비스의 구성 설정이 변경된 경우 재구성 시 해당 서비스를 자동으로 다시 시작합니다. PostgreSQL은 특정 설정이 다시 로드(HUP)될 때도 있고, 다시 시작해야 하는 설정도 있습니다. 따라서 PostgreSQL을 명시적으로 다시 시작하고 싶어 하는 관리자들을 위해 Linux 패키지 설치는 재구성 시 PostgreSQL을 다시 시작하는 대신 다시 로드합니다. 이는 만약 다시 시작이 필요한 PostgreSQL 설정을 수정한다면, 재구성 후에 PostgreSQL을 수동으로 다시 시작해야 함을 의미합니다.

GitLab 구성 템플릿은 PostgreSQL 설정 중 다시 시작이 필요한 설정과 다시 로드만 필요한 설정을 확인할 수 있습니다. 또한, 데이터베이스 상에 대한 쿼리를 실행하여 개별 설정이 다시 시작을 필요로 하는지 확인할 수 있습니다. 다음 쿼리에서 sudo gitlab-psql을 사용하여 데이터베이스 콘솔을 시작한 후, <설정 이름>을 변경하는 설정으로 대체하세요:

SELECT name, setting FROM pg_settings WHERE context = 'postmaster' AND 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).
서버의 인증서를 유효화하는 루트 인증서 번들(root.crt). 기본적으로 Linux 패키지 설치는 /opt/gitlab/embedded/ssl/certs/cacert.pem에 포함된 내장 인증서 번들을 사용합니다. 이는 자체 서명된 인증서에는 필요하지 않습니다.

Linux 패키지 설치에서는 사용할 10년간의 자체 서명된 인증서와 개인 키가 생성됩니다. 자체 서명된 인증서를 사용하거나 사용자 지정 자체 서명된 인증서로 교체하려면 다음 단계를 따르세요.

이 파일들의 위치는 구성할 수 있지만, 개인 키는 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을 사용하고 있는지 확인하려면 다음을 실행할 수 있습니다:

GitLab 14.2 버전 및 이후에서:

sudo gitlab-rails dbconsole --database main

GitLab 14.1 및 이전 버전에서:

sudo gitlab-rails dbconsole

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

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

데이터베이스 서버 구성

서버용 인증서와 키를 생성하세요. 공통 이름은 서버의 DNS 이름과 같아야 합니다.
서버 인증서, 키 및 CA 파일을 PostgreSQL 서버로 복사하고 권한을 올바르게 설정하세요
1. 인증서는 데이터베이스 사용자(default: 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 주소 범위를 지정할 때는 CIDR 표기법을 사용할 수 있습니다.
새 설정이 적용되려면 gitlab-ctl reconfigure 및 gitlab-ctl restart postgresql을 실행하세요.

Rails 클라이언트 구성

Rails 클라이언트가 서버에 연결하려면 commonName이 gitlab으로 설정된 인증서와 키가 필요합니다. 이는 데이터베이스 서버의 ssl_ca_file에서 신뢰할 수 있는 인증 기관에 의해 서명되어야 합니다.

gitlab.rb 구성하기

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

새 설정을 사용하도록 Rails 클라이언트를 위해 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 인증을 위해 허용하는 암호를 설정합니다. 다음 예제에서 securesqlpassword를 수용 가능한 암호로 바꿉니다.

/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 사용자의 이름입니다. (작은따옴표로 감싸 셸 보간을 피합니다.)
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 서비스는 사용자명을 sql_user 값으로, PostgreSQL 서버에 연결할 때 구성된 암호와 함께 제공해야 합니다. 이 값들은 또한 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을 사용하여 서비스를 직접 다시 시작해보세요.

Linux 패키지에 포함된 일부 스크립트(예: gitlab-psql)는 PostgreSQL과의 연결을 UNIX 소켓을 통해 처리되도록 기대하며, 그렇지 않으면 제대로 기능하지 않을 수 있습니다. UNIX 소켓을 비활성화하지 않고 TCP/IP를 활성화할 수 있습니다.

PostgreSQL WAL(Write Ahead Log) Archiving 활성화

기본적으로, Linux 패키지의 PostgreSQL은 WAL 아카이빙이 비활성화되어 있습니다. WAL 아카이빙을 활성화하려면 다음을 고려하세요:

WAL 레벨은 ‘replica’ 이상이어야 합니다 (9.6+에서의 옵션은 minimal, replica, 또는 logical입니다)
WAL 레벨을 높이면 정상 작업에서 사용하는 저장 공간이 증가합니다.

WAL 아카이빙을 활성화하려면:

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

# Replication settings
postgresql['sql_replication_user'] = "gitlab_replicator"
postgresql['wal_level'] = "replica"
    ...
    ...
# Backup/Archive settings
postgresql['archive_mode'] = "on"
postgresql['archive_command'] = "/your/wal/archiver/here"
postgresql['archive_timeout'] = "60"

변경 사항이 적용되려면 GitLab 다시 구성을 수행해야 합니다. 이로써 데이터베이스가 재시작됩니다.

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

기본적으로 모든 것이 /var/opt/gitlab/postgresql 아래에 저장되며, 이는 postgresql['dir'] 속성으로 제어됩니다.

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

데이터베이스 소켓은 /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을 기본으로 제공된 버전으로 업데이트 합니다. 특별히 자동 PostgreSQL 업그레이드에서 선택하지 않은 경우에 해당합니다.

새 버전의 GitLab로 업그레이드하기 전에 Linux 패키지의 버전별 변경 내용을 참조하여 다음을 확인하세요:

데이터베이스 버전이 변경되었는지 확인합니다.
업그레이드가 필요한 경우 확인합니다.

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

참고: 업그레이드 중에 문제가 발생한 경우 omnibus-gitlab 이슈 트래커에서 모든 설명을 포함하여 이슈를 제기해야 합니다.

PostgreSQL 버전을 업그레이드하기 전에 다음 사항을 확인하세요:

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

위의 체크리스트를 만족했는지 확인한 후에 업그레이드를 진행하세요:

sudo gitlab-ctl pg-upgrade

특정 PostgreSQL 버전으로 업그레이드하려면 -V 플래그를 사용하여 버전을 지정하세요. 예를 들어, PostgreSQL 14로 업그레이드하려면 다음과 같이 사용합니다:

sudo gitlab-ctl pg-upgrade -V 14

참고: pg-upgrade에는 인수를 전달할 수 있습니다. 예를 들어, 백그라운드 명령의 실행 시간 초과를 설정할 수 있습니다 (--timeout=1d2h3m4s5ms). 전체 목록을 확인하려면 gitlab-ctl pg-upgrade -h를 실행하세요.

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

데이터베이스가 정상인지를 확인합니다.
충분한 무료 디스크 공간이 있는지 확인하고 아니면 중단합니다. --skip-disk-check 플래그를 추가하여 이를 건너뛸 수 있습니다.
기존 데이터베이스를 종료하고 불필요한 서비스를 중지하며, GitLab을 배포 페이지로 활성화합니다.
/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;'

GitLab 인스턴스가 올바르게 작동하는지 확인했다면, 이전 데이터베이스 파일을 정리할 수 있습니다:

sudo rm -rf /var/opt/gitlab/postgresql/data.<이전_버전>
sudo rm -f /var/opt/gitlab/postgresql-version.old

GitLab 버전에 따라 패키지에 포함된 PostgreSQL 버전의 자세한 내용을 확인할 수 있습니다. PostgreSQL versions shipped with the Linux package.

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

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

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

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

경고: 이 작업은 현재 데이터베이스를 이전 업그레이드 전으로 되돌립니다. PostgreSQL 데이터베이스를 다운그레이드하기 전에 반드시 백업을 만들어 주세요.

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

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

gitlab-ctl revert-pg-upgrade -V 12

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

오직 하나의 PostgreSQL 버전만을 제공하는 다른 GitLab 버전의 경우, PostgreSQL 버전을 다운그레이드할 수 없습니다. 이 경우 이전 버전의 GitLab로 다운그레이드해야 합니다.

다중 데이터베이스 연결 구성

gitlab:db:decomposition:connection_status Rake task는 GitLab 15.11에서 소개되었습니다.

GitLab 16.0에서 GitLab은 기본적으로 동일한 PostgreSQL 데이터베이스를 가리키는 두 개의 데이터베이스 연결을 사용합니다.

GitLab 16.0으로 업그레이드하기 전에, PostgreSQL의 max_connections 설정이 충분히 높아서 여분의 연결이 사용되지 않고 남아있는 연결의 50% 이상임을 확인해 주세요. 예를 들어, max_connections가 100으로 설정되어 있고 75개의 연결이 사용 중이라면, 업그레이드하기 전에 max_connections를 적어도 150으로 늘려주셔야 합니다. 업그레이드 후에 사용 중인 연결은 150개로 두배로 증가될 것입니다.

다음의 Rake task를 실행하여 확인할 수 있습니다:

sudo gitlab-rake gitlab:db:decomposition:connection_status

만일 작업이 max_connections가 충분히 높다고 나타내면, 업그레이드를 진행할 수 있습니다.

어떠한 이유로든지, 단일 연결 상태를 유지하고 싶고, GitLab 15.11 또는 그 이전 버전에서 GitLab 16.0으로 업그레이드하는 경우, 또는 단일 데이터베이스 연결로 다시 변경하려면 /etc/gitlab/gitlab.rb에서 이 설정을 업데이트하세요:

gitlab_rails['databases']['ci']['enable'] = false

다중 노드 환경에서는, 이 설정을 모든 Rails 및 Sidekiq 노드에 업데이트해야 합니다.

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

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

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

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

# 데이터베이스.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'] = '사용자이름'
gitlab_rails['db_password'] = '비밀번호'
```
이러한 줄들의 맨 앞의 # 주석 문자를 제거하는 것을 잊지 마세요.
주의할 점:
- /etc/gitlab/gitlab.rb은 평문 비밀번호를 포함하고 있기 때문에 파일 권한이 0600이 되어야 합니다.
- PostgreSQL은 여러 주소에 대한 리스닝을 허용합니다.
  gitlab_rails['db_host']에 여러 주소를 콤마(,)로 구분하여 사용하는 경우, 목록에서 첫 번째 주소가 연결에 사용됩니다.
변경사항이 적용되도록 GitLab 재구성을 수행하세요.
데이터베이스 시드 구성.

패키지되지 않은 PostgreSQL을 위한 UNIX 소켓 구성

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

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

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

# 데이터베이스.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'] = "<full_path_to_your_ca-bundle.pem>"
```
PostgreSQL 서버에 Amazon RDS를 사용하는 경우, gitlab_rails['db_sslrootcert']에 결합된 CA 번들을 다운로드하여 사용하십시오. 자세한 내용은 AWS의 SSL/TLS를 사용하여 DB 인스턴스에 대한 연결 암호화 문서에서 확인할 수 있습니다.
구성 변경을 적용하려면 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 클라이언트 도구를 설치하는 여러 가지 방법이 있습니다. 옵션은 여기에서 확인할 수 있습니다.

올바른 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 버전이 필요한 GitLab 버전을 확인하십시오.
- Linux 패키지와 함께 제공된 PostgreSQL 버전에서 중요한 변경 사항을 확인하십시오: Linux 패키지의 호환성은 함께 제공되는 PostgreSQL의 주요 릴리스와 테스트되었습니다.
GitLab 백업 또는 복원을 사용할 때, 반드시 동일한 GitLab 버전을 유지해야 합니다. 나중에 GitLab 버전을 업그레이드할 계획이 있다면 PostgreSQL을 먼저 업그레이드하십시오.
백업 및 복원 명령을 사용하여 데이터베이스를 나중의 PostgreSQL 버전으로 백업 및 복원할 수 있습니다.
postgresql['version']으로 지정된 PostgreSQL 버전이 Linux 패키지 릴리스와 함께 제공되지 않는 경우, 호환성 표의 기본 버전에서 사용할 클라이언트 바이너리(예: PostgreSQL 백업/복원 바이너리)가 결정됩니다.

다음 예시는 PostgreSQL 12에서 PostgreSQL 13으로의 데이터베이스 호스트를 업그레이드하는 것을 보여주며, 이 작업은 다운타임을 유발합니다:

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

경고: 설치에서 PgBouncer를 사용하는 경우 추가 매개변수가 필요한 백업 명령.

SKIP 옵션을 사용하여 백업 Rake 작업을 실행하여 데이터베이스만 백업하십시오. 나중에 복원에 사용할 백업 파일 이름을 기록하십시오.
```
sudo gitlab-backup create SKIP=repositories,uploads,builds,artifacts,lfs,pages,registry
```
PostgreSQL 12 데이터베이스 호스트를 종료하십시오.
/etc/gitlab/gitlab.rb를 편집하고 gitlab_rails['db_host'] 설정을 PostgreSQL 데이터베이스 13 호스트로 변경하십시오.
GitLab을 다시 구성하십시오:
```
sudo gitlab-ctl reconfigure
```
경고: 설치에서 PgBouncer를 사용하는 경우 추가 매개변수가 필요한 백업 명령.
데이터베이스 백업 파일을 사용하여 데이터베이스를 복원하고 “이 작업은 이제 authorized_keys 파일을 다시 빌드합니다”라는 질문에 아니요라고 응답하십시오:
```
# 백업 타임스탬프 사용 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;
```
pg_dump 및 pg_restore를 사용하여 업그레이드를 한 경우, PostgreSQL 데이터베이스 콘솔에서 다음 쿼리를 실행하십시오.
```
SET statement_timeout = 0; VACUUM ANALYZE VERBOSE;
```

데이터베이스 시드하기 (새 설치만)

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

Linux 패키지 설치는 외부 데이터베이스에 시드되지 않습니다. 다음 명령을 실행하여 스키마를 가져오고 첫 번째 관리자 사용자를 만듭니다:

# 'git' 사용자라면 'sudo'를 제거하세요
sudo gitlab-rake gitlab:setup

기본 root 사용자의 비밀번호를 지정하려면 위의 gitlab:setup 명령을 실행하기 전에 /etc/gitlab/gitlab.rb의 initial_root_password 설정을 지정하세요:

gitlab_rails['initial_root_password'] = 'nonstandardpassword'

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

gitlab_rails['initial_shared_runners_registration_token'] = 'token'

패키지된 PostgreSQL 버전 고정하기 (새 설치만)

참고: GitLab 14.1부터 Postgres 12 및 Postgres 13이 함께 제공됩니다. GitLab 14.0은 PostgreSQL 12만 제공합니다. GitLab 13.3부터 Postgres 11 및 Postgres 12가 함께 제공됩니다. GitLab 13.0부터 13.2는 PostgreSQL 11만 제공했습니다.

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

경고: 초기 다시 구성 후 Linux 패키지와 함께 패키지된 PostgreSQL을 사용하는 동안 postgresql['version']을 설정하면 데이터 디렉토리가 다른 버전의 PostgreSQL에서 초기화되었다는 오류가 발생합니다. 이에 부딪히면 패키지된 PostgreSQL 서버를 이전 버전으로 되돌리기를 참조하세요.

GitLab을 이전에 설치한 환경에 새로 설치하고 고정된 PostgreSQL 버전을 사용하는 경우, PostgreSQL과 관련된 폴더가 모두 삭제되었는지, 인스턴스에서 실행 중인 PostgreSQL 프로세스가 없는지 확인하세요.

민감한 데이터 구성을 평문 저장 없이 GitLab Rails에 제공하기

자세한 내용은 구성 문서의 예제를 참조하세요.

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

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

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

/etc/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초로 설정됩니다. 값은 밀리초로 지정됩니다.

연결 시간 초과 설정하기

데이터베이스 연결 시도가 성공하기까지 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']`

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

소개됨: GitLab 13.5.

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

백그라운드에서 데이터베이스 인덱스를 다시 만들어줍니다(재인덱싱이라고 함). 이를 통해 쌓인 공간을 제거하고 건강하고 효율적인 인덱스를 유지하는 데 도움이 될 수 있습니다.

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

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

기본적으로 이는 주말에 매 시간 cron 작업을 시작합니다(아마도 저 트래픽 시간에만).

다음 설정을 정확히 조정하여 스케줄을 변경할 수 있습니다.

/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를 데이터베이스 노드 수 + 1로 교체하십시오
postgresql['max_replication_slots'] = X
```
1. 구성을 업데이트하려면 gitlab-ctl reconfigure를 실행하십시오.
2. 새 구성으로 PostgreSQL을 다시 시작하려면 sudo gitlab-ctl restart postgresql를 실행하십시오.
3. PostgreSQL 보조 노드에서 pg-upgrade를 실행하면 노드가 클러스터에서 제거됩니다.
4. 보조 노드에서 pg-upgrade를 실행하면 새 버전과 일치하도록 기존 데이터를 업데이트하지 않으며 해당 데이터는 백업 위치로 이동합니다.
모든 보조 노드를 업그레이드한 후, 기본 노드에서 pg-upgrade를 실행하십시오.
1. 기본 노드에서 다음을 포함하여 /etc/gitlab/gitlab.rb를 수정하십시오.
```
# X를 데이터베이스 노드 수 + 1로 교체하십시오
postgresql['max_replication_slots'] = X
```
1. 구성을 업데이트하려면 gitlab-ctl reconfigure를 실행하십시오.
2. 새 구성으로 PostgreSQL을 다시 시작하려면 sudo gitlab-ctl restart postgresql를 실행하십시오.
3. 기본 노드에서 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 스트리밍 복제를 Geo의 보조 노드에게 다시 초기화해야 하기 때문입니다. 이는 PostgreSQL 스트리밍 복제의 작동 방식 때문입니다. 복제를 다시 초기화하면 모든 데이터가 기본 데이터베이스에서 복사되므로, 데이터베이스의 크기와 사용 가능 대역폭에 따라 시간이 오래 걸릴 수 있습니다. 예를 들어, 전송 속도가 30 Mbps이고 데이터베이스 크기가 100GB일 때, 재동기화에는 약 8시간이 걸릴 수 있습니다. 자세한 내용은 PostgreSQL 문서를 참조하세요.

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

GitLab 12.1부터 GitLab 12.9까지, GitLab 패키지 업그레이드는 PostgreSQL을 10.x 버전으로 업그레이드하려고 시도합니다. 그러나 GitLab 12.10 이후에는 Geo를 사용할 때 PostgreSQL의 업그레이드가 자동으로 이루어지지 않습니다.

GitLab 12.1부터 12.9까지 업그레이드하기 전에 PostgreSQL의 자동 업그레이드를 비활성화하고 GitLab 패키지 업그레이드와 별도로 PostgreSQL을 수동으로 업그레이드하는 것을 강력히 권장합니다.

postgresql이나 geo-postgresql을 실행 중인 모든 노드에서 다음 명령을 실행하여 PostgreSQL의 자동 업그레이드를 비활성화할 수 있습니다:

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

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

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

Geo 기본 데이터베이스 노드에서 기존 복제 슬롯의 이름을 찾으려면 다음을 실행하세요:
```
sudo gitlab-psql -qt -c 'select slot_name from pg_replication_slots'
```
여기서 slot_name을 찾을 수 없거나 출력된 내용이 없는 경우, Geo 보조 노드가 건강하지 않을 수 있습니다. 이 경우, 보조 노드의 건강 상태와 복제 작동 여부를 확인하세요.
복제 사용자의 암호를 수집하세요. 이는 단계 1. 기본 사이트 구성에서 설정되었습니다.
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
```
이 과정에서 기본 데이터베이스의 복제 사용자 암호가 요청됩니다. 첫 번째 단계에서 검색한 슬롯 이름으로 SECONDARY_SLOT_NAME을 대체하세요.
Geo 보조 데이터베이스에서 GitLab을 다시 구성하여 pg_hba.conf 파일을 업데이트하세요. 이 작업은 replicate-geo-database가 기본 데이터베이스의 파일을 보조 데이터베이스로 복제하기 때문에 필요합니다.

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 데이터베이스에 연결해야 한다면, 애플리케이션 사용자로 연결할 수 있습니다:

GitLab 14.2 및 이후:

sudo gitlab-rails dbconsole --database main

GitLab 14.1 이전:

sudo gitlab-rails dbconsole

또는 PostgreSQL 수퍼사용자로:

sudo gitlab-psql -d gitlabhq_production

문제 해결

`default_transaction_isolation`을 `read committed`로 설정

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

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

당신의 데이터베이스의 default_transaction_isolation 구성이 GitLab 애플리케이션 요구 사항과 일치하지 않을 수 있습니다. 이 구성을 확인하고, 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

# Geo PostgreSQL용
sudo gitlab-ctl restart geo-postgresql

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

데이터베이스 설정

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

재구성 및 PostgreSQL 재시작

PostgreSQL 버전 변경 시 자동 재시작

SSL 구성

SSL 필요

SSL 비활성화

SSL 사용 여부 확인

SSL 클라이언트 인증 구성

데이터베이스 서버 구성

Rails 클라이언트 구성

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

PostgreSQL 블록 구성

GitLab Rails 블록 구성

서비스 적용 및 재시작

PostgreSQL WAL(Write Ahead Log) Archiving 활성화

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을 업그레이드할 때 유의해야 할 점

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

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

PostgreSQL 데이터베이스 연결

문제 해결

default_transaction_isolation을 read committed로 설정

plpgsql.so 라이브러리를 불러올 수 없음

도움말

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

도움받기

`default_transaction_isolation`을 `read committed`로 설정

`plpgsql.so` 라이브러리를 불러올 수 없음