InfoGrab Docs

Geo 데이터베이스 복제

요약

이 문서에서는 기본 GitLab 데이터베이스를 보조 사이트의 데이터베이스에 복제하는 데 필요한 최소한의 단계를 설명합니다. GitLab 설치 시 외부 PostgreSQL 인스턴스(Linux 패키지 설치로 관리되지 않는)를 사용하는 경우, 역할이 필요한 모든 구성 단계를 수행할 수 없습니다.

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

Note

GitLab 설치 시 외부 PostgreSQL 인스턴스(Linux 패키지 설치로 관리되지 않는)를 사용하는 경우, 역할이 필요한 모든 구성 단계를 수행할 수 없습니다. 이 경우 외부 PostgreSQL 인스턴스와 Geo 프로세스를 대신 사용하세요.

보조 사이트가 기본 사이트와 동일한 버전의 GitLab Enterprise Edition을 실행하고 있는지 확인하세요. 기본 사이트에 Premium 또는 Ultimate 구독 라이선스를 추가했는지 확인하세요.

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

Note

설정 프로세스의 각 단계는 문서에 나와 있는 순서대로 완료해야 합니다. 그렇지 않은 경우 진행하기 전에 이전의 모든 단계를 완료하세요.

데이터베이스 비밀번호 일관성 요구 사항#

각 데이터베이스 관련 비밀번호 유형은 모든 Geo 사이트(기본 및 보조)에서 동일한 값을 가져야 합니다. 여기에는 다음이 포함됩니다:

  • postgresql['sql_replication_password'] (복제 사용자 비밀번호, MD5)
  • postgresql['sql_user_password'] (GitLab 데이터베이스 사용자 비밀번호, MD5)
  • gitlab_rails['db_password'] (GitLab 데이터베이스 사용자 비밀번호, 일반 텍스트)
  • patroni['replication_password'] (Patroni 설정의 경우, 일반 텍스트)
  • patroni['password'] (Patroni API 인증용, 일반 텍스트)
  • postgresql['pgbouncer_user_password'] (PgBouncer 사용 시, MD5)

예를 들어, 기본 사이트에 구성된 patroni['password'] 값은 모든 보조 사이트의 patroni['password'] 값과 동일해야 합니다.

이러한 비밀번호는 기본 사이트와 보조 사이트 간의 데이터베이스 인증 및 복제에 사용됩니다. 비밀번호가 다르면 복제 실패가 발생하고 Geo가 올바르게 작동하지 않습니다.

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

단일 인스턴스 데이터베이스 복제는 설정이 더 쉽고 클러스터 방식과 동일한 Geo 기능을 제공합니다. 단일 머신에서 실행하거나 향후 클러스터 설치를 위해 Geo를 평가하는 설정에 유용합니다.

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

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

PostgreSQL 복제#

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

기본 사이트가 보조 사이트를 복구하는 데 필요한 모든 데이터를 보유하도록 PostgreSQL의 복제 슬롯을 사용해야 합니다. 자세한 내용은 아래를 참조하세요.

다음 가이드는 다음과 같이 가정합니다:

  • Linux 패키지를 사용하고 있으며(따라서 PostgreSQL 12 이상 사용), pg_basebackup 도구가 포함되어 있습니다.
  • 기본 사이트가 이미 설정되어 있으며(복제 원본인 GitLab 서버), Linux 패키지 설치에서 관리하는 PostgreSQL(또는 동등한 버전)을 실행하고 있으며, 모든 사이트에서 동일한 PostgreSQL 버전, OS, GitLab으로 새 보조 사이트가 설정되어 있습니다.
Warning

Geo는 스트리밍 복제와 함께 작동합니다. 논리적 복제는 지원되지 않지만, 에픽 18022에서 이 동작 변경을 제안하고 있습니다.

1단계. 기본 사이트 구성#

  1. GitLab 기본 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

  3. /etc/gitlab/gitlab.rb를 편집하고 사이트에 고유한 이름을 추가합니다:

    ##
## Geo 사이트의 고유 식별자입니다. 다음을 참조하세요:
## https://docs.gitlab.com/administration/geo_sites/#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

  4. 변경 사항이 적용되도록 기본 사이트를 재구성합니다:

    gitlab-ctl reconfigure

  5. 아래 명령을 실행하여 사이트를 기본 사이트로 정의합니다:

    gitlab-ctl set-geo-primary-node

    이 명령은 /etc/gitlab/gitlab.rb에 정의된 external_url을 사용합니다.

  6. gitlab 데이터베이스 사용자의 비밀번호를 정의합니다:

    원하는 비밀번호의 MD5 해시를 생성합니다:

    gitlab-ctl pg-password-md5 gitlab
# Enter password: <your_db_password_here>
# Confirm password: <your_db_password_here>
# fca0b89a972d69f00eb3ec98a5838484

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

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

# Puma 또는 Sidekiq를 실행하는 모든 노드에 아래와 같이
# 데이터베이스 비밀번호가 지정되어 있어야 합니다. 고가용성 설정이 있는 경우
# 이 내용은 모든 애플리케이션 노드에 있어야 합니다.
gitlab_rails['db_password'] = '<your_db_password_here>'

  7. 데이터베이스 복제 사용자의 비밀번호를 정의합니다.

    /etc/gitlab/gitlab.rb의 postgresql['sql_replication_user'] 설정에 정의된 사용자 이름을 사용합니다. 기본값은 gitlab_replicator입니다. 사용자 이름을 다른 이름으로 변경한 경우, 아래 지침을 해당 사용자에 맞게 조정하세요.

    원하는 비밀번호의 MD5 해시를 생성합니다:

    gitlab-ctl pg-password-md5 gitlab_replicator
# Enter password: <your_replication_password_here>
# Confirm password: <your_replication_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e

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

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

    Linux 패키지 설치에서 관리하지 않는 외부 데이터베이스를 사용하는 경우, gitlab_replicator 사용자를 만들고 해당 사용자의 비밀번호를 수동으로 정의해야 합니다:

    --- 새 사용자 'replicator' 만들기
CREATE USER gitlab_replicator;

--- 비밀번호 설정/변경 및 복제 권한 부여
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

  8. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_primary_role로 설정합니다(자세한 내용은 Geo 역할 참조):

    ## Geo 기본 역할
roles(['geo_primary_role'])

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

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

    [!note] 외부 PostgreSQL 인스턴스의 경우, 추가 지침을 참조하세요.

    클라우드 공급자를 사용하는 경우, 클라우드 공급자의 관리 콘솔에서 각 Geo 사이트의 주소를 조회할 수 있습니다.

    Geo 사이트의 주소를 조회하려면 Geo 사이트에 SSH로 접속하고 다음을 실행합니다:

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

##
## 공용 주소
##
echo "External address: $(curl --silent "ipinfo.io/ip")"

    대부분의 경우 다음 주소를 GitLab Geo 구성에 사용합니다:

    구성 주소
    postgresql['listen_address'] 기본 사이트의 공용 또는 VPC 사설 주소.
    postgresql['md5_auth_cidr_addresses'] 기본 및 보조 사이트의 공용 또는 VPC 사설 주소.

    가상 사설 클라우드(VPC)를 제공하는 Google Cloud Platform, SoftLayer 또는 기타 공급업체를 사용하는 경우, postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에는 기본 및 보조 사이트의 "사설" 또는 "내부" 주소를 사용하는 것이 좋습니다.

    listen_address 옵션은 지정된 주소에 해당하는 인터페이스에서의 네트워크 연결을 허용하도록 PostgreSQL을 엽니다. 자세한 내용은 PostgreSQL 문서를 참조하세요.

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

    네트워크 구성에 따라 제안된 주소가 올바르지 않을 수 있습니다. 기본 및 보조 사이트가 로컬 영역 네트워크 또는 Amazon VPC나 Google VPC와 같이 가용 영역을 연결하는 가상 네트워크를 통해 연결하는 경우, postgresql['md5_auth_cidr_addresses']에는 보조 사이트의 사설 주소를 사용해야 합니다.

    /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. IP 주소를 네트워크 구성에 맞는 주소로 교체하세요:

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

##
# 기본 및 보조 IP에서 PostgreSQL 클라이언트 인증을 허용합니다. 이 IP는
# CIDR 형식의 공용 또는 VPC 주소일 수 있습니다(예: ['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 노드가 두 개 이상인 경우 이 값을 Geo 보조 노드 수로 설정합니다
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

  10. PostgreSQL이 재시작되어 사설 주소에서 수신할 때까지 자동 데이터베이스 마이그레이션을 일시적으로 비활성화합니다. /etc/gitlab/gitlab.rb를 편집하고 구성을 false로 변경합니다:

    ## 자동 데이터베이스 마이그레이션 비활성화
