InfoGrab DocsInfoGrab 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를 편집하고 사이트에 고유한 이름을 추가합니다.

    ##
## The unique identifier for the Geo site. See
## 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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'

# Every node that runs Puma or Sidekiq needs to have the database
# password specified as below. If you have a high-availability setup, this
# must be present in all application nodes.
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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

    Linux 패키지 설치로 관리되지 않는 외부 데이터베이스를 사용하는 경우, gitlab_replicator 사용자를 직접 생성하고 비밀번호를 수동으로 정의해야 합니다.

    --- Create a new user 'replicator'
CREATE USER gitlab_replicator;

--- Set/change a password and grants replication privilege
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

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

    ## Geo Primary role
roles(['geo_primary_role'])

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

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

    [!note] 외부 PostgreSQL 인스턴스의 경우 추가 지침을 참고합니다.

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

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

    ##
## Private address
##
ip route get 255.255.255.255 | awk '{for (i=1; i<=NF; i++) if ($i == "src") { print "Private address:", $(i+1); exit }}'

##
## Public address
##
echo "External address: $(curl --silent "ipinfo.io/ip")"

    대부분의 경우 GitLab Geo를 구성할 때 다음 주소가 사용됩니다.

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

    Google Cloud Platform, SoftLayer 또는 가상 프라이빗 클라우드(VPC)를 제공하는 다른 공급자를 사용하는 경우, 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 address
## - replace '<primary_node_ip>' with the public or VPC address of your Geo primary node
##
postgresql['listen_address'] = '<primary_site_ip>'

##
# Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
# public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

##
## Replication settings
##
# postgresql['max_replication_slots'] = 1 # Set this to be the number of Geo secondary nodes if you have more than one
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

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

    ## Disable automatic database migrations
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 트래픽을 보호하는 데 자동으로 사용됩니다. 활성 공격("man-in-the-middle")으로부터 보호하려면, 보조 사이트에 인증서에 서명한 CA의 사본이 필요합니다. 이 자체 서명 인증서의 경우, 다음 명령을 실행해 기본 사이트의 PostgreSQL server.crt 파일을 복사합니다.

    cat ~gitlab-psql/data/server.crt

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

    그러나 이 인증서는 일반적인 PostgreSQL Common Name으로 생성됩니다. 이 때문에 데이터베이스를 복제할 때 verify-ca 모드를 사용해야 하며, 그렇지 않으면 호스트 이름이 일치하지 않아 오류가 발생합니다.

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

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

    이렇게 하면 데이터베이스를 복제할 때 verify-full SSL 모드를 사용할 수 있으며, CN의 전체 호스트 이름을 확인하는 추가 이점도 얻을 수 있습니다.

    앞으로는 이전에 자동으로 생성된 자체 서명 인증서 대신, 이 인증서 (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 확인을 설정합니다.

    gitlab-psql 사용자를 위해 server.crt 파일을 설치합니다.

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

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

    gitlab-ctl replicate-geo-database는 root 권한으로 실행되므로, root 사용자를 위해서도 인증서를 설치합니다. 그렇지 않으면 sslmode=verify-ca 또는 sslmode=verify-full을 사용할 때 복제 명령이 could not open certificate file 오류로 실패합니다.

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

  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 Secondary role
## - configure dependent flags automatically to enable Geo
##
roles(['geo_secondary_role'])

  9. PostgreSQL을 구성합니다.

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

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

    /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)
## - replicate same values here as defined in primary site
##
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과 함께 사용할 때, 이 명령의 --host 값과 일치하지 않는 일반 PostgreSQL CN 때문에 실패합니다.

    이 명령은 다양한 추가 옵션도 제공합니다. --help를 사용하면 모두 나열할 수 있지만, 여기 몇 가지 팁이 있습니다.

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

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

Note

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

