지오프레미엄 데이터베이스 복제

Tier: 프리미엄, 얼티밋 Offering: Self-managed

이 문서는 기본 GitLab 데이터베이스를 보조 사이트의 데이터베이스로 복제하는 데 필요한 최소한의 단계에 대해 설명합니다. 데이터베이스 설정과 크기와 같은 속성에 따라 일부 값은 변경해야 할 수 있습니다.

참고: GitLab 설치에서 외부 PostgreSQL 인스턴스(리눅스 패키지 설치로 관리되지 않음)를 사용하는 경우 역할은 모든 필요한 구성 단계를 수행할 수 없습니다. 이 경우 외부 PostgreSQL 인스턴스와 함께 하는 Geo프로세스를 대신 사용하십시오.

참고: 설치 프로세스의 단계는 문서화된 순서대로 완료되어야 합니다. 그렇지 않은 경우 진행하기 전에 이전의 모든 단계를 완료하십시오.

보조 사이트가 주요 사이트와 동일한 GitLab Enterprise Edition 버전을 실행 중인지 확인하세요. 주요 사이트에 프리미엄 또는 얼티밋 구독 라이센스가 추가되었는지 확인하세요.

테스트 또는 프로덕션 환경에서 실행하기 전에 이러한 단계를 모두 읽고 검토하세요.

단일 인스턴스 데이터베이스 복제

단일 인스턴스 데이터베이스 복제는 설정이 쉽고 클러스터화된 대체 옵션과 동일한 Geo 기능을 제공합니다. 단일 기계에서 실행되거나 향후 클러스터 설치에 대한 Geo를 평가하는 설정에 유용합니다.

단일 인스턴스는 고가용성 아키텍처를 위해 권장되는 Patroni를 사용하여 클러스터화된 버전으로 확장할 수 있습니다.

아래 지침에 따라 PostgreSQL 복제를 단일 인스턴스 데이터베이스로 설정하는 방법을 따르세요. 또는 다중 노드 데이터베이스 복제 지침을 참조하여 Patroni 클러스터를 사용하여 복제를 설정할 수 있습니다.

PostgreSQL 복제

쓰기 작업이 발생하는 GitLab 주요 사이트는 주요 데이터베이스 서버에 연결합니다. 보조 사이트는 각자의 데이터베이스 서버(읽기 전용)에 연결합니다.

PostgreSQL의 복제 슬롯을 사용하여 주요 사이트가 보조 사이트가 복구하는 데 필요한 모든 데이터를 보유하도록 보장하세요. 자세한 내용은 아래를 참조하세요.

다음 가이드는 다음을 가정합니다.