gitlab_rails['auto_migrate'] = false

  11. 선택 사항. 다른 보조 사이트를 추가하려면 관련 설정은 다음과 같습니다:

    postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32', '<another_secondary_site_ip>/32']

    데이터베이스 복제 요구 사항에 맞게 wal_keep_segments 및 max_wal_senders도 편집할 수 있습니다. 자세한 내용은 PostgreSQL - 복제 문서를 참조하세요.

  12. 파일을 저장하고 데이터베이스 수신 변경 사항 및 복제 슬롯 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

    변경 사항이 적용되도록 PostgreSQL을 재시작합니다:

    gitlab-ctl restart postgresql

  13. PostgreSQL이 재시작되어 사설 주소에서 수신하고 있으므로 이제 마이그레이션을 다시 활성화합니다.

    /etc/gitlab/gitlab.rb를 편집하고 구성을 true로 변경합니다:

    gitlab_rails['auto_migrate'] = true

    파일을 저장하고 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  14. PostgreSQL 서버가 원격 연결을 허용하도록 설정되었으므로, netstat -plnt | grep 5432를 실행하여 PostgreSQL이 기본 사이트의 사설 주소에서 포트 5432에서 수신하고 있는지 확인합니다.

  15. GitLab 재구성 시 인증서가 자동으로 생성되었습니다. 이 인증서는 도청자로부터 PostgreSQL 트래픽을 자동으로 보호하는 데 사용됩니다. 능동적("중간자 공격") 공격자로부터 보호하기 위해, 보조 사이트에는 인증서에 서명한 CA의 복사본이 필요합니다. 이 자체 서명 인증서의 경우, 다음 명령을 실행하여 기본 사이트에서 PostgreSQL server.crt 파일의 복사본을 만드세요:

    cat ~gitlab-psql/data/server.crt

    출력을 클립보드 또는 로컬 파일에 복사합니다. 보조 사이트를 설정할 때 필요합니다! 인증서는 민감한 데이터가 아닙니다.

    그러나 이 인증서는 일반적인 PostgreSQL Common Name으로 만들어집니다. 따라서 데이터베이스를 복제할 때 verify-ca 모드를 사용해야 합니다. 그렇지 않으면 호스트 이름 불일치로 오류가 발생합니다.

  16. 선택 사항. 생성된 인증서를 사용하는 대신 자체 SSL 인증서를 생성하고 PostgreSQL용 SSL 수동 구성을 합니다.

    SSL 인증서와 키가 최소한 필요합니다. Database SSL 문서에 따라 postgresql['ssl_cert_file'] 및 postgresql['ssl_key_file'] 값을 전체 경로로 설정합니다.

    이렇게 하면 데이터베이스를 복제할 때 verify-full SSL 모드를 사용하여 인증서 CN/SAN에서 전체 호스트 이름을 검증하는 추가 이점을 얻을 수 있습니다.

    이제부터 자동으로 생성된 자체 서명 인증서 대신 이 인증서(postgresql['ssl_cert_file']에도 설정한)를 사용할 수 있습니다. CN이 일치하면 복제 오류 없이 verify-full을 사용할 수 있습니다.

    기본 데이터베이스에서 /etc/gitlab/gitlab.rb를 열고 postgresql['ssl_ca_file'](CA 인증서)을 검색합니다. 그 값을 나중에 server.crt에 붙여넣을 클립보드에 복사합니다.