PgBouncer 지원(선택 사항)#

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

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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

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

    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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator` on the Geo primary
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

  2. 초기 복제 설정 중에 gitlab-ctl replicate-geo-database 명령은 복제 사용자 계정의 평문 비밀번호를 두 위치에 기록합니다.

    • gitlab-geo.conf: PostgreSQL 복제 프로세스에서 사용하며, 기본적으로 PostgreSQL 데이터 디렉터리인 /var/opt/gitlab/postgresql/data/gitlab-geo.conf에 기록됩니다.
    • .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 데이터베이스의 읽기 전용 복제본입니다.

프로덕션에 사용할 수 있는 안전한 설정에는 최소한 다음이 필요합니다.

  • Consul 노드 3개 (기본 및 보조 사이트)
  • Patroni 노드 2개 (기본 및 보조 사이트)
  • PgBouncer 노드 1개 (기본 및 보조 사이트)
  • 내부 로드 밸런서 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]
}

# You need one entry for each secondary, with a unique name following PostgreSQL slot_name constraints:
#
# Configuration syntax is: 'unique_slotname' => { 'type' => 'physical' },
# We don't support setting a permanent replication slot for logical replication type
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}

patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # Use double of the amount of patroni/reserved slots (3 patronis + 1 reserved slot for a Geo secondary).
patroni['postgresql']['max_replication_slots'] = 8 # Use double of the amount of patroni/reserved slots (3 patronis + 1 reserved slot for a Geo secondary).
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'

# Add all patroni nodes to the 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
]

# We list all secondary instances as they can all become a Standby Leader
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' # You can use a public or VPC address here instead

  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 # Use 2 per secondary site (1 temporary slot for initial Patroni replication + 1 reserved slot for a Geo secondary)
postgresql['max_replication_slots'] = 2 # Use 2 per secondary site (1 temporary slot for initial Patroni replication + 1 reserved slot for a Geo secondary)

  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 노드에 연결할 수 있어야 합니다.

    --- Create a new user 'pgbouncer'
CREATE USER pgbouncer;

--- Set/change a password and grants replication privilege
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 서비스 노드가 2개를 초과하는 경우, 내부 로드 밸런서(TCP)가 필요합니다. 내부 로드 밸런서는 PgBouncer 클러스터에 연결하기 위한 단일 엔드포인트를 제공합니다. 자세한 내용은 관련 문서를 참고합니다.

보조 사이트에서 PgBouncer 인스턴스를 실행하는 각 노드에서 다음과 같이 합니다.

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

    sudo -i

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

    # Disable all components except Pgbouncer and Consul agent
roles(['pgbouncer_role'])

# PgBouncer configuration
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
'gitlab-consul': {
   # Generate it with: `gitlab-ctl pg-password-md5 gitlab-consul`
   password: 'GITLAB_CONSUL_PASSWORD_HASH'
 },
  'pgbouncer': {
    # Generate it with: `gitlab-ctl pg-password-md5 pgbouncer`
    password: 'PGBOUNCER_PASSWORD_HASH'
  }
}

# Consul configuration
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',
  # Any other instance that needs access to the database as per documentation
]

# Add patroni nodes to the allowlist
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' # Or the unique replication slot name you setup before
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 # A minimum of three for one replica, plus two for each additional replica
patroni['postgresql']['max_replication_slots'] = 5 # A minimum of three for one replica, plus two for each additional replica

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' # You can use a public or VPC address here instead

# GitLab Rails configuration is required for `gitlab-ctl geo-replication-pause`
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 데이터베이스나, GitLab Linux 패키지로 관리되지 않는 수동으로 구성한 Patroni 클러스터에 연결할 수 있습니다. 외부 PostgreSQL 인스턴스를 사용하는 Geo 절차를 따릅니다.

문제 해결#

문제 해결 문서를 참고합니다.

Geo 데이터베이스 복제

GitLab v19.4
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를 편집하고 사이트에 고유한 이름을 추가합니다.

    ##
## The unique identifier for the Geo site. See
## 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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'

# Every node that runs Puma or Sidekiq needs to have the database
# password specified as below. If you have a high-availability setup, this
# must be present in all application nodes.
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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

    Linux 패키지 설치로 관리되지 않는 외부 데이터베이스를 사용하는 경우, gitlab_replicator 사용자를 직접 생성하고 비밀번호를 수동으로 정의해야 합니다.

    --- Create a new user 'replicator'
CREATE USER gitlab_replicator;

--- Set/change a password and grants replication privilege
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

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

    ## Geo Primary role
roles(['geo_primary_role'])

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

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

    [!note] 외부 PostgreSQL 인스턴스의 경우 추가 지침을 참고합니다.

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

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

    ##
## Private address
##
ip route get 255.255.255.255 | awk '{for (i=1; i<=NF; i++) if ($i == "src") { print "Private address:", $(i+1); exit }}'

##
## Public address
##
echo "External address: $(curl --silent "ipinfo.io/ip")"

    대부분의 경우 GitLab Geo를 구성할 때 다음 주소가 사용됩니다.

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

    Google Cloud Platform, SoftLayer 또는 가상 프라이빗 클라우드(VPC)를 제공하는 다른 공급자를 사용하는 경우, 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 address
## - replace '<primary_node_ip>' with the public or VPC address of your Geo primary node
##
postgresql['listen_address'] = '<primary_site_ip>'

##
# Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
# public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

##
## Replication settings
##
# postgresql['max_replication_slots'] = 1 # Set this to be the number of Geo secondary nodes if you have more than one
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

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

    ## Disable automatic database migrations
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 트래픽을 보호하는 데 자동으로 사용됩니다. 활성 공격("man-in-the-middle")으로부터 보호하려면, 보조 사이트에 인증서에 서명한 CA의 사본이 필요합니다. 이 자체 서명 인증서의 경우, 다음 명령을 실행해 기본 사이트의 PostgreSQL server.crt 파일을 복사합니다.

    cat ~gitlab-psql/data/server.crt

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

    그러나 이 인증서는 일반적인 PostgreSQL Common Name으로 생성됩니다. 이 때문에 데이터베이스를 복제할 때 verify-ca 모드를 사용해야 하며, 그렇지 않으면 호스트 이름이 일치하지 않아 오류가 발생합니다.

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

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

    이렇게 하면 데이터베이스를 복제할 때 verify-full SSL 모드를 사용할 수 있으며, CN의 전체 호스트 이름을 확인하는 추가 이점도 얻을 수 있습니다.

    앞으로는 이전에 자동으로 생성된 자체 서명 인증서 대신, 이 인증서 (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 확인을 설정합니다.

    gitlab-psql 사용자를 위해 server.crt 파일을 설치합니다.

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

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

    gitlab-ctl replicate-geo-database는 root 권한으로 실행되므로, root 사용자를 위해서도 인증서를 설치합니다. 그렇지 않으면 sslmode=verify-ca 또는 sslmode=verify-full을 사용할 때 복제 명령이 could not open certificate file 오류로 실패합니다.

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

  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 Secondary role
## - configure dependent flags automatically to enable Geo
##
roles(['geo_secondary_role'])

  9. PostgreSQL을 구성합니다.

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

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

    /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)
## - replicate same values here as defined in primary site
##
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과 함께 사용할 때, 이 명령의 --host 값과 일치하지 않는 일반 PostgreSQL CN 때문에 실패합니다.

    이 명령은 다양한 추가 옵션도 제공합니다. --help를 사용하면 모두 나열할 수 있지만, 여기 몇 가지 팁이 있습니다.

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

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

Note

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

PgBouncer 지원(선택 사항)#

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

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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

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

    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를 편집합니다.

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator` on the Geo primary
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

  2. 초기 복제 설정 중에 gitlab-ctl replicate-geo-database 명령은 복제 사용자 계정의 평문 비밀번호를 두 위치에 기록합니다.

    • gitlab-geo.conf: PostgreSQL 복제 프로세스에서 사용하며, 기본적으로 PostgreSQL 데이터 디렉터리인 /var/opt/gitlab/postgresql/data/gitlab-geo.conf에 기록됩니다.
    • .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 데이터베이스의 읽기 전용 복제본입니다.