Linux 패키지를 사용하고 있으며(pg_basebackup 도구](https://www.postgresql.org/docs/12/app-pgbasebackup.html)를 포함), PostgreSQL 12 이상을 사용하고 있습니다.
이미 주요 사이트를 설정했으며, 리눅스 패키지 설치에 의해 관리되는 PostgreSQL(또는 해당 버전)이 실행 중이며, 모든 사이트에서 동일한 PostgreSQL 버전, OS 및 GitLab을 실행 중입니다.

경고: Geo는 스트리밍 복제와 함께 작동합니다. 현재 논의 중인 논의 중인 지원에 대한 이슈가 있습니다. 논리적 복제는 현재 지원되지 않습니다.

단계 1. 주요 사이트 구성

GitLab 주요 사이트에 SSH로 로그인하여 root 계정으로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집하고 사이트에 고유한 이름을 추가하십시오:

##
## Geo 사이트에 대한 고유 식별자입니다. 자세한 내용은 아래 링크를 참조하십시오.
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

변경 사항이 적용되도록 주요 사이트를 다시 구성합니다:
```
gitlab-ctl reconfigure
```
아래 명령을 실행하여 사이트를 주요 사이트로 정의합니다:
```
gitlab-ctl set-geo-primary-node
```
이 명령은 /etc/gitlab/gitlab.rb의 정의된 external_url을 사용합니다.

gitlab 데이터베이스 사용자의 암호를 정의합니다:

원하는 암호의 MD5 해시를 생성합니다:

gitlab-ctl pg-password-md5 gitlab
# 암호 입력: <your_password_here>
# 암호 확인: <your_password_here>
# fca0b89a972d69f00eb3ec98a5838484

/etc/gitlab/gitlab.rb를 편집합니다:

# `gitlab-ctl pg-password-md5 gitlab`에 의해 생성된 해시로 채웁니다
postgresql['sql_user_password'] = '<md5_hash_of_your_password>'

# Puma 또는 Sidekiq를 실행하는 모든 노드에는 아래와 같이 데이터베이스
# 암호가 지정되어야 합니다. 고가용성 설정일 경우 모든 응용 프로그램 노드에
# 이 정보가 있어야 합니다.
gitlab_rails['db_password'] = '<your_password_here>'

데이터베이스 복제 사용자의 암호를 정의합니다.
/etc/gitlab/gitlab.rb에서 postgresql['sql_replication_user'] 설정에 정의된 사용자 이름을 사용합니다. 기본값은 gitlab_replicator입니다. 만약 사용자 이름을 다른 값으로 변경했다면 아래 지침을 적응시키세요.
원하는 암호의 MD5 해시를 생성합니다:
```
gitlab-ctl pg-password-md5 gitlab_replicator
# 암호 입력: <your_password_here>
# 암호 확인: <your_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e
```
/etc/gitlab/gitlab.rb를 편집합니다:
```
# `gitlab-ctl pg-password-md5 gitlab_replicator`에 의해 생성된 해시로 채웁니다
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
```
리눅스 패키지 설치로 관리되는 외부 데이터베이스를 사용하는 경우, gitlab_replicator 사용자를 만들고 해당 사용자의 암호를 수동으로 정의해야 합니다.
```
--- 신규 사용자 'replicator' 생성
CREATE USER gitlab_replicator;

--- 암호 설정 및 복제 권한 부여
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';
```
/etc/gitlab/gitlab.rb를 편집하고 geo_primary_role 역할을 설정합니다(Geo roles을 참조하세요):
```
## Geo Primary role
roles(['geo_primary_role'])
```

네트워크 인터페이스에서 PostgreSQL을 수신하도록 PostgreSQL을 구성합니다:

보안상의 이유로, 기본적으로 PostgreSQL은 어떠한 네트워크 인터페이스에서도 수신하지 않습니다. 그러나 Geo는 [주요** 사이트가 보조 사이트의 데이터베이스에 연결할 수 있도록 필요합니다. 이를 위해 각 사이트의 IP 주소가 필요합니다.

참고: 외부 PostgreSQL 인스턴스를 사용하는 경우 추가 지침을 참조하십시오.

클라우드 제공 업체를 사용하는 경우 클라우드 제공 업체의 관리 콘솔을 통해 각 Geo 사이트의 주소를 조회할 수 있습니다.

Geo 사이트의 주소를 조회하려면 Geo 사이트에 SSH로 로그인하여 다음을 실행하세요:

##
## 개인 주소
##
ip route get 255.255.255.255 | awk '{print "Private address:", $NF; exit}'

##
## 외부 주소
##
echo "외부 주소: $(curl --silent "ipinfo.io/ip")"

대부분의 경우, GitLab Geo를 구성하기 위해 다음 주소가 사용됩니다:

구성	주소
`postgresql['listen_address']`	주요 사이트의 공용 또는 VPC 개인 주소.
`postgresql['md5_auth_cidr_addresses']`	주요 및 보조 사이트의 공용 또는 VPC 개인 주소.

Google Cloud Platform, SoftLayer 또는 기타 가상 개인 클라우드(VPC)를 제공하는 공급업체를 사용하는 경우, VPC 주소의 “private” 또는 “internal” 주소를 postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에 사용하기를 권장합니다.

listen_address 옵션은 주어진 주소에 해당하는 인터페이스에 대한 네트워크 연결을 PostgreSQL에 엽니다. 자세한 내용은 PostgreSQL 문서를 참조하십시오.

참고: 0.0.0.0 또는 *를 listen_address로 사용해야 하는 경우, postgresql['md5_auth_cidr_addresses'] 설정에 127.0.0.1/32를 추가하여 Rails가 127.0.0.1을 통해 연결할 수 있도록 해야 합니다. 자세한 내용은 이슈 5258을 참조하십시오.

네트워크 구성에 따라 제안된 주소가 잘못될 수 있습니다. 주요 사이트와 보조 사이트가 로컬 영역 네트워크 또는 Amazon의 VPC, Google의 VPC와 같은 가용성 영역을 연결하는 가상 네트워크를 통해 연결하는 경우, postgresql['md5_auth_cidr_addresses']에는 보조 사이트의 개인 주소를 사용해야 합니다.

/etc/gitlab/gitlab.rb를 편집하고 아래 내용을 추가합니다. 주소는 네트워크 구성에 맞게 변경합니다:

##
## 주요 주소
## - '<primary_node_ip>'를 Geo 주요 노드의 공용 또는 VPC 주소로 대체합니다
##
postgresql['listen_address'] = '<primary_site_ip>'

##
# PostgreSQL 클라이언트 인증을 주요 및 보조 IP에서 허용합니다. 이들 IP는
# 공용 또는 VPC 주소로 CIDR 형식으로 표시됩니다. 예를 들어 ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

##
## 복제 설정
##
# postgresql['max_replication_slots'] = 1 # Geo 보조 노드 개수에 따라 설정하세요
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

PostgreSQL이 개인 주소에서 수신하고 있고 복제 슬롯 변경이 적용되도록 데이터베이스 listen 변경을 위해 GitLab을 다시 구성합니다.
```
gitlab-ctl reconfigure
```
효력을 발휘하기 위해 PostgreSQL을 다시 시작합니다:
```
gitlab-ctl restart postgresql
```
PostgreSQL 서버가 원격 연결을 받아들일 수 있도록 설정되었으므로, netstat -plnt | grep 5432를 실행하여 PostgreSQL이 주요 사이트의 개인 주소에서 포트 5432에서 수신하는지 확인하세요.
인증서가 GitLab을 다시 구성할 때 자동으로 생성됩니다. 이는 주요 사이트의 PostgreSQL 트래픽을 도청하는 자들로부터 보호하는 데 자동으로 사용됩니다. 활성(“중간에서 가로채기”) 공격자에 대한 보호를 위해 보조 사이트에 인증서 사본이 필요합니다. 주요 사이트의 PostgreSQL server.crt 파일을 다음 명령으로 복사하세요:
```
cat ~gitlab-psql/data/server.crt
```
출력을 클립보드에 복사하거나 로컬 파일에 붙여넣으세요. 이를 설정 시 필요합니다! 인증서는 민감한 데이터가 아닙니다.
그러나 이 인증서는 일반적인 PostgreSQL 공통 이름으로 생성됩니다. 이에 대응하여 보조 사이트에서 데이터베이스를 복제할 때 verify-ca 모드를 사용해야 하며, 그렇지 않으면 호스트명 불일치가 오류를 발생시킵니다.
선택 사항. 직접 SSL 인증서를 생성하고 PostgreSQL을 위해 SSL을 구성하여 생성된 인증서 대신에 사용할 수 있습니다.
적어도 SSL 인증서와 키가 필요합니다. postgresql['ssl_cert_file'] 및 postgresql['ssl_key_file'] 값을 데이터베이스 SSL 문서에 따라 전체 경로로 설정합니다.
이를 사용하여 데이터베이스 복제 시 verify-full SSL 모드를 사용하고 CN에서 호스트명 일치를 확인할 수 있는 추가 혜택을 얻으려고 합니다.
이 인증서를 (앞서 설정한 postgresql['ssl_cert_file']에 설정 한 것처럼) 준비하여, 이후부터 위의 포인트에서 생성된 인증서를 대신 사용할 수 있습니다. CN이 일치하는 경우 verify-full을 사용하여 복제 오류 없이 verify-full을 사용할 수 있습니다.
CN이 일치하지 않는 경우 본 포인

단계 2. 보조 서버 구성

GitLab 보조 사이트에 SSH로 로그인한 후 root로 로그인합니다.
```
sudo -i
```
애플리케이션 서버 및 Sidekiq를 중지합니다.
```
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
```
참고: 이 단계는 사이트가 완전히 구성되기 전에 어떤 작업도 실행하지 않도록 하는 데 중요합니다.
주 사이트의 PostgreSQL 서버와의 TCP 연결을 확인합니다. (링크)
```
gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]
```
참고: 이 단계에서 실패하는 경우 잘못된 IP 주소를 사용하거나 방화벽이 사이트 접속을 막고 있을 수 있습니다. 공용 및 사설 주소의 차이에 주의하세요. 방화벽이 있는 경우 보조 사이트에서 주 사이트로의 포트 5432에서의 연결을 허용했는지 확인하세요.
보조 사이트에 server.crt 파일을 생성하고, 이 파일에는 주 사이트 설정의 마지막 단계에서 얻은 내용을 넣습니다.
```
editor server.crt
```
보조 사이트에서 PostgreSQL TLS 검증 설정합니다.
server.crt 파일을 설치합니다.
```
install \
   -D \
   -o gitlab-psql \
   -g gitlab-psql \
   -m 0400 \
   -T server.crt ~gitlab-psql/.postgresql/root.crt
```
PostgreSQL은 이제 TLS 연결을 확인할 때 해당 인증서만 인식합니다. 해당 인증서는 주 사이트에만 있는 개인 키에 접근할 수 있는 사용자만 복제할 수 있습니다.
gitlab-psql 사용자가 주 사이트의 데이터베이스에 연결할 수 있는지 테스트합니다 (리눅스 패키지 설치의 경우 기본 데이터베이스 이름은 gitlabhq_production입니다).
```
sudo \
   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
   --list \
   -U gitlab_replicator \
   -d "dbname=gitlabhq_production sslmode=verify-ca" \
   -W \
   -h <primary_site_ip>
```
참고: 수동으로 생성된 인증서를 사용하고 전체 호스트 이름 확인을 위해 sslmode=verify-full을 사용하려는 경우, 명령을 실행할 때 verify-ca를 verify-full로 바꿉니다.
프롬프트가 표시되면, 처음 단계에서 설정한 평문 암호를 입력하세요. 모든 작업이 올바로 진행되었다면, 주 사이트의 데이터베이스 목록이 표시됩니다.
여기서 연결 실패가 발생하면 TLS 구성이 올바르지 않은 것입니다. 주 사이트의 ~gitlab-psql/data/server.crt의 내용이 보조 사이트의 ~gitlab-psql/.postgresql/root.crt의 내용과 일치하는지 확인하세요.
/etc/gitlab/gitlab.rb 파일을 편집하고 역할을 geo_secondary_role로 설정합니다. (자세한 내용은 Geo roles를 참조하세요.)
```
##
## Geo Secondary role
## - configure dependent flags automatically to enable Geo
##
roles(['geo_secondary_role'])
```

PostgreSQL을 구성합니다.

이 단계는 주 인스턴스를 구성한 방법과 유사합니다. 단일 노드를 사용하는 경우에도 활성화해야 합니다.

/etc/gitlab/gitlab.rb 파일을 편집하고 아래 항목을 추가합니다. IP 주소는 네트워크 구성에 맞게 해당 주소로 교체하세요.

##
## Secondary address
## - replace '<secondary_site_ip>' with the public or VPC address of your Geo secondary site
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']

##
## Database credentials password (defined previously in primary site)
## - primary site에서 정의한 것과 동일한 값을 여기에 복제합니다
##
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
gitlab_rails['db_password'] = '<your_password_here>'

외부 PostgreSQL 인스턴스의 경우 추가 지침을 참조하세요. 주 사이트를 보조 사이트로 다시 온라인 상태로 변경하려면 roles(['geo_primary_role']) 또는 geo_primary_role['enable'] = true를 제거해야 합니다.

변경 사항이 적용되도록 GitLab을 다시 구성합니다.
```
gitlab-ctl reconfigure
```
IP 변경이 적용되도록 PostgreSQL을 다시 시작합니다.
```
gitlab-ctl restart postgresql
```

단계 3. 복제 프로세스 시작

아래는 secondary 사이트의 데이터베이스를 primary 사이트의 데이터베이스에 연결하는 스크립트입니다. 이 스크립트는 데이터베이스를 복제하고 스트리밍 복제를 위해 필요한 파일을 생성합니다.

Linux 패키지 설치에서 설정한 기본 디렉토리를 사용합니다. 기본값을 변경했다면 스크립트를 그에 맞게 구성하세요(디렉토리와 경로를 대체).

경고: 이 작업은 secondary 사이트에서 실행하여 pg_basebackup을 실행하기 전에 모든 PostgreSQL 데이터를 제거합니다.

GitLab secondary 사이트에 SSH로 로그인하고 루트로 전환하세요:
```
sudo -i
```
데이터베이스 친화적인 이름을 선택하여 secondary 사이트에 복제 슬롯 이름으로 사용하세요. 예를 들어, 도메인이 secondary.geo.example.com이라면 아래 명령어에서와 같이 secondary_example을 슬롯 이름으로 사용하세요.
아래 명령어를 실행하여 백업/복원을 시작하고 복제를 시작하세요
경고: 각 Geo secondary 사이트는 고유한 복제 슬롯 이름이 있어야 합니다. 두 개의 secondary가 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 실패합니다.
참고: 복제 슬롯 이름은 소문자, 숫자, 밑줄 문자만 포함해야 합니다.
프스트 단계에서 gitlab_replicator 사용자의 평문 암호를 입력했을 때, 해당 암호를 입력하세요.
```
gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca
```
참고: 만약 사용자 정의 PostgreSQL 인증서를 생성했다면, 추가 보안을 위해 --sslmode=verify-full을 사용해야 합니다 (sslmode 줄을 제외하거나 옵트해도 됨). 그렇지 않으면 verify-full로 자동으로 생성된 인증서를 사용하면 실패합니다. 이는 PostgreSQL 일반적인 CN을 갖고 있기 때문에 이 명령어의 --host 값과 일치하지 않기 때문입니다.
이 명령어는 여러 가지 추가 옵션을 사용합니다. 모든 옵션을 보려면 --help를 사용할 수 있지만, 여기 몇 가지 팁이 있습니다:
- PostgreSQL이 비표준 포트에서 수신 중이라면 --port=를 추가하세요.
- 데이터베이스가 30분 안에 전송될 수 없을 정도로 커다라면, 시간 제한을 늘려야 합니다. 예를 들어, 초기 복제가 1시간 이내로 완료될 것으로 예상된다면 --backup-timeout=3600을 사용하세요.
- PostgreSQL TLS 인증을 완전히 건너뛰려면 --sslmode=disable을 추가하세요 (네트워크 경로가 안전하다는 것을 이미 알고 있는 경우 또는 사이트 간 VPN을 사용하는 경우). 공개 인터넷에서는 안전하지 않습니다!
- PostgreSQL 문서에서 각 sslmode에 대해 더 자세한 내용을 읽을 수 있습니다. 위의 지시사항은 수동 도청자 및 적극적인 “중간자 공격”에 대한 보호를 제공하는 것을 확실히하기 위해 신중하게 작성되었습니다.
- primary 데이터베이스에서 사용할 복제 슬롯 이름으로 --slot-name을 변경하세요. 스크립트는 해당 복제 슬롯을 자동으로 생성하려고 시도합니다.
- 이전 사이트를 Geo secondary 사이트로 재사용할 경우 명령줄에 --force를 추가해야 합니다.
- 프로덕션 머신이 아닌 경우 --skip-backup을 추가하여 백업 단계를 건너뛸 수 있습니다 (원하는 대로 확실한 경우).
- PgBouncer를 사용 중이라면 데이터베이스 호스트로 직접 대상을 지정해야 합니다.
- 프라이머리 사이트에 Patroni를 사용 중이라면 현재 리더 호스트로 대상을 지정해야 합니다.
- 로드 밸런서 프록시(예: HAProxy)를 사용하고 해당 프록시가 프라이머리를 위해 Patroni 리더를 타게팅하고 있다면, 대신 로드 밸런서 프록시를 타게팅해야 합니다.

변제 프로세스가 이제 완료되었습니다.

PgBouncer 지원 (선택 사항)

PgBouncer는 GitLab Geo와 함께 사용하여 PostgreSQL 연결을 풀링하는 데 사용될 수 있으며, 단일 인스턴스 설치에서도 성능을 향상시킬 수 있습니다.

Geo primary 사이트를 지원하는 노드 클러스터와 Geo secondary 사이트를 지원하는 두 개의 노드 클러스터가 있는 고가용성 구성에서 GitLab을 사용하는 경우 PgBouncer를 사용해야 합니다. 주 데이터베이스와 추적 데이터베이스를 위해 두 개의 PgBouncer 노드가 필요합니다. 자세한 내용은 해당 문서를 참조하십시오.

복제 비밀번호 변경

PostgreSQL 스트리밍 복제를 사용할 때 Linux 패키지 설치로 관리되는 PostgreSQL 인스턴스에서 복제 사용자의 비밀번호를 변경하려면:

GitLab Geo primary 사이트에서:

복제 사용자의 기본값은 gitlab_replicator이지만, /etc/gitlab/gitlab.rb의 postgresql['sql_replication_user'] 설정에 사용자를 설정한 경우, 다음 지침을 해당 사용자에 맞게 적용하세요.

원하는 비밀번호의 MD5 해시를 생성하세요:

sudo gitlab-ctl pg-password-md5 gitlab_replicator
# 비밀번호 입력: <your_password_here>
# 비밀번호 확인: <your_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e

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

# `gitlab-ctl pg-password-md5 gitlab_replicator`로 생성된 해시로 채웁니다.
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'

파일을 저장하고 복제 사용자의 비밀번호를 PostgreSQL에서 변경하려면 GitLab을 다시 구성하세요:
```
sudo gitlab-ctl reconfigure
```
복제 비밀번호 변경이 적용되려면 PostgreSQL을 다시 시작하세요:
```
sudo gitlab-ctl restart postgresql
```

변경된 비밀번호가 모든 secondary 사이트에서 업데이트될 때까지, 두 번째들의 PostgreSQL 로그에 다음 오류 메시지가 표시됩니다:

FATAL:  could not connect to the primary server: FATAL:  password authentication failed for user "gitlab_replicator"

GitLab Geo secondary 사이트에서:

구성 관점에서 첫 번째 단계는 필요하지 않습니다. 왜냐하면 secondary 사이트에서 해시화된 'sql_replication_password'이 사용되지 않기 때문입니다. 그러나 secondary 사이트를 GitLab Geo primary로 승격해야 하는 경우를 위해 secondary 사이트 구성에서 'sql_replication_password'를 일치시키도록 합니다.
/etc/gitlab/gitlab.rb를 편집하세요:
```
# Geo primary에서 `gitlab-ctl pg-password-md5 gitlab_replicator`로 생성된 해시로 채웁니다.
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
```
초기 복제 설정 중, gitlab-ctl replicate-geo-database 명령은 복제 사용자 계정의 평문 비밀번호를 두 위치에 기록합니다:
- gitlab-geo.conf: 기본적으로 /var/opt/gitlab/postgresql/data/gitlab-geo.conf에 작성되며, PostgreSQL 복제 프로세스에서 사용됩니다.
- .pgpass: 기본적으로 /var/opt/gitlab/postgresql/.pgpass에 위치하며, gitlab-psql 사용자에서 사용됩니다.
이 두 파일의 평문 비밀번호를 업데이트하고 PostgreSQL을 다시 시작하세요:
```
sudo gitlab-ctl restart postgresql
```

Multi-node database replication

GitLab 14.0에서, Patroni가 고가용성 PostgreSQL 솔루션으로서 repmgr을 대체했습니다.

참고: 아직 repmgr에서 Patroni로 마이그레이션하지 않은 경우, 권장드립니다.

Repmgr에서 Patroni로 마이그레이션

마이그레이션 전에 primary과 secondary 사이트 간의 복제 지연이 없는지 확인하고, 복제가 일시 중지되어 있는지 확인하세요. GitLab 13.2 이상에서는 Geo secondary 데이터베이스 노드에서 gitlab-ctl geo-replication-pause 및 gitlab-ctl geo-replication-resume로 복제를 일시 중지 및 재개할 수 있습니다.
repmgr에서 Patroni로 마이그레이션하는 방법을 참조하세요. 각 primary 사이트 데이터베이스 노드에서 Patroni를 구성할 때, gitlab.rb에 patroni['replication_slots'] = { '<slot_name>' => 'physical' }을 추가하여 secondary 사이트의 복제 슬롯 이름을 영구적인 것으로 인식하고 재시작 시에 삭제되지 않도록 합니다.
마이그레이션 전 secondary 사이트로의 데이터베이스 복제가 일시 중지되었으면, Patroni가 primary 사이트에서 작동하는 것을 확인한 후 복제를 재개하세요.

단일 PostgreSQL 노드를 Patroni로 마이그레이션하기

Patroni가 도입되기 이전에, Geo는 secondary 사이트의 Linux 패키지 설치를 위한 HA(High Availability) 설정을 지원하지 않았습니다.

Patroni를 사용하면, 해당 지원이 가능해졌습니다. 기존의 PostgreSQL을 Patroni로 마이그레이션하려면:

secondary에서 Consul 클러스터가 primary에서 설정하는 것과 유사하게 구성되어 있는지 확인하세요.
영구적인 복제 슬롯을 구성하세요.
내부 로드 밸런서를 구성하세요.
PgBouncer 노드를 구성하세요.
단일 노드 기계에 Standby Cluster를 구성하세요.

이렇게 함으로써, 단일 노드로 _Standby Cluster_를 얻을 수 있습니다. 이를 통해 위와 같은 지침에 따라 추가적인 Patroni 노드를 추가할 수 있습니다.

Patroni 지원

Patroni는 Geo를 위한 공식 복제 관리 솔루션입니다. Patroni를 사용하여 기본 및 보조 Geo 사이트에 고가용성 클러스터를 구축할 수 있습니다. 보조 사이트에 Patroni를 사용하는 것은 선택 사항이며 각 Geo 사이트에 동일한 수의 노드를 사용할 필요는 없습니다.

기본 사이트에 Patroni를 설정하는 방법은 관련 문서를 참조하십시오.

Geo 보조 사이트를 위한 Patroni 클러스터 구성

Geo 보조 사이트에서, 주 PostgreSQL 데이터베이스는 기본 사이트의 PostgreSQL 데이터베이스의 읽기 전용 복제본입니다.

Geo 기본 사이트에서 repmgr을 사용 중이라면, repmgr에서 Patroni로 마이그레이션하는 방법은 이 지침을 참조하십시오.

생산 준비 및 안전한 설정에는 적어도 다음이 필요합니다:

3개의 Consul 노드 (기본 및 보조 사이트)
2개의 Patroni 노드 (기본 및 보조 사이트)
1개의 PgBouncer 노드 (기본 및 보조 사이트)
1개의 내부 로드 밸런서 (기본 사이트 전용)

내부 로드 밸런서는 보조 사이트에서 계층적 복제를 활성화하기 위해 새 리더가 선택되는 경우 Patroni 클러스터의 리더에 연결하기 위한 단일 엔드포인트를 제공합니다.

패스워드 자격 증명 및 기타 데이터베이스 최상의 관행을 사용해야 합니다.

단계 1. 기본 사이트에서 Patroni 영구적 복제 슬롯 구성

보조 사이트에서 Patroni를 사용하여 데이터베이스 복제를 설정하려면, 기본 사이트의 Patroni 클러스터에 _영구적 복제 슬롯_을 구성하고 패스워드 인증을 사용해야 합니다.

기본 사이트의 각 Patroni 인스턴스를 실행하는 각 노드에서 Patroni 리더 인스턴스부터 다음을 수행합니다:

Patroni 인스턴스로 SSH를 통해 루트 사용자로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다:

roles(['patroni_role'])

consul['services'] = %w(postgresql)
consul['configuration'] = {
  retry_join: %w[CONSUL_PRIMARY1_IP CONSUL_PRIMARY2_IP CONSUL_PRIMARY3_IP]
}

# 각 보조마다 고유한 이름을 사용하여 각 보조에 대해 하나의 항목이 필요합니다:
#
# 구성 구문은 다음과 같습니다: 'unique_slotname' => { 'type' => 'physical' },
# 논리 복제 유형에 대한 영구 복제 슬롯 설정은 지원하지 않습니다
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}

patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # patroni/reserved 슬롯의 양의 두 배 사용 (3 patroni + 1 Geo 보조용 예약 슬롯).
patroni['postgresql']['max_replication_slots'] = 8 # patroni/reserved 슬롯의 양의 두 배 사용 (3 patroni + 1 Geo 보조용 예약 슬롯).
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'

# 모든 patroni 노드를 allowlist에 추가합니다
patroni['allowlist'] = %w[
  127.0.0.1/32
  PATRONI_PRIMARY1_IP/32 PATRONI_PRIMARY2_IP/32 PATRONI_PRIMARY3_IP/32
  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32
]

# 모든 보조 인스턴스를 모두 Standby 리더가 될 수 있으므로 나열합니다
postgresql['md5_auth_cidr_addresses'] = %w[
  PATRONI_PRIMARY1_IP/32 PATRONI_PRIMARY2_IP/32 PATRONI_PRIMARY3_IP/32 PATRONI_PRIMARY_PGBOUNCER/32
  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32 PATRONI_SECONDARY_PGBOUNCER/32
]

postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
postgresql['sql_replication_password'] = 'POSTGRESQL_REPLICATION_PASSWORD_HASH'
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
postgresql['listen_address'] = '0.0.0.0' # 여기에 공개 또는 VPC 주소를 사용할 수 있습니다

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

단계 2. 주 사이트에서 내부 로드 밸런서 구성

기본 사이트에서 새 리더가 선출될 때마다 보조 리더를 다시 구성하지 않고 두 번째 사이트의 Standby Leader를 설정하는 것을 피하려면 TCP 내부 로드 밸런서를 설정해야 합니다. 이 로드 밸런서는 Patroni 클러스터의 리더에 연결하기 위한 단일 엔드포인트를 제공합니다.

Linux 패키지에는 로드 밸런서가 포함되어 있지 않습니다. HAProxy로 다음과 같이 수행할 수 있습니다.

다음 IP 및 이름은 예시로 사용됩니다:

10.6.0.21: Patroni 1 (patroni1.internal)
10.6.0.22: Patroni 2 (patroni2.internal)
10.6.0.23: Patroni 3 (patroni3.internal)

global
    log /dev/log local0
    log localhost local1 notice
    log stdout format raw local0

defaults
    log global
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions

frontend internal-postgresql-tcp-in
    bind *:5432
    mode tcp
    option tcplog

    default_backend postgresql

backend postgresql
    option httpchk
    http-check expect status 200

    server patroni1.internal 10.6.0.21:5432 maxconn 100 check port 8008
    server patroni2.internal 10.6.0.22:5432 maxconn 100 check port 8008
    server patroni3.internal 10.6.0.23:5432 maxconn 100 check port 8008

더 많은 지침이 필요한 경우, 원하는 로드 밸런서에 대한 문서를 참조하세요.

단계 3. 보조 사이트에서 PgBouncer 노드 구성

생산 준비 및 고가용성 구성에는 최소 세 개의 Consul 노드 및 최소한 하나의 PgBouncer 노드가 필요합니다. 그러나 데이터베이스 노드 당 하나의 PgBouncer 노드를 가지는 것이 권장됩니다. 여러 개의 PgBouncer 서비스 노드가 있는 경우 내부 로드 밸런서 (TCP)가 필요합니다. 내부 로드 밸런서는 PgBouncer 클러스터에 연결하기 위한 단일 엔드포인트를 제공합니다. 더 많은 정보는 해당 문서를 참조하세요.

보조 사이트의 각 노드에서 PgBouncer 인스턴스를 실행하는 경우:

PgBouncer 노드로 SSH하여 루트로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb 파일을 편집하고 다음을 추가합니다:

# Pgbouncer 및 Consul 에이전트 외의 모든 컴포넌트를 비활성화합니다
roles(['pgbouncer_role'])

# PgBouncer 구성
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
'gitlab-consul': {
   # 다음으로 생성: `gitlab-ctl pg-password-md5 gitlab-consul`
   password: 'GITLAB_CONSUL_PASSWORD_HASH'
 },
  'pgbouncer': {
    # 다음으로 생성: `gitlab-ctl pg-password-md5 pgbouncer`
    password: 'PGBOUNCER_PASSWORD_HASH'
  }
}