2단계. 보조 서버 구성#

  1. GitLab 보조 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

  3. 애플리케이션 서버 및 Sidekiq를 중지합니다:

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq

    [!note] 이 단계는 사이트가 완전히 구성되기 전에 어떤 작업도 실행하지 않도록 하기 위해 중요합니다.

  4. 기본 사이트의 PostgreSQL 서버에 대한 TCP 연결 확인:

    gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]

    [!note] 이 단계가 실패하면 잘못된 IP 주소를 사용하거나 방화벽이 사이트 접근을 방지하고 있을 수 있습니다. 공용 주소와 사설 주소의 차이에 주의하면서 IP 주소를 확인하세요. 방화벽이 있는 경우, 보조 사이트가 포트 5432에서 기본 사이트에 연결할 수 있는지 확인합니다.

  5. 기본 사이트 설정의 마지막 단계에서 얻은 콘텐츠로 보조 사이트에 server.crt 파일을 만듭니다:

    editor server.crt

  6. 보조 사이트에서 PostgreSQL TLS 검증을 설정합니다:

    server.crt 파일을 설치합니다:

    install \
   -D \
   -o gitlab-psql \
   -g gitlab-psql \
   -m 0400 \
   -T server.crt ~gitlab-psql/.postgresql/root.crt

    이제 PostgreSQL은 TLS 연결을 검증할 때 정확한 인증서만 인식합니다. 인증서는 개인 키에 접근할 수 있는 사람만 복제할 수 있으며, 이 키는 기본 사이트에만 있습니다.

  7. gitlab-psql 사용자가 기본 사이트의 데이터베이스에 연결할 수 있는지 테스트합니다 (Linux 패키지 설치에서 기본 데이터베이스 이름은 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>

    [!note] 수동으로 생성된 인증서를 사용하고 전체 호스트 이름 검증의 이점을 얻기 위해 sslmode=verify-full을 사용하려면, 명령 실행 시 verify-ca를 verify-full로 교체하세요.

    메시지가 표시되면 첫 번째 단계에서 gitlab_replicator 사용자에 대해 설정한 일반 텍스트 비밀번호를 입력합니다. 모든 것이 올바르게 작동하면 기본 사이트의 데이터베이스 목록이 표시됩니다.

    여기에서 연결 실패는 TLS 구성이 잘못되었음을 나타냅니다. 기본 사이트의 ~gitlab-psql/data/server.crt 내용이 보조 사이트의 ~gitlab-psql/.postgresql/root.crt 내용과 일치하는지 확인합니다.

  8. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_secondary_role로 설정합니다(자세한 내용은 Geo 역할 참조):

    ##
## Geo 보조 역할
## - Geo를 활성화하기 위해 종속 플래그를 자동으로 구성합니다
##
roles(['geo_secondary_role'])

  9. PostgreSQL을 구성합니다:

    이 단계는 기본 인스턴스를 구성한 방법과 유사합니다. 단일 노드를 사용하더라도 이를 활성화해야 합니다.

    [!warning] 각 비밀번호 유형은 모든 Geo 사이트에서 일치하는 값을 가져야 합니다.

    /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. IP 주소를 네트워크 구성에 맞는 주소로 교체하세요:

    ##
## 보조 주소
## - '<secondary_site_ip>'를 Geo 보조 사이트의 공용 또는 VPC 주소로 교체합니다
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']

##
## 데이터베이스 자격 증명 비밀번호(이전에 기본 사이트에서 정의됨)
## - 기본 사이트에서 정의된 것과 동일한 값을 여기에 복제합니다
##
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
gitlab_rails['db_password'] = '<your_db_password_here>'

    외부 PostgreSQL 인스턴스의 경우, 추가 지침을 참조하세요. 이전 기본 사이트를 보조 사이트로 다시 온라인으로 전환하는 경우, roles(['geo_primary_role']) 또는 geo_primary_role['enable'] = true도 제거해야 합니다.

  10. 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  11. IP 변경 사항이 적용되도록 PostgreSQL을 재시작합니다:

    gitlab-ctl restart postgresql

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

아래는 보조 사이트의 데이터베이스를 기본 사이트의 데이터베이스에 연결하는 스크립트입니다. 이 스크립트는 데이터베이스를 복제하고 스트리밍 복제에 필요한 파일을 만듭니다.

사용된 디렉토리는 Linux 패키지 설치에서 설정된 기본값입니다. 기본값을 변경한 경우, 스크립트를 그에 맞게 구성하세요 (디렉토리 및 경로 교체).

Warning

pg_basebackup을 실행하기 전에 모든 PostgreSQL 데이터를 제거하므로 보조 사이트에서 실행해야 합니다.

  1. GitLab 보조 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 보조 사이트에서 복제 슬롯 이름으로 사용할 데이터베이스 친화적인 이름을 선택합니다. 예를 들어 도메인이 secondary.geo.example.com인 경우, 아래 명령에 표시된 것처럼 슬롯 이름으로 secondary_example을 사용합니다.

  3. 아래 명령을 실행하여 백업/복원을 시작하고 복제를 시작합니다

    [!warning] 각 Geo 보조 사이트에는 고유한 복제 슬롯 이름이 있어야 합니다. 두 보조 사이트 간에 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 중단됩니다.

    복제 슬롯 이름에는 소문자, 숫자 및 밑줄 문자만 포함할 수 있습니다.

    메시지가 표시되면 첫 번째 단계에서 gitlab_replicator 사용자에 대해 설정한 일반 텍스트 비밀번호를 입력합니다.

    gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca

    [!note] 사용자 지정 PostgreSQL 인증서를 생성한 경우, 추가 보안을 위해 인증서 CN/SAN의 전체 호스트 이름 검증의 이점을 얻으려면 --sslmode=verify-full을 사용해야 합니다(또는 sslmode 줄을 완전히 생략). 그렇지 않으면 자동으로 생성된 인증서로 verify-full을 사용하면 실패합니다. 일반적인 PostgreSQL CN이 이 명령의 --host 값과 일치하지 않기 때문입니다.

    이 명령은 추가 옵션도 사용합니다. --help를 사용하여 모두 나열할 수 있지만, 다음은 몇 가지 팁입니다:

    • 기본 사이트에 단일 노드가 있는 경우, 기본 노드 호스트를 --host 매개변수로 사용합니다.
    • 기본 사이트가 외부 PostgreSQL 데이터베이스를 사용하는 경우, --host 매개변수를 조정해야 합니다:
      • PgBouncer 설정의 경우, PgBouncer 주소가 아닌 실제 PostgreSQL 데이터베이스 호스트를 직접 대상으로 합니다.
      • Patroni 구성의 경우, 현재 Patroni 리더 호스트를 대상으로 합니다.
      • 로드 밸런서(예: HAProxy) 사용 시, 로드 밸런서가 항상 Patroni 리더로 라우팅하도록 구성된 경우 로드 밸런서를 대상으로 할 수 있습니다. 그렇지 않은 경우, 실제 데이터베이스 호스트를 대상으로 해야 합니다.
      • 전용 PostgreSQL 노드가 있는 설정의 경우, 전용 데이터베이스 호스트를 직접 대상으로 합니다.
    • 기본 데이터베이스에 사용할 복제 슬롯 이름으로 --slot-name을 변경합니다. 스크립트는 복제 슬롯이 존재하지 않으면 자동으로 생성을 시도합니다.
    • PostgreSQL이 비표준 포트에서 수신 중인 경우, --port=를 추가합니다.
    • 데이터베이스가 30분 이내에 전송되기에 너무 큰 경우, 타임아웃을 늘려야 합니다. 예를 들어 초기 복제가 1시간 미만 걸릴 것으로 예상되면 --backup-timeout=3600을 사용합니다.
    • --sslmode=disable을 전달하여 PostgreSQL TLS 인증을 완전히 건너뜁니다 (예: 네트워크 경로가 안전하거나 사이트 간 VPN을 사용하는 경우). 공용 인터넷을 통해 사용하는 것은 안전하지 않습니다!
    • 각 sslmode에 대한 자세한 내용은 PostgreSQL 문서에서 읽을 수 있습니다. 앞서 나열된 지침은 수동 도청자와 능동적 "중간자 공격" 공격자 모두로부터 보호를 보장하기 위해 신중하게 작성되었습니다.
    • 이전 사이트를 Geo 보조 사이트로 용도를 변경하는 경우, 명령줄에 --force를 추가해야 합니다.
    • 프로덕션 환경이 아닌 경우, --skip-backup을 추가하여 백업 단계를 비활성화할 수 있습니다(이것이 원하는 것임을 확실히 아는 경우).

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

Note

복제 프로세스는 기본 사이트의 데이터베이스에서 보조 사이트의 데이터베이스로 데이터만 복사합니다. 보조 사이트 구성을 완료하려면 기본 사이트에서 보조 사이트를 추가하세요.

PgBouncer 지원 (선택 사항)#

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

Geo 기본 사이트를 지원하는 노드 클러스터와 Geo 보조 사이트를 지원하는 두 개의 다른 노드 클러스터가 있는 고가용성 구성에서 GitLab을 사용하는 경우 PgBouncer를 사용해야 합니다. PgBouncer 노드가 두 개 필요합니다: 메인 데이터베이스용과 추적 데이터베이스용. 자세한 내용은 관련 문서를 참조하세요.

복제 비밀번호 변경#

Warning

복제 비밀번호를 변경할 때는 모든 Geo 사이트(기본 및 모든 보조)에서 동일한 비밀번호 값으로 업데이트해야 합니다. 비밀번호를 동기화하지 않으면 복제가 중단됩니다.

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

GitLab Geo 기본 사이트에서:

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

    원하는 비밀번호의 MD5 해시를 생성합니다:

    sudo gitlab-ctl pg-password-md5 gitlab_replicator
# Enter password: <your_replication_password_here>
# Confirm password: <your_replication_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e

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

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

  2. 파일을 저장하고 GitLab을 재구성하여 PostgreSQL의 복제 사용자 비밀번호를 변경합니다:

    sudo gitlab-ctl reconfigure

  3. 복제 비밀번호 변경 사항이 적용되도록 PostgreSQL을 재시작합니다:

    sudo gitlab-ctl restart postgresql

보조 사이트에서 비밀번호가 업데이트되기 전까지, 보조 사이트의 PostgreSQL 로그에 다음 오류 메시지가 보고됩니다:

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

모든 GitLab Geo 보조 사이트에서:

  1. 첫 번째 단계는 구성 관점에서 필요하지 않습니다. 해시된 'sql_replication_password'는 GitLab Geo 보조 사이트에서 사용되지 않기 때문입니다. 그러나 보조 사이트가 GitLab Geo 기본 사이트로 승격되어야 하는 경우에 대비하여, 보조 사이트 구성의 'sql_replication_password'가 기본 사이트와 일치하는지 확인하세요.

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

    # Geo 기본 사이트에서 `gitlab-ctl pg-password-md5 gitlab_replicator`로 생성한 해시로 채웁니다
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

  2. 초기 복제 설정 중에 gitlab-ctl replicate-geo-database 명령은 복제 사용자 계정의 일반 텍스트 비밀번호를 두 위치에 씁니다:

    • gitlab-geo.conf: PostgreSQL 복제 프로세스에서 사용되며, 기본적으로 /var/opt/gitlab/postgresql/data/gitlab-geo.conf의 PostgreSQL 데이터 디렉토리에 씁니다.
    • .pgpass: gitlab-psql 사용자가 사용하며, 기본적으로 /var/opt/gitlab/postgresql/.pgpass에 있습니다.

    이 두 파일에서 일반 텍스트 비밀번호를 업데이트하고, PostgreSQL을 재시작합니다:

    sudo gitlab-ctl restart postgresql

다중 노드 데이터베이스 복제#

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

Patroni 도입 이전에 Geo는 보조 사이트의 HA 설정을 위한 Linux 패키지 설치를 지원하지 않았습니다.

Patroni를 사용하면 이 지원이 이제 가능합니다. 기존 PostgreSQL을 Patroni로 마이그레이션하려면:

  1. 보조 사이트에 Consul 클러스터가 설정되어 있는지 확인합니다(기본 사이트에 설정한 것과 유사).
  2. 영구 복제 슬롯 구성.
  3. 내부 로드 밸런서 구성.
  4. PgBouncer 노드 구성
  5. 해당 단일 노드 머신에서 스탠바이 클러스터 구성.

결과적으로 단일 노드로 구성된 스탠바이 클러스터가 생깁니다. 이를 통해 앞서 나열된 동일한 지침에 따라 추가 Patroni 노드를 추가할 수 있습니다.

Patroni 지원#

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

기본 사이트에서 Patroni를 설정하는 방법에 대한 지침은 관련 문서를 참조하세요.

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

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

프로덕션 준비가 완료된 안전한 설정에는 최소한 다음이 필요합니다:

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

내부 로드 밸런서는 새 리더가 선출될 때마다 Patroni 클러스터의 리더에 연결하기 위한 단일 엔드포인트를 제공합니다. 로드 밸런서는 보조 사이트에서의 계단식 복제를 활성화하는 데 필요합니다.

비밀번호 자격 증명 및 기타 데이터베이스 모범 사례를 사용해야 합니다.

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

기본 데이터베이스에서 보조 노드의 Patroni 클러스터로 지속적인 데이터 복제를 보장하기 위해 기본 데이터베이스에 영구 복제 슬롯을 설정합니다.

보조 사이트에서 Patroni로 데이터베이스 복제를 설정하려면, 기본 사이트의 Patroni 클러스터에 영구 복제 슬롯을 구성하고 비밀번호 인증이 사용되도록 해야 합니다.

기본 사이트에서 Patroni 리더 인스턴스부터 시작하여 Patroni 인스턴스를 실행하는 각 노드에서:

  1. Patroni 인스턴스에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

  3. /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. 각 비밀번호 유형이 모든 Geo 사이트에서 일치하는 값을 가지는지 확인하세요.

    roles(['patroni_role'])

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

# 각 보조 사이트에 대해 PostgreSQL slot_name 제약 조건을 따르는 고유한 이름으로 하나의 항목이 필요합니다:
#
# 구성 구문: 'unique_slotname' => { 'type' => 'physical' },
# 논리적 복제 유형에 대한 영구 복제 슬롯 설정은 지원하지 않습니다
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}

patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # patroni/예약 슬롯 수의 두 배를 사용합니다 (Patroni 3개 + Geo 보조 사이트용 예약 슬롯 1개).
patroni['postgresql']['max_replication_slots'] = 8 # patroni/예약 슬롯 수의 두 배를 사용합니다 (Patroni 3개 + Geo 보조 사이트용 예약 슬롯 1개).
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'

# 모든 patroni 노드를 허용 목록에 추가합니다
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
]

# 모든 보조 인스턴스가 스탠바이 리더가 될 수 있으므로 모두 나열합니다
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 주소를 사용할 수 있습니다

  4. 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  1. 단일 노드 인스턴스에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

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

    postgresql['max_wal_senders'] = 2 # 보조 사이트당 2를 사용합니다 (초기 Patroni 복제를 위한 임시 슬롯 1개 + Geo 보조 사이트용 예약 슬롯 1개)
postgresql['max_replication_slots'] = 2 # 보조 사이트당 2를 사용합니다 (초기 Patroni 복제를 위한 임시 슬롯 1개 + Geo 보조 사이트용 예약 슬롯 1개)

  4. GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  5. 새 변경 사항이 적용되도록 PostgreSQL 서비스를 재시작합니다:

    gitlab-ctl restart postgresql

  6. 데이터베이스 콘솔을 시작합니다

    gitlab-psql

  7. 기본 사이트에서 영구 복제 슬롯을 구성합니다

    select pg_create_physical_replication_slot('geo_secondary')

  8. 선택 사항. 기본 사이트에는 PgBouncer가 없지만 보조 사이트에 있는 경우:

    기본 사이트에서 pgbouncer 사용자를 구성하고 Linux 패키지에 포함된 PgBouncer에 필요한 pg_shadow_lookup 함수를 추가합니다. 보조 서버의 PgBouncer는 여전히 보조 사이트의 PostgreSQL 노드에 연결할 수 있어야 합니다.

    --- 새 사용자 'pgbouncer' 만들기
CREATE USER pgbouncer;

--- 비밀번호 설정/변경 및 복제 권한 부여
ALTER USER pgbouncer WITH REPLICATION ENCRYPTED PASSWORD '<pgbouncer_password_from_secondary>';

CREATE OR REPLACE FUNCTION public.pg_shadow_lookup(in i_username text, out username text, out password text) RETURNS record AS $$
BEGIN
    SELECT usename, passwd FROM pg_catalog.pg_shadow
    WHERE usename = i_username INTO username, password;
    RETURN;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

REVOKE ALL ON FUNCTION public.pg_shadow_lookup(text) FROM public, pgbouncer;
GRANT EXECUTE ON FUNCTION public.pg_shadow_lookup(text) TO pgbouncer;
2단계. 기본 사이트에서 내부 로드 밸런서 구성#

기본 사이트에서 새 리더가 선출될 때마다 보조 사이트의 스탠바이 리더를 재구성하지 않으려면, 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
    mode tcp
    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 노드 구성#

프로덕션 준비가 완료된 고가용성 구성에는 최소 3개의 Consul 노드와 최소 1개의 PgBouncer 노드가 필요합니다. 그러나 데이터베이스 노드당 하나의 PgBouncer 노드를 두는 것이 좋습니다. PgBouncer 서비스 노드가 두 개 이상인 경우 내부 로드 밸런서(TCP)가 필요합니다. 내부 로드 밸런서는 PgBouncer 클러스터에 연결하기 위한 단일 엔드포인트를 제공합니다. 자세한 내용은 관련 문서를 참조하세요.

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

  1. PgBouncer 노드에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

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

  3. 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  4. Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 만듭니다. 요청 시 PLAIN_TEXT_PGBOUNCER_PASSWORD를 두 번 입력합니다:

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

  5. PgBouncer 서비스를 다시 로드합니다:

    gitlab-ctl hup pgbouncer
4단계. 보조 사이트에서 스탠바이 클러스터 구성#
Note

단일 PostgreSQL 인스턴스가 있는 보조 사이트를 Patroni 클러스터로 변환하는 경우, PostgreSQL 인스턴스에서 시작해야 합니다. 이 인스턴스가 Patroni 스탠바이 리더 인스턴스가 되고, 그런 다음 필요하면 다른 복제본으로 전환할 수 있습니다.

보조 사이트에서 Patroni 인스턴스를 실행하는 각 노드에서:

  1. Patroni 노드에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

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

    [!warning] 각 비밀번호 유형은 모든 Geo 사이트에서 일치하는 값을 가져야 합니다.

    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 # 복제본 하나에 최소 3개, 추가 복제본마다 2개씩 추가
