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이 설치된 새로운 보조 사이트가 준비되어 있습니다.

Note

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

Step 1. 기본 사이트 구성#

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

    sudo -i

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

  • /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>'

  • 변경 사항을 적용하려면 기본 사이트를 재구성합니다.

    gitlab-ctl reconfigure

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

    gitlab-ctl set-geo-primary-node

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

  • 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>'

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

    postgresql['sql_replication_user'] 설정 아래 /etc/gitlab/gitlab.rb에 정의된 사용자 이름을 사용하세요. 기본값은 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>';

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

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

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

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

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

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

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

    ##
## Private address
##
ip route get 255.255.255.255 | awk '{print "Private address:", $NF; 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

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

    ## Disable automatic database migrations
gitlab_rails['auto_migrate'] = false

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

    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 - 복제 문서를 참조하세요.

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

    gitlab-ctl reconfigure

    변경 사항을 적용하려면 PostgreSQL을 재시작합니다.

    gitlab-ctl restart postgresql

  • PostgreSQL이 재시작하고 개인 주소에서 수신 대기하고 있으므로 마이그레이션을 다시 활성화합니다.

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

    gitlab_rails['auto_migrate'] = true

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

    gitlab-ctl reconfigure

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

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

    cat ~gitlab-psql/data/server.crt

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

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

  • 선택 사항: 생성된 인증서 대신 자체 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에 붙여넣으세요.

Step 2. 보조 서버 구성#

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

    sudo -i

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

  • 애플리케이션 서버와 Sidekiq를 중지합니다.

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq

    [!note] 이 단계는 사이트가 완전히 구성되기 전에 아무것도 실행하지 않도록 하는 데 중요합니다.

  • 기본 사이트의 PostgreSQL 서버에 대한 TCP 연결을 확인합니다.

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

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

  • 기본 사이트 설정의 마지막 단계에서 얻은 내용으로 보조 사이트에 server.crt 파일을 만듭니다.

    editor server.crt

  • 보조 사이트에서 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

  • 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 내용과 일치하는지 확인하세요.

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

    ##
## Geo Secondary role
## - configure dependent flags automatically to enable Geo
##
roles(['geo_secondary_role'])

  • PostgreSQL을 구성합니다.

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

    [!note] 각 비밀번호 유형은 모든 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도 제거해야 합니다.

  • 변경 사항을 적용하려면 GitLab을 재구성합니다.

    gitlab-ctl reconfigure

  • IP 변경 사항을 적용하려면 PostgreSQL을 재시작합니다.

    gitlab-ctl restart postgresql

Step 3. 복제 프로세스 시작#

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

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

Warning

pg_basebackup을 실행하기 전에 PostgreSQL의 모든 데이터를 제거하므로, 보조 사이트에서 실행하세요.

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

    sudo -i

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

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

    [!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 문서에서 읽을 수 있습니다. 앞서 나열된 지침은 수동적인 도청자와 활성 "중간자" 공격자 모두에 대한 보호를 보장하기 위해 신중하게 작성되었습니다.

    • 이전 사이트를 Geo 보조 사이트로 재활용하는 경우, 명령줄에 --force를 추가해야 합니다.

    • 프로덕션 머신이 아닌 경우, --skip-backup을 추가하여 백업 단계를 건너뛸 수 있습니다(이것이 원하는 바임이 확실할 때).

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

Note

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

PgBouncer 지원 (선택 사항)#

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

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

복제 비밀번호 변경#

Warning

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

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

GitLab Geo 기본 사이트에서:

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

    원하는 비밀번호의 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>'

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

    sudo gitlab-ctl reconfigure

  • 복제 비밀번호 변경 사항을 적용하려면 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 보조 사이트에서:

  • 첫 번째 단계는 구성 관점에서 꼭 필요하지는 않습니다. 해시된 '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>'

  • 초기 복제 설정 중에 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로 마이그레이션하려면:

그러면 단일 노드가 있는 스탠바이 클러스터가 생성됩니다. 이를 통해 앞서 나열된 동일한 지침을 따라 추가 Patroni 노드를 추가할 수 있습니다.

Patroni 지원#

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

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

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

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

프로덕션 준비 및 안전한 설정에는 최소한 다음이 필요합니다.

  • Consul 노드 3개 (기본 및 보조 사이트)

  • Patroni 노드 2개 (기본 및 보조 사이트)

  • PgBouncer 노드 1개 (기본 및 보조 사이트)

  • 내부 로드 밸런서 1개 (기본 사이트만)

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

비밀번호 자격 증명과 기타 데이터베이스 모범 사례를 사용하세요.

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

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

Note

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

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

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

    sudo -i

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

  • /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

  • 변경 사항을 적용하려면 GitLab을 재구성합니다.

    gitlab-ctl reconfigure

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

    sudo -i

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

  • /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)

  • GitLab을 재구성합니다.

    gitlab-ctl reconfigure

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

    gitlab-ctl restart postgresql

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

    gitlab-psql

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

    select pg_create_physical_replication_slot('geo_secondary')

  • 선택 사항: 기본 사이트에 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;