# Consul 구성
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
  retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
}
consul['monitoring_service_discovery'] =  true

변경 사항이 적용되도록 GitLab을 다시 구성합니다:
```
gitlab-ctl reconfigure
```
.pgpass 파일을 작성하여 Consul이 PgBouncer를 다시로드할 수 있도록 합니다. 묻힐 때 PLAIN_TEXT_PGBOUNCER_PASSWORD를 두 번 입력합니다:
```
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
```
PgBouncer 서비스를 다시로드합니다:
```
gitlab-ctl hup pgbouncer
```

단계 4. 보조 사이트에서 대기 클러스터 구성

참고: 보조 사이트의 단일 PostgreSQL 인스턴스를 Patroni 클러스터로 변환하는 경우, 먼저 PostgreSQL 인스턴스에서 시작해야 합니다. 이는 Patroni Standby Leader 인스턴스가 되며, 필요한 경우 다른 레플리카로 전환할 수 있게 될 것입니다.

보조 사이트의 각 Patroni 인스턴스를 실행하는 노드마다:

Patroni 노드로 SSH하여 루트로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb 파일을 편집하고 다음을 추가합니다:

roles(['consul_role', 'patroni_role'])

consul['enable'] = true
consul['configuration'] = {
  retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
}
consul['services'] = %w(postgresql)