프로덕션에 사용할 수 있는 안전한 설정에는 최소한 다음이 필요합니다.

  • Consul 노드 3개 (기본 및 보조 사이트)
  • Patroni 노드 2개 (기본 및 보조 사이트)
  • PgBouncer 노드 1개 (기본 및 보조 사이트)
  • 내부 로드 밸런서 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]
}

# You need one entry for each secondary, with a unique name following PostgreSQL slot_name constraints:
#
# Configuration syntax is: 'unique_slotname' => { 'type' => 'physical' },
# We don't support setting a permanent replication slot for logical replication type
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}

patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # Use double of the amount of patroni/reserved slots (3 patronis + 1 reserved slot for a Geo secondary).
patroni['postgresql']['max_replication_slots'] = 8 # Use double of the amount of patroni/reserved slots (3 patronis + 1 reserved slot for a Geo secondary).
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'

# Add all patroni nodes to the 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
]

# We list all secondary instances as they can all become a Standby Leader
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' # You can use a public or VPC address here instead

  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 # Use 2 per secondary site (1 temporary slot for initial Patroni replication + 1 reserved slot for a Geo secondary)
postgresql['max_replication_slots'] = 2 # Use 2 per secondary site (1 temporary slot for initial Patroni replication + 1 reserved slot for a Geo secondary)

  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 노드에 연결할 수 있어야 합니다.

    --- Create a new user 'pgbouncer'
CREATE USER pgbouncer;

--- Set/change a password and grants replication privilege
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 서비스 노드가 2개를 초과하는 경우, 내부 로드 밸런서(TCP)가 필요합니다. 내부 로드 밸런서는 PgBouncer 클러스터에 연결하기 위한 단일 엔드포인트를 제공합니다. 자세한 내용은 관련 문서를 참고합니다.

보조 사이트에서 PgBouncer 인스턴스를 실행하는 각 노드에서 다음과 같이 합니다.

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

    sudo -i

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

    # Disable all components except Pgbouncer and Consul agent
roles(['pgbouncer_role'])

# PgBouncer configuration
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
'gitlab-consul': {
   # Generate it with: `gitlab-ctl pg-password-md5 gitlab-consul`
   password: 'GITLAB_CONSUL_PASSWORD_HASH'
 },
  'pgbouncer': {
    # Generate it with: `gitlab-ctl pg-password-md5 pgbouncer`
    password: 'PGBOUNCER_PASSWORD_HASH'
  }
}

# Consul configuration
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',
  # Any other instance that needs access to the database as per documentation
]

# Add patroni nodes to the allowlist
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' # Or the unique replication slot name you setup before
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 # A minimum of three for one replica, plus two for each additional replica
patroni['postgresql']['max_replication_slots'] = 5 # A minimum of three for one replica, plus two for each additional replica

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' # You can use a public or VPC address here instead

# GitLab Rails configuration is required for `gitlab-ctl geo-replication-pause`
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 데이터베이스나, GitLab Linux 패키지로 관리되지 않는 수동으로 구성한 Patroni 클러스터에 연결할 수 있습니다. 외부 PostgreSQL 인스턴스를 사용하는 Geo 절차를 따릅니다.

문제 해결#

문제 해결 문서를 참고합니다.