Step 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

추가 지침은 선호하는 로드 밸런서의 문서를 참조하세요.

Step 3. 보조 사이트에서 PgBouncer 노드 구성#

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

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

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

    sudo -i

  • /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

  • 변경 사항을 적용하려면 GitLab을 재구성합니다.

    gitlab-ctl reconfigure

  • Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 만듭니다. 메시지가 표시되면 PLAIN_TEXT_PGBOUNCER_PASSWORD를 두 번 입력합니다.

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

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

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

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

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

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

    sudo -i

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

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

    [!note] 각 비밀번호 유형은 모든 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를 가리켜야 합니다.

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

    Patroni의 새로운 설치인 경우:

    gitlab-ctl reconfigure

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

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

    gitlab-ctl stop patroni

  • 스탠바이 클러스터를 다시 만들려면 리더 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

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

    gitlab-ctl start patroni

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

    gitlab-ctl patroni members

    다음을 확인하세요.

    현재 Patroni 노드가 출력에 표시됩니다.

    • 권한이 Standby Leader입니다. 처음에는 권한이 Replica로 표시될 수 있습니다.

    • 상태가 Running입니다. 처음에는 상태가 Creating replica로 표시될 수 있습니다.

    노드의 권한이 Standby Leader로 안정되고 상태가 Running이 될 때까지 기다리세요. 몇 분이 걸릴 수 있습니다.

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

    gitlab-ctl start patroni

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

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

    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 추적 데이터베이스 구성을 참조하세요.

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

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

트러블슈팅#

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

Geo 데이터베이스 복제

GitLab v19.2
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이 설치된 새로운 보조 사이트가 준비되어 있습니다.

Note

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

Step 1. 기본 사이트 구성#

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

    sudo -i

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

  • /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>'

  • 변경 사항을 적용하려면 기본 사이트를 재구성합니다.

    gitlab-ctl reconfigure

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

    gitlab-ctl set-geo-primary-node

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

  • 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>'

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

    postgresql['sql_replication_user'] 설정 아래 /etc/gitlab/gitlab.rb에 정의된 사용자 이름을 사용하세요. 기본값은 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>';

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

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

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

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

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

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

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

    ##
## Private address
##
ip route get 255.255.255.255 | awk '{print "Private address:", $NF; 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

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

    ## Disable automatic database migrations
gitlab_rails['auto_migrate'] = false

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

    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 - 복제 문서를 참조하세요.

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

    gitlab-ctl reconfigure

    변경 사항을 적용하려면 PostgreSQL을 재시작합니다.

    gitlab-ctl restart postgresql

  • PostgreSQL이 재시작하고 개인 주소에서 수신 대기하고 있으므로 마이그레이션을 다시 활성화합니다.

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

    gitlab_rails['auto_migrate'] = true

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

    gitlab-ctl reconfigure

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

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

    cat ~gitlab-psql/data/server.crt

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

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

  • 선택 사항: 생성된 인증서 대신 자체 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에 붙여넣으세요.

Step 2. 보조 서버 구성#

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

    sudo -i

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

  • 애플리케이션 서버와 Sidekiq를 중지합니다.

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq

    [!note] 이 단계는 사이트가 완전히 구성되기 전에 아무것도 실행하지 않도록 하는 데 중요합니다.

  • 기본 사이트의 PostgreSQL 서버에 대한 TCP 연결을 확인합니다.

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

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

  • 기본 사이트 설정의 마지막 단계에서 얻은 내용으로 보조 사이트에 server.crt 파일을 만듭니다.

    editor server.crt

  • 보조 사이트에서 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

  • 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 내용과 일치하는지 확인하세요.

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

    ##