postgresql['md5_auth_cidr_addresses'] = [
  'PATRONI_SECONDARY1_IP/32', 'PATRONI_SECONDARY2_IP/32', 'PATRONI_SECONDARY3_IP/32', 'PATRONI_SECONDARY_PGBOUNCER/32',
  # 설명서에 따라 데이터베이스에 액세스해야 하는 다른 인스턴스
]


# patroni 노드를 허용 목록에 추가합니다
patroni['allowlist'] = %w[
  127.0.0.1/32
  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32
]

patroni['standby_cluster']['enable'] = true
patroni['standby_cluster']['host'] = 'INTERNAL_LOAD_BALANCER_PRIMARY_IP'
patroni['standby_cluster']['port'] = INTERNAL_LOAD_BALANCER_PRIMARY_PORT
patroni['standby_cluster']['primary_slot_name'] = 'geo_secondary' # 또는 이전에 설정한 고유한 복제 슬롯 이름
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'
patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 5 # 하나의 레플리카당 세 개 이상, 추가 레플리카당 두 개씩 필요
patroni['postgresql']['max_replication_slots'] = 5 # 하나의 레플리카당 세 개 이상, 추가 레플리카당 두 개씩 필요

postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
postgresql['sql_replication_password'] = 'POSTGRESQL_REPLICATION_PASSWORD_HASH'
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
postgresql['listen_address'] = '0.0.0.0' # 여기에 공용 또는 VPC 주소를 사용할 수 있습니다