patroni['postgresql']['max_replication_slots'] = 5 # 복제본 하나에 최소 3개, 추가 복제본마다 2개씩 추가

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-ctl geo-replication-pause`를 위해 GitLab Rails 구성이 필요합니다
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 클러스터 리더에 구성된 프론트엔드 포트를 가리켜야 합니다. PgBouncer 프론트엔드 포트를 사용하지 마세요.

  4. 변경 사항이 적용되도록 GitLab을 재구성합니다. 이 단계는 PostgreSQL 사용자 및 설정을 부트스트랩하는 데 필요합니다.

    • 새로운 Patroni 설치인 경우:

      gitlab-ctl reconfigure

    • 이전에 작동하는 Patroni 클러스터가 있던 사이트에서 Patroni 스탠바이 클러스터를 구성하는 경우:

      1. Patroni가 관리하는 모든 노드에서(계단식 복제본 포함) Patroni를 중지합니다:

        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

      3. 리더 Patroni 노드에서 Patroni를 시작하여 기본 데이터베이스에서 복제 프로세스를 시작합니다:

        gitlab-ctl start patroni

      4. Patroni 클러스터의 상태를 확인합니다:

        gitlab-ctl patroni members

        다음을 확인합니다:

        • 현재 Patroni 노드가 출력에 나타납니다.
        • 역할이 Standby Leader입니다. 역할이 처음에는 Replica로 표시될 수 있습니다.
        • 상태가 Running입니다. 상태가 처음에는 Creating replica로 표시될 수 있습니다.

        노드의 역할이 Standby Leader로 안정되고 상태가 Running이 될 때까지 기다립니다. 이 과정이 몇 분 정도 걸릴 수 있습니다.

      5. 리더 Patroni 노드가 Standby Leader이고 Running 상태이면, 스탠바이 클러스터의 다른 Patroni 노드에서 Patroni를 시작합니다:

        gitlab-ctl start patroni

        다른 Patroni 노드는 자동으로 새 스탠바이 클러스터에 복제본으로 참여하고 리더 Patroni 노드에서 복제를 시작합니다.

  5. 클러스터 상태를 확인합니다:

    gitlab-ctl patroni members

    모든 Patroni 노드가 Running 상태로 나열되어 있는지 확인합니다. Standby Leader 노드 하나와 여러 개의 Replica 노드가 있어야 합니다.

단일 추적 데이터베이스 노드를 Patroni로 마이그레이션#

Patroni 도입 이전에 Geo는 보조 사이트의 HA 설정을 위한 Linux 패키지 설치를 지원하지 않았습니다.

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

보조 노드는 새 추적 데이터베이스를 백필하며, 데이터 동기화가 필요하지 않습니다.

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

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

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

Linux 패키지는 고가용성 구성에서 Geo 추적 데이터베이스 실행을 지원하지 않습니다. 특히 장애 조치가 제대로 작동하지 않습니다. 기능 요청 이슈를 참조하세요.

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

트러블슈팅#

트러블슈팅 문서를 읽으세요.

Geo 데이터베이스 복제

Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

이 문서에서는 기본 GitLab 데이터베이스를 보조 사이트의 데이터베이스에 복제하는 데 필요한 최소한의 단계를 설명합니다. GitLab 설치 시 외부 PostgreSQL 인스턴스(Linux 패키지 설치로 관리되지 않는)를 사용하는 경우, 역할이 필요한 모든 구성 단계를 수행할 수 없습니다.

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

Note

GitLab 설치 시 외부 PostgreSQL 인스턴스(Linux 패키지 설치로 관리되지 않는)를 사용하는 경우, 역할이 필요한 모든 구성 단계를 수행할 수 없습니다. 이 경우 외부 PostgreSQL 인스턴스와 Geo 프로세스를 대신 사용하세요.

보조 사이트가 기본 사이트와 동일한 버전의 GitLab Enterprise Edition을 실행하고 있는지 확인하세요. 기본 사이트에 Premium 또는 Ultimate 구독 라이선스를 추가했는지 확인하세요.

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

Note

설정 프로세스의 각 단계는 문서에 나와 있는 순서대로 완료해야 합니다. 그렇지 않은 경우 진행하기 전에 이전의 모든 단계를 완료하세요.

데이터베이스 비밀번호 일관성 요구 사항#

각 데이터베이스 관련 비밀번호 유형은 모든 Geo 사이트(기본 및 보조)에서 동일한 값을 가져야 합니다. 여기에는 다음이 포함됩니다:

  • postgresql['sql_replication_password'] (복제 사용자 비밀번호, MD5)
  • postgresql['sql_user_password'] (GitLab 데이터베이스 사용자 비밀번호, MD5)
  • gitlab_rails['db_password'] (GitLab 데이터베이스 사용자 비밀번호, 일반 텍스트)
  • patroni['replication_password'] (Patroni 설정의 경우, 일반 텍스트)
  • patroni['password'] (Patroni API 인증용, 일반 텍스트)
  • postgresql['pgbouncer_user_password'] (PgBouncer 사용 시, MD5)

예를 들어, 기본 사이트에 구성된 patroni['password'] 값은 모든 보조 사이트의 patroni['password'] 값과 동일해야 합니다.

이러한 비밀번호는 기본 사이트와 보조 사이트 간의 데이터베이스 인증 및 복제에 사용됩니다. 비밀번호가 다르면 복제 실패가 발생하고 Geo가 올바르게 작동하지 않습니다.

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

단일 인스턴스 데이터베이스 복제는 설정이 더 쉽고 클러스터 방식과 동일한 Geo 기능을 제공합니다. 단일 머신에서 실행하거나 향후 클러스터 설치를 위해 Geo를 평가하는 설정에 유용합니다.

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

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

PostgreSQL 복제#

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

기본 사이트가 보조 사이트를 복구하는 데 필요한 모든 데이터를 보유하도록 PostgreSQL의 복제 슬롯을 사용해야 합니다. 자세한 내용은 아래를 참조하세요.

다음 가이드는 다음과 같이 가정합니다:

  • Linux 패키지를 사용하고 있으며(따라서 PostgreSQL 12 이상 사용), pg_basebackup 도구가 포함되어 있습니다.
  • 기본 사이트가 이미 설정되어 있으며(복제 원본인 GitLab 서버), Linux 패키지 설치에서 관리하는 PostgreSQL(또는 동등한 버전)을 실행하고 있으며, 모든 사이트에서 동일한 PostgreSQL 버전, OS, GitLab으로 새 보조 사이트가 설정되어 있습니다.
Warning

Geo는 스트리밍 복제와 함께 작동합니다. 논리적 복제는 지원되지 않지만, 에픽 18022에서 이 동작 변경을 제안하고 있습니다.

1단계. 기본 사이트 구성#

  1. GitLab 기본 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

  3. /etc/gitlab/gitlab.rb를 편집하고 사이트에 고유한 이름을 추가합니다:

    ##
## Geo 사이트의 고유 식별자입니다. 다음을 참조하세요:
## https://docs.gitlab.com/administration/geo_sites/#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

  4. 변경 사항이 적용되도록 기본 사이트를 재구성합니다:

    gitlab-ctl reconfigure

  5. 아래 명령을 실행하여 사이트를 기본 사이트로 정의합니다:

    gitlab-ctl set-geo-primary-node

    이 명령은 /etc/gitlab/gitlab.rb에 정의된 external_url을 사용합니다.

  6. gitlab 데이터베이스 사용자의 비밀번호를 정의합니다:

    원하는 비밀번호의 MD5 해시를 생성합니다:

    gitlab-ctl pg-password-md5 gitlab
# Enter password: <your_db_password_here>
# Confirm password: <your_db_password_here>
# fca0b89a972d69f00eb3ec98a5838484

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

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

# Puma 또는 Sidekiq를 실행하는 모든 노드에 아래와 같이
# 데이터베이스 비밀번호가 지정되어 있어야 합니다. 고가용성 설정이 있는 경우
# 이 내용은 모든 애플리케이션 노드에 있어야 합니다.
gitlab_rails['db_password'] = '<your_db_password_here>'

  7. 데이터베이스 복제 사용자의 비밀번호를 정의합니다.

    /etc/gitlab/gitlab.rb의 postgresql['sql_replication_user'] 설정에 정의된 사용자 이름을 사용합니다. 기본값은 gitlab_replicator입니다. 사용자 이름을 다른 이름으로 변경한 경우, 아래 지침을 해당 사용자에 맞게 조정하세요.

    원하는 비밀번호의 MD5 해시를 생성합니다:

    gitlab-ctl pg-password-md5 gitlab_replicator
# Enter password: <your_replication_password_here>
# Confirm password: <your_replication_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e

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

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

    Linux 패키지 설치에서 관리하지 않는 외부 데이터베이스를 사용하는 경우, gitlab_replicator 사용자를 만들고 해당 사용자의 비밀번호를 수동으로 정의해야 합니다:

    --- 새 사용자 'replicator' 만들기
CREATE USER gitlab_replicator;

--- 비밀번호 설정/변경 및 복제 권한 부여
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

  8. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_primary_role로 설정합니다(자세한 내용은 Geo 역할 참조):

    ## Geo 기본 역할
roles(['geo_primary_role'])

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

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

    [!note] 외부 PostgreSQL 인스턴스의 경우, 추가 지침을 참조하세요.

    클라우드 공급자를 사용하는 경우, 클라우드 공급자의 관리 콘솔에서 각 Geo 사이트의 주소를 조회할 수 있습니다.

    Geo 사이트의 주소를 조회하려면 Geo 사이트에 SSH로 접속하고 다음을 실행합니다:

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

##
## 공용 주소
##
echo "External address: $(curl --silent "ipinfo.io/ip")"

    대부분의 경우 다음 주소를 GitLab Geo 구성에 사용합니다:

    구성 주소
    postgresql['listen_address'] 기본 사이트의 공용 또는 VPC 사설 주소.
    postgresql['md5_auth_cidr_addresses'] 기본 및 보조 사이트의 공용 또는 VPC 사설 주소.

    가상 사설 클라우드(VPC)를 제공하는 Google Cloud Platform, SoftLayer 또는 기타 공급업체를 사용하는 경우, postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에는 기본 및 보조 사이트의 "사설" 또는 "내부" 주소를 사용하는 것이 좋습니다.

    listen_address 옵션은 지정된 주소에 해당하는 인터페이스에서의 네트워크 연결을 허용하도록 PostgreSQL을 엽니다. 자세한 내용은 PostgreSQL 문서를 참조하세요.

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

    네트워크 구성에 따라 제안된 주소가 올바르지 않을 수 있습니다. 기본 및 보조 사이트가 로컬 영역 네트워크 또는 Amazon VPC나 Google VPC와 같이 가용 영역을 연결하는 가상 네트워크를 통해 연결하는 경우, postgresql['md5_auth_cidr_addresses']에는 보조 사이트의 사설 주소를 사용해야 합니다.

    /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. IP 주소를 네트워크 구성에 맞는 주소로 교체하세요:

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

##
# 기본 및 보조 IP에서 PostgreSQL 클라이언트 인증을 허용합니다. 이 IP는
# CIDR 형식의 공용 또는 VPC 주소일 수 있습니다(예: ['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 노드가 두 개 이상인 경우 이 값을 Geo 보조 노드 수로 설정합니다
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

  10. PostgreSQL이 재시작되어 사설 주소에서 수신할 때까지 자동 데이터베이스 마이그레이션을 일시적으로 비활성화합니다. /etc/gitlab/gitlab.rb를 편집하고 구성을 false로 변경합니다:

    ## 자동 데이터베이스 마이그레이션 비활성화
gitlab_rails['auto_migrate'] = false

  11. 선택 사항. 다른 보조 사이트를 추가하려면 관련 설정은 다음과 같습니다:

    postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32', '<another_secondary_site_ip>/32']

    데이터베이스 복제 요구 사항에 맞게 wal_keep_segments 및 max_wal_senders도 편집할 수 있습니다. 자세한 내용은 PostgreSQL - 복제 문서를 참조하세요.

  12. 파일을 저장하고 데이터베이스 수신 변경 사항 및 복제 슬롯 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

    변경 사항이 적용되도록 PostgreSQL을 재시작합니다:

    gitlab-ctl restart postgresql

  13. PostgreSQL이 재시작되어 사설 주소에서 수신하고 있으므로 이제 마이그레이션을 다시 활성화합니다.

    /etc/gitlab/gitlab.rb를 편집하고 구성을 true로 변경합니다:

    gitlab_rails['auto_migrate'] = true

    파일을 저장하고 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  14. PostgreSQL 서버가 원격 연결을 허용하도록 설정되었으므로, netstat -plnt | grep 5432를 실행하여 PostgreSQL이 기본 사이트의 사설 주소에서 포트 5432에서 수신하고 있는지 확인합니다.

  15. GitLab 재구성 시 인증서가 자동으로 생성되었습니다. 이 인증서는 도청자로부터 PostgreSQL 트래픽을 자동으로 보호하는 데 사용됩니다. 능동적("중간자 공격") 공격자로부터 보호하기 위해, 보조 사이트에는 인증서에 서명한 CA의 복사본이 필요합니다. 이 자체 서명 인증서의 경우, 다음 명령을 실행하여 기본 사이트에서 PostgreSQL server.crt 파일의 복사본을 만드세요:

    cat ~gitlab-psql/data/server.crt

    출력을 클립보드 또는 로컬 파일에 복사합니다. 보조 사이트를 설정할 때 필요합니다! 인증서는 민감한 데이터가 아닙니다.

    그러나 이 인증서는 일반적인 PostgreSQL Common Name으로 만들어집니다. 따라서 데이터베이스를 복제할 때 verify-ca 모드를 사용해야 합니다. 그렇지 않으면 호스트 이름 불일치로 오류가 발생합니다.

  16. 선택 사항. 생성된 인증서를 사용하는 대신 자체 SSL 인증서를 생성하고 PostgreSQL용 SSL 수동 구성을 합니다.

    SSL 인증서와 키가 최소한 필요합니다. Database SSL 문서에 따라 postgresql['ssl_cert_file'] 및 postgresql['ssl_key_file'] 값을 전체 경로로 설정합니다.

    이렇게 하면 데이터베이스를 복제할 때 verify-full SSL 모드를 사용하여 인증서 CN/SAN에서 전체 호스트 이름을 검증하는 추가 이점을 얻을 수 있습니다.

    이제부터 자동으로 생성된 자체 서명 인증서 대신 이 인증서(postgresql['ssl_cert_file']에도 설정한)를 사용할 수 있습니다. CN이 일치하면 복제 오류 없이 verify-full을 사용할 수 있습니다.

    기본 데이터베이스에서 /etc/gitlab/gitlab.rb를 열고 postgresql['ssl_ca_file'](CA 인증서)을 검색합니다. 그 값을 나중에 server.crt에 붙여넣을 클립보드에 복사합니다.

2단계. 보조 서버 구성#

  1. GitLab 보조 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

  3. 애플리케이션 서버 및 Sidekiq를 중지합니다:

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq

    [!note] 이 단계는 사이트가 완전히 구성되기 전에 어떤 작업도 실행하지 않도록 하기 위해 중요합니다.

  4. 기본 사이트의 PostgreSQL 서버에 대한 TCP 연결 확인:

    gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]

    [!note] 이 단계가 실패하면 잘못된 IP 주소를 사용하거나 방화벽이 사이트 접근을 방지하고 있을 수 있습니다. 공용 주소와 사설 주소의 차이에 주의하면서 IP 주소를 확인하세요. 방화벽이 있는 경우, 보조 사이트가 포트 5432에서 기본 사이트에 연결할 수 있는지 확인합니다.

  5. 기본 사이트 설정의 마지막 단계에서 얻은 콘텐츠로 보조 사이트에 server.crt 파일을 만듭니다:

    editor server.crt

  6. 보조 사이트에서 PostgreSQL TLS 검증을 설정합니다:

    server.crt 파일을 설치합니다:

    install \
   -D \
   -o gitlab-psql \
   -g gitlab-psql \
   -m 0400 \
   -T server.crt ~gitlab-psql/.postgresql/root.crt

    이제 PostgreSQL은 TLS 연결을 검증할 때 정확한 인증서만 인식합니다. 인증서는 개인 키에 접근할 수 있는 사람만 복제할 수 있으며, 이 키는 기본 사이트에만 있습니다.

  7. gitlab-psql 사용자가 기본 사이트의 데이터베이스에 연결할 수 있는지 테스트합니다 (Linux 패키지 설치에서 기본 데이터베이스 이름은 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>

    [!note] 수동으로 생성된 인증서를 사용하고 전체 호스트 이름 검증의 이점을 얻기 위해 sslmode=verify-full을 사용하려면, 명령 실행 시 verify-ca를 verify-full로 교체하세요.

    메시지가 표시되면 첫 번째 단계에서 gitlab_replicator 사용자에 대해 설정한 일반 텍스트 비밀번호를 입력합니다. 모든 것이 올바르게 작동하면 기본 사이트의 데이터베이스 목록이 표시됩니다.

    여기에서 연결 실패는 TLS 구성이 잘못되었음을 나타냅니다. 기본 사이트의 ~gitlab-psql/data/server.crt 내용이 보조 사이트의 ~gitlab-psql/.postgresql/root.crt 내용과 일치하는지 확인합니다.

  8. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_secondary_role로 설정합니다(자세한 내용은 Geo 역할 참조):

    ##
## Geo 보조 역할
## - Geo를 활성화하기 위해 종속 플래그를 자동으로 구성합니다
##
roles(['geo_secondary_role'])

  9. PostgreSQL을 구성합니다:

    이 단계는 기본 인스턴스를 구성한 방법과 유사합니다. 단일 노드를 사용하더라도 이를 활성화해야 합니다.

    [!warning] 각 비밀번호 유형은 모든 Geo 사이트에서 일치하는 값을 가져야 합니다.

    /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. IP 주소를 네트워크 구성에 맞는 주소로 교체하세요:

    ##
## 보조 주소
## - '<secondary_site_ip>'를 Geo 보조 사이트의 공용 또는 VPC 주소로 교체합니다
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']

##
## 데이터베이스 자격 증명 비밀번호(이전에 기본 사이트에서 정의됨)
## - 기본 사이트에서 정의된 것과 동일한 값을 여기에 복제합니다
##
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
gitlab_rails['db_password'] = '<your_db_password_here>'

    외부 PostgreSQL 인스턴스의 경우, 추가 지침을 참조하세요. 이전 기본 사이트를 보조 사이트로 다시 온라인으로 전환하는 경우, roles(['geo_primary_role']) 또는 geo_primary_role['enable'] = true도 제거해야 합니다.

  10. 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  11. IP 변경 사항이 적용되도록 PostgreSQL을 재시작합니다:

    gitlab-ctl restart postgresql

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

아래는 보조 사이트의 데이터베이스를 기본 사이트의 데이터베이스에 연결하는 스크립트입니다. 이 스크립트는 데이터베이스를 복제하고 스트리밍 복제에 필요한 파일을 만듭니다.

사용된 디렉토리는 Linux 패키지 설치에서 설정된 기본값입니다. 기본값을 변경한 경우, 스크립트를 그에 맞게 구성하세요 (디렉토리 및 경로 교체).

Warning

pg_basebackup을 실행하기 전에 모든 PostgreSQL 데이터를 제거하므로 보조 사이트에서 실행해야 합니다.

  1. GitLab 보조 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 보조 사이트에서 복제 슬롯 이름으로 사용할 데이터베이스 친화적인 이름을 선택합니다. 예를 들어 도메인이 secondary.geo.example.com인 경우, 아래 명령에 표시된 것처럼 슬롯 이름으로 secondary_example을 사용합니다.

  3. 아래 명령을 실행하여 백업/복원을 시작하고 복제를 시작합니다

    [!warning] 각 Geo 보조 사이트에는 고유한 복제 슬롯 이름이 있어야 합니다. 두 보조 사이트 간에 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 중단됩니다.

    복제 슬롯 이름에는 소문자, 숫자 및 밑줄 문자만 포함할 수 있습니다.

    메시지가 표시되면 첫 번째 단계에서 gitlab_replicator 사용자에 대해 설정한 일반 텍스트 비밀번호를 입력합니다.

    gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca

    [!note] 사용자 지정 PostgreSQL 인증서를 생성한 경우, 추가 보안을 위해 인증서 CN/SAN의 전체 호스트 이름 검증의 이점을 얻으려면 --sslmode=verify-full을 사용해야 합니다(또는 sslmode 줄을 완전히 생략). 그렇지 않으면 자동으로 생성된 인증서로 verify-full을 사용하면 실패합니다. 일반적인 PostgreSQL CN이 이 명령의 --host 값과 일치하지 않기 때문입니다.

    이 명령은 추가 옵션도 사용합니다. --help를 사용하여 모두 나열할 수 있지만, 다음은 몇 가지 팁입니다:

    • 기본 사이트에 단일 노드가 있는 경우, 기본 노드 호스트를 --host 매개변수로 사용합니다.
    • 기본 사이트가 외부 PostgreSQL 데이터베이스를 사용하는 경우, --host 매개변수를 조정해야 합니다:
      • PgBouncer 설정의 경우, PgBouncer 주소가 아닌 실제 PostgreSQL 데이터베이스 호스트를 직접 대상으로 합니다.
      • Patroni 구성의 경우, 현재 Patroni 리더 호스트를 대상으로 합니다.
      • 로드 밸런서(예: HAProxy) 사용 시, 로드 밸런서가 항상 Patroni 리더로 라우팅하도록 구성된 경우 로드 밸런서를 대상으로 할 수 있습니다. 그렇지 않은 경우, 실제 데이터베이스 호스트를 대상으로 해야 합니다.
      • 전용 PostgreSQL 노드가 있는 설정의 경우, 전용 데이터베이스 호스트를 직접 대상으로 합니다.
    • 기본 데이터베이스에 사용할 복제 슬롯 이름으로 --slot-name을 변경합니다. 스크립트는 복제 슬롯이 존재하지 않으면 자동으로 생성을 시도합니다.
    • PostgreSQL이 비표준 포트에서 수신 중인 경우, --port=를 추가합니다.
    • 데이터베이스가 30분 이내에 전송되기에 너무 큰 경우, 타임아웃을 늘려야 합니다. 예를 들어 초기 복제가 1시간 미만 걸릴 것으로 예상되면 --backup-timeout=3600을 사용합니다.
    • --sslmode=disable을 전달하여 PostgreSQL TLS 인증을 완전히 건너뜁니다 (예: 네트워크 경로가 안전하거나 사이트 간 VPN을 사용하는 경우). 공용 인터넷을 통해 사용하는 것은 안전하지 않습니다!
    • 각 sslmode에 대한 자세한 내용은 PostgreSQL 문서에서 읽을 수 있습니다. 앞서 나열된 지침은 수동 도청자와 능동적 "중간자 공격" 공격자 모두로부터 보호를 보장하기 위해 신중하게 작성되었습니다.
    • 이전 사이트를 Geo 보조 사이트로 용도를 변경하는 경우, 명령줄에 --force를 추가해야 합니다.
    • 프로덕션 환경이 아닌 경우, --skip-backup을 추가하여 백업 단계를 비활성화할 수 있습니다(이것이 원하는 것임을 확실히 아는 경우).

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

Note

복제 프로세스는 기본 사이트의 데이터베이스에서 보조 사이트의 데이터베이스로 데이터만 복사합니다. 보조 사이트 구성을 완료하려면 기본 사이트에서 보조 사이트를 추가하세요.

PgBouncer 지원 (선택 사항)#

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

Geo 기본 사이트를 지원하는 노드 클러스터와 Geo 보조 사이트를 지원하는 두 개의 다른 노드 클러스터가 있는 고가용성 구성에서 GitLab을 사용하는 경우 PgBouncer를 사용해야 합니다. PgBouncer 노드가 두 개 필요합니다: 메인 데이터베이스용과 추적 데이터베이스용. 자세한 내용은 관련 문서를 참조하세요.

복제 비밀번호 변경#

Warning

복제 비밀번호를 변경할 때는 모든 Geo 사이트(기본 및 모든 보조)에서 동일한 비밀번호 값으로 업데이트해야 합니다. 비밀번호를 동기화하지 않으면 복제가 중단됩니다.

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

GitLab Geo 기본 사이트에서:

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

    원하는 비밀번호의 MD5 해시를 생성합니다:

    sudo gitlab-ctl pg-password-md5 gitlab_replicator
# Enter password: <your_replication_password_here>
# Confirm password: <your_replication_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e

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

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

  2. 파일을 저장하고 GitLab을 재구성하여 PostgreSQL의 복제 사용자 비밀번호를 변경합니다:

    sudo gitlab-ctl reconfigure

  3. 복제 비밀번호 변경 사항이 적용되도록 PostgreSQL을 재시작합니다:

    sudo gitlab-ctl restart postgresql

보조 사이트에서 비밀번호가 업데이트되기 전까지, 보조 사이트의 PostgreSQL 로그에 다음 오류 메시지가 보고됩니다:

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

모든 GitLab Geo 보조 사이트에서:

  1. 첫 번째 단계는 구성 관점에서 필요하지 않습니다. 해시된 'sql_replication_password'는 GitLab Geo 보조 사이트에서 사용되지 않기 때문입니다. 그러나 보조 사이트가 GitLab Geo 기본 사이트로 승격되어야 하는 경우에 대비하여, 보조 사이트 구성의 'sql_replication_password'가 기본 사이트와 일치하는지 확인하세요.

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

    # Geo 기본 사이트에서 `gitlab-ctl pg-password-md5 gitlab_replicator`로 생성한 해시로 채웁니다
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

  2. 초기 복제 설정 중에 gitlab-ctl replicate-geo-database 명령은 복제 사용자 계정의 일반 텍스트 비밀번호를 두 위치에 씁니다:

    • gitlab-geo.conf: PostgreSQL 복제 프로세스에서 사용되며, 기본적으로 /var/opt/gitlab/postgresql/data/gitlab-geo.conf의 PostgreSQL 데이터 디렉토리에 씁니다.
    • .pgpass: gitlab-psql 사용자가 사용하며, 기본적으로 /var/opt/gitlab/postgresql/.pgpass에 있습니다.

    이 두 파일에서 일반 텍스트 비밀번호를 업데이트하고, PostgreSQL을 재시작합니다:

    sudo gitlab-ctl restart postgresql

다중 노드 데이터베이스 복제#

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

Patroni 도입 이전에 Geo는 보조 사이트의 HA 설정을 위한 Linux 패키지 설치를 지원하지 않았습니다.

Patroni를 사용하면 이 지원이 이제 가능합니다. 기존 PostgreSQL을 Patroni로 마이그레이션하려면:

  1. 보조 사이트에 Consul 클러스터가 설정되어 있는지 확인합니다(기본 사이트에 설정한 것과 유사).
  2. 영구 복제 슬롯 구성.
  3. 내부 로드 밸런서 구성.
  4. PgBouncer 노드 구성
  5. 해당 단일 노드 머신에서 스탠바이 클러스터 구성.

결과적으로 단일 노드로 구성된 스탠바이 클러스터가 생깁니다. 이를 통해 앞서 나열된 동일한 지침에 따라 추가 Patroni 노드를 추가할 수 있습니다.

Patroni 지원#

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

기본 사이트에서 Patroni를 설정하는 방법에 대한 지침은 관련 문서를 참조하세요.

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

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

프로덕션 준비가 완료된 안전한 설정에는 최소한 다음이 필요합니다:

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

내부 로드 밸런서는 새 리더가 선출될 때마다 Patroni 클러스터의 리더에 연결하기 위한 단일 엔드포인트를 제공합니다. 로드 밸런서는 보조 사이트에서의 계단식 복제를 활성화하는 데 필요합니다.

비밀번호 자격 증명 및 기타 데이터베이스 모범 사례를 사용해야 합니다.

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

기본 데이터베이스에서 보조 노드의 Patroni 클러스터로 지속적인 데이터 복제를 보장하기 위해 기본 데이터베이스에 영구 복제 슬롯을 설정합니다.

보조 사이트에서 Patroni로 데이터베이스 복제를 설정하려면, 기본 사이트의 Patroni 클러스터에 영구 복제 슬롯을 구성하고 비밀번호 인증이 사용되도록 해야 합니다.

기본 사이트에서 Patroni 리더 인스턴스부터 시작하여 Patroni 인스턴스를 실행하는 각 노드에서:

  1. Patroni 인스턴스에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

  3. /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. 각 비밀번호 유형이 모든 Geo 사이트에서 일치하는 값을 가지는지 확인하세요.

    roles(['patroni_role'])

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

# 각 보조 사이트에 대해 PostgreSQL slot_name 제약 조건을 따르는 고유한 이름으로 하나의 항목이 필요합니다:
#
# 구성 구문: 'unique_slotname' => { 'type' => 'physical' },
# 논리적 복제 유형에 대한 영구 복제 슬롯 설정은 지원하지 않습니다
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}

patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # patroni/예약 슬롯 수의 두 배를 사용합니다 (Patroni 3개 + Geo 보조 사이트용 예약 슬롯 1개).
patroni['postgresql']['max_replication_slots'] = 8 # patroni/예약 슬롯 수의 두 배를 사용합니다 (Patroni 3개 + Geo 보조 사이트용 예약 슬롯 1개).
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'

# 모든 patroni 노드를 허용 목록에 추가합니다
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
]

# 모든 보조 인스턴스가 스탠바이 리더가 될 수 있으므로 모두 나열합니다
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 주소를 사용할 수 있습니다

  4. 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  1. 단일 노드 인스턴스에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

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

    postgresql['max_wal_senders'] = 2 # 보조 사이트당 2를 사용합니다 (초기 Patroni 복제를 위한 임시 슬롯 1개 + Geo 보조 사이트용 예약 슬롯 1개)
postgresql['max_replication_slots'] = 2 # 보조 사이트당 2를 사용합니다 (초기 Patroni 복제를 위한 임시 슬롯 1개 + Geo 보조 사이트용 예약 슬롯 1개)

  4. GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  5. 새 변경 사항이 적용되도록 PostgreSQL 서비스를 재시작합니다:

    gitlab-ctl restart postgresql

  6. 데이터베이스 콘솔을 시작합니다

    gitlab-psql

  7. 기본 사이트에서 영구 복제 슬롯을 구성합니다

    select pg_create_physical_replication_slot('geo_secondary')

  8. 선택 사항. 기본 사이트에는 PgBouncer가 없지만 보조 사이트에 있는 경우:

    기본 사이트에서 pgbouncer 사용자를 구성하고 Linux 패키지에 포함된 PgBouncer에 필요한 pg_shadow_lookup 함수를 추가합니다. 보조 서버의 PgBouncer는 여전히 보조 사이트의 PostgreSQL 노드에 연결할 수 있어야 합니다.

    --- 새 사용자 'pgbouncer' 만들기
CREATE USER pgbouncer;

--- 비밀번호 설정/변경 및 복제 권한 부여
ALTER USER pgbouncer WITH REPLICATION ENCRYPTED PASSWORD '<pgbouncer_password_from_secondary>';

CREATE OR REPLACE FUNCTION public.pg_shadow_lookup(in i_username text, out username text, out password text) RETURNS record AS $$
BEGIN
    SELECT usename, passwd FROM pg_catalog.pg_shadow
    WHERE usename = i_username INTO username, password;
    RETURN;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

REVOKE ALL ON FUNCTION public.pg_shadow_lookup(text) FROM public, pgbouncer;
GRANT EXECUTE ON FUNCTION public.pg_shadow_lookup(text) TO pgbouncer;
2단계. 기본 사이트에서 내부 로드 밸런서 구성#

기본 사이트에서 새 리더가 선출될 때마다 보조 사이트의 스탠바이 리더를 재구성하지 않으려면, 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
    mode tcp
    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 노드 구성#

프로덕션 준비가 완료된 고가용성 구성에는 최소 3개의 Consul 노드와 최소 1개의 PgBouncer 노드가 필요합니다. 그러나 데이터베이스 노드당 하나의 PgBouncer 노드를 두는 것이 좋습니다. PgBouncer 서비스 노드가 두 개 이상인 경우 내부 로드 밸런서(TCP)가 필요합니다. 내부 로드 밸런서는 PgBouncer 클러스터에 연결하기 위한 단일 엔드포인트를 제공합니다. 자세한 내용은 관련 문서를 참조하세요.

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

  1. PgBouncer 노드에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

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

  3. 변경 사항이 적용되도록 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  4. Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 만듭니다. 요청 시 PLAIN_TEXT_PGBOUNCER_PASSWORD를 두 번 입력합니다:

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

  5. PgBouncer 서비스를 다시 로드합니다:

    gitlab-ctl hup pgbouncer
4단계. 보조 사이트에서 스탠바이 클러스터 구성#
Note

단일 PostgreSQL 인스턴스가 있는 보조 사이트를 Patroni 클러스터로 변환하는 경우, PostgreSQL 인스턴스에서 시작해야 합니다. 이 인스턴스가 Patroni 스탠바이 리더 인스턴스가 되고, 그런 다음 필요하면 다른 복제본으로 전환할 수 있습니다.

보조 사이트에서 Patroni 인스턴스를 실행하는 각 노드에서:

  1. Patroni 노드에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 의도하지 않은 다운타임을 방지하기 위해 GitLab 업그레이드 시 자동 PostgreSQL 업그레이드에서 제외하세요. Geo로 PostgreSQL을 업그레이드할 때의 주의 사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 따라서 앞으로 PostgreSQL 업그레이드는 정기적인 유지보수 활동의 일부로 포함시키세요.

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

    [!warning] 각 비밀번호 유형은 모든 Geo 사이트에서 일치하는 값을 가져야 합니다.

    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 # 복제본 하나에 최소 3개, 추가 복제본마다 2개씩 추가
patroni['postgresql']['max_replication_slots'] = 5 # 복제본 하나에 최소 3개, 추가 복제본마다 2개씩 추가

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-ctl geo-replication-pause`를 위해 GitLab Rails 구성이 필요합니다
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 클러스터 리더에 구성된 프론트엔드 포트를 가리켜야 합니다. PgBouncer 프론트엔드 포트를 사용하지 마세요.

  4. 변경 사항이 적용되도록 GitLab을 재구성합니다. 이 단계는 PostgreSQL 사용자 및 설정을 부트스트랩하는 데 필요합니다.

    • 새로운 Patroni 설치인 경우:

      gitlab-ctl reconfigure

    • 이전에 작동하는 Patroni 클러스터가 있던 사이트에서 Patroni 스탠바이 클러스터를 구성하는 경우:

      1. Patroni가 관리하는 모든 노드에서(계단식 복제본 포함) Patroni를 중지합니다:

        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

      3. 리더 Patroni 노드에서 Patroni를 시작하여 기본 데이터베이스에서 복제 프로세스를 시작합니다:

        gitlab-ctl start patroni

      4. Patroni 클러스터의 상태를 확인합니다:

        gitlab-ctl patroni members

        다음을 확인합니다:

        • 현재 Patroni 노드가 출력에 나타납니다.
        • 역할이 Standby Leader입니다. 역할이 처음에는 Replica로 표시될 수 있습니다.
        • 상태가 Running입니다. 상태가 처음에는 Creating replica로 표시될 수 있습니다.

        노드의 역할이 Standby Leader로 안정되고 상태가 Running이 될 때까지 기다립니다. 이 과정이 몇 분 정도 걸릴 수 있습니다.

      5. 리더 Patroni 노드가 Standby Leader이고 Running 상태이면, 스탠바이 클러스터의 다른 Patroni 노드에서 Patroni를 시작합니다:

        gitlab-ctl start patroni

        다른 Patroni 노드는 자동으로 새 스탠바이 클러스터에 복제본으로 참여하고 리더 Patroni 노드에서 복제를 시작합니다.

  5. 클러스터 상태를 확인합니다:

    gitlab-ctl patroni members

    모든 Patroni 노드가 Running 상태로 나열되어 있는지 확인합니다. Standby Leader 노드 하나와 여러 개의 Replica 노드가 있어야 합니다.

단일 추적 데이터베이스 노드를 Patroni로 마이그레이션#

Patroni 도입 이전에 Geo는 보조 사이트의 HA 설정을 위한 Linux 패키지 설치를 지원하지 않았습니다.

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

보조 노드는 새 추적 데이터베이스를 백필하며, 데이터 동기화가 필요하지 않습니다.

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

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

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

Linux 패키지는 고가용성 구성에서 Geo 추적 데이터베이스 실행을 지원하지 않습니다. 특히 장애 조치가 제대로 작동하지 않습니다. 기능 요청 이슈를 참조하세요.

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

트러블슈팅#

트러블슈팅 문서를 읽으세요.