## Geo Secondary role
## - configure dependent flags automatically to enable Geo
##
roles(['geo_secondary_role'])

  • PostgreSQL을 구성합니다.

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

    [!note] 각 비밀번호 유형은 모든 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도 제거해야 합니다.

  • 변경 사항을 적용하려면 GitLab을 재구성합니다.

    gitlab-ctl reconfigure

  • IP 변경 사항을 적용하려면 PostgreSQL을 재시작합니다.

    gitlab-ctl restart postgresql

Step 3. 복제 프로세스 시작#

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

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

Warning

pg_basebackup을 실행하기 전에 PostgreSQL의 모든 데이터를 제거하므로, 보조 사이트에서 실행하세요.

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

    sudo -i

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

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

    [!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 문서에서 읽을 수 있습니다. 앞서 나열된 지침은 수동적인 도청자와 활성 "중간자" 공격자 모두에 대한 보호를 보장하기 위해 신중하게 작성되었습니다.

    • 이전 사이트를 Geo 보조 사이트로 재활용하는 경우, 명령줄에 --force를 추가해야 합니다.

    • 프로덕션 머신이 아닌 경우, --skip-backup을 추가하여 백업 단계를 건너뛸 수 있습니다(이것이 원하는 바임이 확실할 때).

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

Note

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

PgBouncer 지원 (선택 사항)#

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

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

복제 비밀번호 변경#

Warning

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

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

GitLab Geo 기본 사이트에서:

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

    원하는 비밀번호의 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>'

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

    sudo gitlab-ctl reconfigure

  • 복제 비밀번호 변경 사항을 적용하려면 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 보조 사이트에서:

  • 첫 번째 단계는 구성 관점에서 꼭 필요하지는 않습니다. 해시된 '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>'

  • 초기 복제 설정 중에 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로 마이그레이션하려면:

그러면 단일 노드가 있는 스탠바이 클러스터가 생성됩니다. 이를 통해 앞서 나열된 동일한 지침을 따라 추가 Patroni 노드를 추가할 수 있습니다.

Patroni 지원#

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

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

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

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

프로덕션 준비 및 안전한 설정에는 최소한 다음이 필요합니다.

  • Consul 노드 3개 (기본 및 보조 사이트)

  • Patroni 노드 2개 (기본 및 보조 사이트)

  • PgBouncer 노드 1개 (기본 및 보조 사이트)

  • 내부 로드 밸런서 1개 (기본 사이트만)

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

비밀번호 자격 증명과 기타 데이터베이스 모범 사례를 사용하세요.

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

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

Note

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

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

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

    sudo -i

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

  • /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

  • 변경 사항을 적용하려면 GitLab을 재구성합니다.

    gitlab-ctl reconfigure

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

    sudo -i

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

  • /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)

  • GitLab을 재구성합니다.

    gitlab-ctl reconfigure

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

    gitlab-ctl restart postgresql

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

    gitlab-psql

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

    select pg_create_physical_replication_slot('geo_secondary')

  • 선택 사항: 기본 사이트에 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;
Step 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

추가 지침은 선호하는 로드 밸런서의 문서를 참조하세요.

Step 3. 보조 사이트에서 PgBouncer 노드 구성#

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

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

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

    sudo -i

  • /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

  • 변경 사항을 적용하려면 GitLab을 재구성합니다.

    gitlab-ctl reconfigure

  • Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 만듭니다. 메시지가 표시되면 PLAIN_TEXT_PGBOUNCER_PASSWORD를 두 번 입력합니다.

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

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

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

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

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

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

    sudo -i

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

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

    [!note] 각 비밀번호 유형은 모든 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를 가리켜야 합니다.

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

    Patroni의 새로운 설치인 경우:

    gitlab-ctl reconfigure

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

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

    gitlab-ctl stop patroni

  • 스탠바이 클러스터를 다시 만들려면 리더 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

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

    gitlab-ctl start patroni

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

    gitlab-ctl patroni members

    다음을 확인하세요.

    현재 Patroni 노드가 출력에 표시됩니다.

    • 권한이 Standby Leader입니다. 처음에는 권한이 Replica로 표시될 수 있습니다.

    • 상태가 Running입니다. 처음에는 상태가 Creating replica로 표시될 수 있습니다.

    노드의 권한이 Standby Leader로 안정되고 상태가 Running이 될 때까지 기다리세요. 몇 분이 걸릴 수 있습니다.

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

    gitlab-ctl start patroni

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

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

    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 추적 데이터베이스 구성을 참조하세요.

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

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

트러블슈팅#

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