gitlab_rails['db_password'] = 'POSTGRESQL_PASSWORD'
gitlab_rails['enable'] = true
gitlab_rails['auto_migrate'] = false

patroni['standby_cluster']['host']와 patroni['standby_cluster']['port']를 구성할 때: - INTERNAL_LOAD_BALANCER_PRIMARY_IP은 기본 내부 로드 밸런서 IP를 가리켜야 합니다. - INTERNAL_LOAD_BALANCER_PRIMARY_PORT은 [기본 Patroni 클러스터 리더에 대해 구성된] (#step-2-configure-the-internal-load-balancer-on-the-primary-site) 프론트 엔드 포트를 가리켜야 합니다. PgBouncer 프론트 엔드 포트를 사용하면 안 됩니다.

변경 사항이 적용되도록 GitLab을 다시 구성합니다. 이 단계에서는 PostgreSQL 사용자 및 설정을 부트스트랩해야 합니다.
- 이것이 Patroni의 초기 설치인 경우:
```
gitlab-ctl reconfigure
```
- 이전에 작동했던 Patroni 클러스터가 있는 사이트에서 대기 중인 Patroni 클러스터를 구성하는 경우:
  1. Patroni가 관리하는 모든 노드에서 Patroni를 중단합니다. 이는 cascade 레플리카를 포함합니다:
    gitlab-ctl stop patroni
  2. 대기 중인 클러스터를 다시 생성하기 위해 리더 Patroni 노드에서 다음을 실행합니다:
    rm -rf /var/opt/gitlab/postgresql/data /opt/gitlab/embedded/bin/patronictl -c /var/opt/gitlab/patroni/patroni.yaml remove postgresql-ha gitlab-ctl reconfigure gitlab-ctl start patroni

Patroni를 사용하여 단일 추적 데이터베이스 노드 마이그레이션

Patroni가 도입되기 전에 Geo는 보조 사이트에서 HA(고가용성) 설치용 리눅스 패키지 설치를 지원하지 않았습니다.

Patroni를 사용하면 이제 HA 설치를 지원할 수 있습니다. 그러나 Patroni의 일부 제한 사항으로 인해 동일한 머신에서 두 개의 다른 클러스터를 관리할 수 없습니다. 위의 지침을 따라 새로운 추적 데이터베이스를 위해 Patroni 클러스터를 설정해야 합니다.

추적 PostgreSQL 데이터베이스를 위한 Patroni 클러스터 구성

보조 Geo 사이트는 복제 상태를 추적하고 잠재적인 복제 문제로부터 자동으로 복구하기 위해 별도의 PostgreSQL 설치를 사용합니다.

Geo 추적 데이터베이스를 단일 노드에서 실행하려는 경우 지오 보조 사이트에서 추적 데이터베이스 구성을 참조하세요.

리눅스 패키지는 Geo 추적 데이터베이스를 고가용성 구성으로 실행하는 것을 지원하지 않습니다. 특히, 장애 조치(failover)가 제대로 작동하지 않습니다. 기능 요청 문제를 참조하세요.

Geo 추적 데이터베이스를 고가용성 구성으로 실행하려면 보조 사이트를 클라우드 관리 데이터베이스나 GitLab 리눅스 패키지로 관리되지 않는 수동으로 구성된 Patroni 클러스터와 연결할 수 있습니다. 외부 PostgreSQL 인스턴스와 함께 Geo를 따르세요.

문제 해결

문제 해결 문서를 읽어보세요.

지오프레미엄 데이터베이스 복제

단일 인스턴스 데이터베이스 복제

PostgreSQL 복제

단계 1. 주요 사이트 구성

단계 2. 보조 서버 구성

단계 3. 복제 프로세스 시작

PgBouncer 지원 (선택 사항)

복제 비밀번호 변경

Multi-node database replication

Repmgr에서 Patroni로 마이그레이션

단일 PostgreSQL 노드를 Patroni로 마이그레이션하기

Patroni 지원

Geo 보조 사이트를 위한 Patroni 클러스터 구성

단계 1. 기본 사이트에서 Patroni 영구적 복제 슬롯 구성

단계 2. 주 사이트에서 내부 로드 밸런서 구성

단계 3. 보조 사이트에서 PgBouncer 노드 구성

단계 4. 보조 사이트에서 대기 클러스터 구성

Patroni를 사용하여 단일 추적 데이터베이스 노드 마이그레이션

추적 PostgreSQL 데이터베이스를 위한 Patroni 클러스터 구성

문제 해결

도움말

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

도움받기