Geo 데이터베이스 복제

Tier: Premium, Ultimate Offering: Self-managed

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

note
GitLab 설치에 외부 PostgreSQL 인스턴스(리눅스 패키지 설치로 관리되지 않음)를 사용하는 경우 역할(role)은 모든 필요한 구성 단계를 수행할 수 없습니다. 이 경우 외부 PostgreSQL 인스턴스와 함께 사용하는 Geo 프로세스를 대신 사용하십시오.
note
설치 프로세스의 각 단계는 문서화된 순서대로 완료해야 합니다. 그렇지 않으면 계속하기 전에 이전 단계를 모두 완료해야 합니다.

보조 사이트가 주 사이트와 동일한 GitLab Enterprise Edition 버전을 실행 중인지 확인하십시오. 주 사이트에 Premium 또는 Ultimate 구독 라이선스가 추가되었는지 확인하십시오.

테스트 환경 또는 프로덕션 환경에서 실행하기 전에 이러한 모든 단계를 꼼꼼히 읽고 검토하십시오.

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

단일 인스턴스 데이터베이스 복제는 더 쉽게 설정할 수 있으며 여전히 클러스터링 대체 특성을 제공합니다. 단일 기계에서 실행되거나 미래의 클러스터 설치를 위해 Geo를 평가하는 설정에 유용합니다.

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

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

PostgreSQL 복제

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

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

다음 가이드에서는:

  • Linux 패키지를 사용 중이라고 가정합니다(즉, pg_basebackup 도구를 사용 중).
  • 이미 설정된 주 사이트가 있으며, 리눅스 패키지 설치로 관리되는 PostgreSQL(또는 해당 버전)이 실행 중이며, 모든 사이트에서 같은 PostgreSQL 버전, OS 및 GitLab을 사용 중이라고 가정합니다.
caution
Geo는 스트리밍 복제와 함께 작동합니다. 논리적 복제는 현재 지원되지 않습니다. 지원이 논의 중인 이슈가 있습니다.

단계 1. 주 사이트 구성

  1. GitLab 주 사이트에 SSH로 로그인한 후 root로 로그인합니다: 

    sudo -i

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

    ##
## Geo 사이트의 고유 식별자. 자세한 내용은
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings 를 참조하십시오.
##
gitlab_rails['geo_node_name'] = '<사이트_이름_여기에_입력>'

  3. 변경 사항이 적용되려면 주 사이트를 재구성하십시오: 

    gitlab-ctl reconfigure

  4. 아래 명령을 실행하여 사이트를 주 사이트로 정의하십시오: 

    gitlab-ctl set-geo-primary-node

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

  5. gitlab 데이터베이스 사용자의 암호를 정의하십시오: 원하는 암호의 MD5 해시를 생성하십시오: 

    gitlab-ctl pg-password-md5 gitlab
# 암호 입력: <여기에_암호_입력>
# 암호 확인: <여기에_암호_입력>
# fca0b89a972d69f00eb3ec98a5838484

    /etc/gitlab/gitlab.rb를 편집하십시오: 

    # `gitlab-ctl pg-password-md5 gitlab` 명령으로 생성된 해시로 채우십시오
postgresql['sql_user_password'] = '<암호의_md5_해시>'
   
# Puma 또는 Sidekiq를 실행하는 모든 노드에 아래와 같이 데이터베이스 암호를 지정해야 합니다.
# 고가용성 설정이 있는 경우 이것은 모든 애플리케이션 노드에서 있어야 합니다.
gitlab_rails['db_password'] = '<여기에_암호_입력>'

  6. 데이터베이스 복제 사용자에 대한 암호를 정의하십시오: /etc/gitlab/gitlab.rb에서 postgresql['sql_replication_user'] 하위 설정에 정의된 사용자 이름을 사용하십시오. 기본값은 gitlab_replicator입니다. 사용자 이름을 다른 값으로 변경했다면 아래 지침에 적절하게 수정하십시오. 원하는 암호의 MD5 해시를 생성하십시오: 

    gitlab-ctl pg-password-md5 gitlab_replicator
# 암호 입력: <여기에_암호_입력>
# 암호 확인: <여기에_암호_입력>
# 950233c0dfc2f39c64cf30457c3b7f1e

    /etc/gitlab/gitlab.rb를 편집하십시오: 

    # `gitlab-ctl pg-password-md5 gitlab_replicator` 명령으로 생성된 해시로 채우십시오
postgresql['sql_replication_password'] = '<암호의_md5_해시>'

    리눅스 패키지 설치로 관리되지 않는 외부 데이터베이스를 사용하는 경우 gitlab_replicator 사용자를 만들고 해당 사용자에 대한 암호를 매뉴얼으로 정의해야 합니다: 

    --- 'replicator'라는 새로운 사용자 생성
CREATE USER gitlab_replicator;
   
--- 암호 설정 및 복제 권한 부여
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<복제_암호>';

  7. /etc/gitlab/gitlab.rb를 편집하고 geo_primary_role 역할을 설정하십시오(자세한 내용은 Geo roles 참조): 

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

  8. 네트워크 인터페이스에서 PostgreSQL을 수신하도록 구성하십시오: 보안상의 이유로 PostgreSQL은 기본적으로 어떤 네트워크 인터페이스에도 수신하지 않습니다. 그러나 Geo에는 보조 사이트가 주 사이트의 데이터베이스에 연결해야 하므로 각 사이트의 IP 주소가 필요합니다.

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

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

    Geo 사이트의 주소를 확인하려면 Geo 사이트에 SSH로 로그인하고 다음을 실행하십시오: 

    ##
## 개인 주소
##
ip route get 255.255.255.255 | awk '{print "개인 주소:", $NF; exit}'
   
##
## 공용 주소
##
echo "외부 주소: $(curl --silent "ipinfo.io/ip")"

    대부분의 경우, 다음과 같은 주소를 사용하여 GitLab Geo를 구성합니다:

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

    Google Cloud Platform, SoftLayer 또는 기타 VPC를 제공하는 공급업체를 사용하는 경우 postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에 대해 주 및 보조 사이트의 “개인” 또는 “내부” 주소를 사용하는 것이 좋습니다.

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

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

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

    /etc/gitlab/gitlab.rb를 편집하고 아래 내용을 추가하십시오. IP 주소를 해당 네트워크 구성에 적합한 주소로 대체하십시오: 

    ##
## 주요 주소
## - '<주_사이트_공인_IP>'를 Geo 주요 노드의 공용 또는 VPC 주소로 대체하십시오
##
postgresql['listen_address'] = '주_사이트_IP'
   
##
# PostgreSQL 클라이언트의 인증을 주요 및 보조 IP로 부터 허용합니다. 이 IP들은 CIDR 형식의 공용 또는 VPC 주소일 수 있습니다. 예를 들어 ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['주_사이트_IP/32', '보조_사이트_IP/32']
   
##
## 복제 설정
##
# postgresql['max_replication_slots'] = 1 # 여러 개의 Geo 보조 노드가 있는 경우 해당 수로 설정합니다
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

  9. PostgreSQL이 개인 주소에서 수신 및 복제 슬롯 변경을 위해 GitLab 재구성하십시오. 파일을 저장하고 재구성하고 PostgreSQL을 재시작하여 변경 내용이 적용되도록 하십시오: 

    gitlab-ctl reconfigure
gitlab-ctl restart postgresql

  10. PostgreSQL 서버가 원격 연결을 수신하도록 설정되었으므로 PostgreSQL이 5432 포트에서 수신 중인지 확인하기 위해 netstat -plnt | grep 5432를 실행하십시오.

  11. 인증서는 GitLab을 재구성할 때 자동으로 생성됩니다. 이는 PostgreSQL 트래픽을 도청자로부터 보호하는 데 자동으로 사용됩니다. MitM(중간자 공격)에 대한 보호를 위해 보조 사이트에는 인증서의 사본이 필요합니다. 다음 명령을 실행하여 주 사이트의 PostgreSQL server.crt 파일의 사본을 만드십시오: 

    cat ~gitlab-psql/data/server.crt

    출력 내용을 클립보드에 복사하거나 로컬 파일에 붙여넣기합니다. 인증서는 민감한 데이터가 아닙니다.

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

  12. 선택 사항입니다. 직접 SSL을 생성하고 PostgreSQL을 위해 SSL 구성하는 대신 생성된 인증서를 사용할 수 있습니다. SSL 인증서 및 키가 필요합니다. postgresql['ssl_cert_file'] 및 postgresql['ssl_key_file'] 값을 Database SSL 문서대로 전체 경로로 설정하십시오.

    이렇게 하면 verify-full SSL 모드를 사용하여 데이터베이스를 복제할 수 있으며 CN에서 호스트 이름을 완전히 검증하는 추가 혜택

단계 2. 보조 서버 구성

  1. GitLab 보조 사이트로 SSH를 하고 root로 로그인합니다. 

    sudo -i

  2. 응용 프로그램 서버 및 Sidekiq를 중지합니다. 

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq
    note
    이 단계는 사이트가 완전히 구성되기 전에 아무것도 실행하지 않도록 중요합니다.

  3. 주 사이트의 PostgreSQL 서버로의 TCP 연결을 확인하세요. 

    gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]
    note
    이 단계가 실패하는 경우 잘못된 IP 주소를 사용하거나 방화벽이 사이트 접근을 막고 있을 수 있습니다. 공용 및 사설 주소 간 차이에 주의하십시오. 방화벽이 있는 경우 보조 사이트가 5432 포트에서 주 사이트에 연결할 수 있도록 허용되었는지 확인합니다.

  4. 보조 사이트에 server.crt라는 파일을 만들어 마지막 단계에서 주 사이트의 설정에서 얻은 내용을 넣습니다. 

    editor server.crt

  5. 보조 사이트에서 PostgreSQL TLS 확인 설정:

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

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

    PostgreSQL은 이제 TLS 연결 검증 시 해당 정확한 인증서만 인식합니다. 해당 인증서는 주 사이트에만 있는 개인 키가 있는 사람에 의해 복제될 수 있습니다.

  6. gitlab-psql 사용자가 주 사이트의 데이터베이스에 연결할 수 있는지 테스트합니다 (리눅스 패키지 설치의 경우 기본 데이터베이스 이름은 gitlabhq_production입니다). 

    sudo \
   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
   --list \
   -U gitlab_replicator \
   -d "dbname=gitlabhq_production sslmode=verify-ca" \
   -W \
   -h <primary_site_ip>
    note
    매뉴얼으로 생성한 인증서를 사용하고 전체 호스트 이름 확인을 위해 sslmode=verify-full을 사용하려는 경우, 해당 명령을 실행할 때 verify-ca를 verify-full로 바꿉니다.

    암호를 입력하라는 프롬프트가 표시되면 첫 번째 단계에서 gitlab_replicator 사용자를 위해 설정한 평문 암호를 입력합니다. 모든 것이 올바르게 작동했다면 주 사이트의 데이터베이스 디렉터리이 표시됩니다.

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

  7. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_secondary_role로 설정합니다 (Geo 역할에 대한 자세한 내용은 여기를 참조하세요). 

    ##
## Geo 보조 역할
## - 종속 플래그를 자동으로 설정하여 Geo를 활성화합니다.
##
roles(['geo_secondary_role'])

  8. PostgreSQL 구성:

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

    /etc/gitlab/gitlab.rb를 편집하고 다음을 추가하여 IP 주소에 적합한 주소로 바꿉니다. 

    ##
## 보조 주소
## - '<secondary_site_ip>'를 Geo 보조 사이트의 공용 또는 VPC 주소로 대체합니다.
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']
   
##
## 데이터베이스 자격 증명 비밀번호 (이전에 주 사이트에서 정의함)
## - 주 사이트에서 정의한 것과 동일한 값을 여기에 복제합니다.
##
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
gitlab_rails['db_password'] = '<your_password_here>'

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

  9. 변경 사항이 적용되도록 GitLab을 다시 구성합니다. 

    gitlab-ctl reconfigure

  10. IP 변경이 적용되도록 PostgreSQL을 다시 시작합니다. 

    gitlab-ctl restart postgresql

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

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

사용된 디렉터리는 리눅스 패키지 설치 시 설정된 기본값입니다. 기본값을 변경했다면 스크립트를 그에 맞게 구성하세요(디렉터리 및 경로 교체).

caution
pg_basebackup을 실행하기 전에 여기서 실행하십시오. 보조 사이트에서 실행하지 않도록 주의하십시오. 모든 PostgreSQL 데이터를 제거합니다.

  1. GitLab 보조 사이트로 SSH를 하고 root로 로그인합니다. 

    sudo -i

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

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

    caution
    각 Geo 보조 사이트는 고유한 복제 슬롯 이름을 가져야 합니다. 두 개의 보조 사이트 사이에 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 중단됩니다.
    note
    복제 슬롯 이름은 소문자, 숫자 및 밑줄 문자만 포함해야 합니다.

    프롬프트에서 첫 번째 단계에서 gitlab_replicator 사용자를 위해 설정한 평문 암호를 입력합니다. 

    gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca
    note
    사용자 지정 PostgreSQL 인증서를 생성한 경우 추가 보안을 위해 --sslmode=verify-full을 사용하거나 (또는 sslmode 줄 전체를 생략)하여 추가 보안을 위해 인증서의 전체 호스트 이름 확인을 이용합니다. 그렇지 않으면 verify-full을 사용하여 자동으로 생성된 인증서를 사용하려고 하면 실패합니다. 이는 이 명령어에 있는 --host 값과 일치하지 않는 일반적인 PostgreSQL CN을 가지고 있기 때문입니다.

    이 명령에는 여러 가지 추가 옵션이 있습니다. 모두 나열하려면 --help를 사용할 수 있지만, 여기 몇 가지 팁이 있습니다:

    • PostgreSQL이 비표준 포트에서 듣고 있는 경우 --port=를 추가합니다.
    • 데이터베이스가 30분 내에 전송할 수 없을 정도로 크다면 타임아웃을 늘려야 합니다. 예를 들어, 초기 복제에 1시간 이내 소요 예상이면 --backup-timeout=3600을 사용합니다.
    • PostgreSQL TLS 인증을 완전히 건너뛰려면 --sslmode=disable을 전달하세요(예를 들어, 네트워크 경로가 안전하다고 알고 있는 경우 또는 site-to-site VPN을 사용하는 경우). 이 방법은 공용 인터넷에서는 안전하지 않습니다!
    • 각 sslmode에 대한 자세한 정보는 PostgreSQL 문서를 참조하십시오. 위의 지침은 매뉴얼 도청자 및 적극적인 “중간자” 공격자에 대한 보호를 보장하도록 주의 깊게 작성되었습니다.
    • --slot-name을 주 데이터베이스에서 사용할 복제 슬롯 이름으로 변경합니다. 스크립트는 해당 복제 슬롯이 없는 경우 자동으로 생성하려고 시도합니다.
    • 이전 사이트를 Geo 보조 사이트로 다시 사용하려면 명령줄에 --force를 추가해야 합니다.
    • 프로덕션 머신이 아닌 경우 백업 단계를 비활성화하려면(원하는대로 확실한 경우) --skip-backup을 추가합니다.
    • PgBouncer를 사용 중인 경우 데이터베이스 호스트에 직접 대상을 지정해야 합니다.
    • 주 사이트에서 Patroni를 사용 중인 경우 현재 리더 호스트를 대상으로 지정해야 합니다.
    • 로드 밸런서 프록시(예: HAProxy)를 사용 중이고 주 사이트의 Patroni 리더를 대상으로 지정하는 경우 로드 밸런서 프록시를 대상으로 지정해야 합니다.

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

PgBouncer 지원 (옵션)

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

primary 사이트와 Geosupport를 하는 노드 클러스터, secondary 사이트를 지원하는 다른 두 개의 노드 클러스터를 가진 고가용성 구성에서 GitLab을 사용한다면 PgBouncer를 사용해야 합니다. 주요 데이터베이스와 추적 데이터베이스 각각에 PgBouncer 노드를 두 개 필요합니다. 더 많은 정보는 관련 문서를 참조하세요.

복제 비밀번호 변경

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

GitLab Geo primary 사이트에서:

  1. 복제 사용자의 기본값은 gitlab_replicator이지만, /etc/gitlab/gitlab.rb에서 postgresql['sql_replication_user'] 설정 아래에서 사용자를 직접 설정했다면, 다음 지침을 사용자에 맞도록 수정하세요.

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

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

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

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

  2. 파일을 저장하고 복제 사용자의 비밀번호를 PostgreSQL에서 변경하도록 GitLab을 다시 구성하세요: 

    sudo gitlab-ctl reconfigure

  3. 복제 비밀번호 변경이 적용되려면 PostgreSQL을 다시 시작하세요: 

    sudo gitlab-ctl restart postgresql

secondary 사이트에서 비밀번호가 업데이트되기 전까지, 두 번째 위치의 PostgreSQL 로그에 다음과 같은 오류 메시지가 표시됩니다: 

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

GitLab Geo secondary 사이트에서:

  1. 구성 관점에서 첫 번째 단계는 필요하지 않으며, 해시 처리된 'sql_replication_password'는 secondary 사이트에서 사용되지 않습니다. 그러나 secondary 사이트가 GitLab Geo primary으로 승격되어야 하는 경우를 대비하여 secondary 사이트 구성에서 'sql_replication_password'를 일치시켜야 합니다.

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

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

  2. 초기 복제 설정 중, gitlab-ctl replicate-geo-database 명령은 복제 사용자 계정의 평문 비밀번호를 두 군데에 작성합니다:

    • gitlab-geo.conf: PostgreSQL 복제 프로세스에서 사용되며, 기본적으로 /var/opt/gitlab/postgresql/data/gitlab-geo.conf에 작성됩니다.
    • .pgpass: gitlab-psql 사용자에서 사용되며, 기본적으로 /var/opt/gitlab/postgresql/.pgpass에 위치합니다.

    이 두 파일의 평문 비밀번호를 업데이트하고, PostgreSQL을 재시작하세요: 

    sudo gitlab-ctl restart postgresql

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

GitLab 14.0에서 repmgr을 지원하는 고가용성 PostgreSQL 솔루션으로서 Patroni가 대체되었습니다.

note
아직 repmgr에서 Patroni로 마이그레이션하지 않았다면 이를 권장합니다.

repmgr에서 Patroni로 마이그레이션

  1. 마이그레이션 전에 primary와 secondary 사이트 간의 복제 지연이 없고 복제가 일시 중지되어 있는지 확인해야 합니다. GitLab 13.2 이후로 Geo secondary 데이터베이스 노드에서 gitlab-ctl geo-replication-pause 및 gitlab-ctl geo-replication-resume을 사용하여 복제를 일시 중지 및 재개할 수 있습니다.
  2. repmgr에서 Patroni로 마이그레이션 지침을 따르세요. 각 primary 사이트 데이터베이스 노드에서 Patroni를 구성할 때, patroni['replication_slots'] = { '<slot_name>' => 'physical' }를 gitlab.rb에 추가하여 secondary 사이트의 복제 슬롯의 이름을 지정하세요. 이로써 Patroni가 복제 슬롯을 영구적으로 인식하고 다시 시작할 때 삭제하지 않도록 보장합니다.
  3. 마이그레이션 전에 secondary 사이트로의 데이터베이스 복제가 일시 중지된 경우, Patroni가 primary 사이트에서 작동하는 것이 확인된 후 복제를 다시 시작하세요.

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

Patroni가 도입되기 전에 Geo는 secondary 사이트에 대한 HA 설정용 Linux 패키지 설치를 지원하지 않았습니다.

Patroni를 사용하면 이제 이러한 서포트가 가능합니다. 기존 PostgreSQL을 Patroni로 마이그레이션하려면:

  1. primary 사이트와 유사한 방식으로 secondary에 Consul 클러스터가 설정되어 있는지 확인하세요.
  2. 영구 복제 슬롯 구성.
  3. 내부 로드 밸런서 구성.
  4. PgBouncer 노드 구성.
  5. 스탠바이 클러스터 구성 단일 노드 머신에서.

이로써 단일 노드에 _스탠바이 클러스터_가 생성됩니다. 이를 통해 동일한 지침을 따라 추가 Patroni 노드를 추가할 수 있습니다.

Patroni 지원

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

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

Geo 보조 사이트용 Patroni 클러스터 구성

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

Geo 기본 사이트에서 repmgr을 사용하는 경우 repmgr에서 Patroni로 이관하는 방법에 대해서는 이 지침을 참조하세요.

프로덕션 준비 및 안전한 설정은 적어도 다음을 필요로 합니다:

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

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

암호 자격 증명 및 기타 데이터베이스 모범 사례를 사용하세요.

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

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

기본 사이트의 Patroni 인스턴스를 실행 중인 각 노드에서 다음을 시작하여 root로 로그인합니다:

  1. Patroni 리더 인스턴스부터 다음과 같이 Patroni 인스턴스에 SSH로 로그인합니다: 

    sudo -i

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

    roles(['patroni_role'])
   
consul['services'] = %w(postgresql)
consul['configuration'] = {
  retry_join: %w[CONSUL_PRIMARY1_IP CONSUL_PRIMARY2_IP CONSUL_PRIMARY3_IP]
}
   
# 각 보조 사이트에 대한 항목마다 고유한 이름을 사용하여 다음과 같이 구성합니다. 해당 이름은 PostgreSQL slot_name 제약 조건을 따릅니다:
#
# 구성 구문: 'unique_slotname' => { 'type' => 'physical' },
# 논리적 복제 유형에 대한 영구 복제 슬롯 설정은 지원하지 않습니다
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}
   
patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # Patroni/예약된 슬롯의 수의 2배(3개 Patroni + 1개 Geo 보조용 예약된 슬롯)
patroni['postgresql']['max_replication_slots'] = 8 # Patroni/예약된 슬롯의 수의 2배(3개 Patroni + 1개 Geo 보조용 예약된 슬롯)
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = '평문_POSTGRESQL_복제_비밀번호'
   
# 허용 디렉터리에 모든 patroni 노드를 추가합니다
patroni['allowlist'] = %w[
  127.0.0.1/32
  PATRONI_PRIMARY1_IP/32 PATRONI_PRIMARY2_IP/32 PATRONI_PRIMARY3_IP/32
  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32
]
   
# 모든 보조 인스턴스를 나열하므로 모두 Standby 리더가 될 수 있습니다
postgresql['md5_auth_cidr_addresses'] = %w[
  PATRONI_PRIMARY1_IP/32 PATRONI_PRIMARY2_IP/32 PATRONI_PRIMARY3_IP/32 PATRONI_PRIMARY_PGBOUNCER/32
  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32 PATRONI_SECONDARY_PGBOUNCER/32
]
   
postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
postgresql['sql_replication_password'] = 'POSTGRESQL_REPLICATION_PASSWORD_HASH'
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
postgresql['listen_address'] = '0.0.0.0' # 여기에 공용 또는 VPC 주소를 사용할 수 있습니다

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

    gitlab-ctl reconfigure
단계 2. 기본 사이트에 내부 로드 밸런서 구성

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

Linux 패키지에는 로드 밸런서가 포함되어 있지 않습니다. 다음은 HAProxy로 수행하는 방법입니다.

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

  • 10.6.0.21: Patroni 1 (patroni1.internal)
  • 10.6.0.22: Patroni 2 (patroni2.internal)
  • 10.6.0.23: Patroni 3 (patroni3.internal) 
global
    log /dev/log local0
    log localhost local1 notice
    log stdout format raw local0

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

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

backend postgresql
    option httpchk
    http-check expect status 200
    
    server patroni1.internal 10.6.0.21:5432 maxconn 100 check port 8008
    server patroni2.internal 10.6.0.22:5432 maxconn 100 check port 8008
    server patroni3.internal 10.6.0.23:5432 maxconn 100 check port 8008

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

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

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

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

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

    sudo -i

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

    # Pgbouncer 및 Consul 에이전트를 제외한 모든 컴포넌트 비활성화
roles(['pgbouncer_role'])
   
# PgBouncer 구성
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
'gitlab-consul': {
   # 이 명령으로 생성: `gitlab-ctl pg-password-md5 gitlab-consul`
   password: 'GITLAB_CONSUL_PASSWORD_HASH'
 },
  'pgbouncer': {
    # 이 명령으로 생성: `gitlab-ctl pg-password-md5 pgbouncer`
    password: 'PGBOUNCER_PASSWORD_HASH'
  }
}
   
# Consul 구성
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
  retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
}
consul['monitoring_service_discovery'] =  true

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

    gitlab-ctl reconfigure

  4. Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 생성합니다. 물어볼 때 PLAIN_TEXT_PGBOUNCER_PASSWORD 두 번 입력합니다: 

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

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

    gitlab-ctl hup pgbouncer
단계 4. 보조 사이트에 대기 클러스터 구성
note
단일 PostgreSQL 인스턴스를 Patroni 클러스터로 변환하는 경우, 먼저 PostgreSQL 인스턴스에서 시작해야 합니다. 이것은 Patroni 대기 리더 인스턴스가 되며, 그 후 필요한 경우 다른 레플리카로 전환할 수 있습니다.

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

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

    sudo -i

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

    roles(['consul_role', 'patroni_role'])
   
consul['enable'] = true
consul['configuration'] = {
  retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
}
consul['services'] = %w(postgresql)
   
postgresql['md5_auth_cidr_addresses'] = [
  'PATRONI_SECONDARY1_IP/32', 'PATRONI_SECONDARY2_IP/32', 'PATRONI_SECONDARY3_IP/32', 'PATRONI_SECONDARY_PGBOUNCER/32',
  # 문서대로 데이터베이스에 액세스해야 하는 다른 인스턴스
]
   
# patroni 노드를 허용 디렉터리에 추가
patroni['allowlist'] = %w[
  127.0.0.1/32
  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32
]
   
patroni['standby_cluster']['enable'] = true
patroni['standby_cluster']['host'] = 'INTERNAL_LOAD_BALANCER_PRIMARY_IP'
patroni['standby_cluster']['port'] = INTERNAL_LOAD_BALANCER_PRIMARY_PORT
patroni['standby_cluster']['primary_slot_name'] = 'geo_secondary' # 또는 이전에 설정한 고유한 복제 슬롯 이름
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'
patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 5 # 하나의 레플리카당 최소 3개, 추가 레플리카당 2개
patroni['postgresql']['max_replication_slots'] = 5 # 하나의 레플리카당 최소 3개, 추가 레플리카당 2개
   
postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
postgresql['sql_replication_password'] = 'POSTGRESQL_REPLICATION_PASSWORD_HASH'
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
postgresql['listen_address'] = '0.0.0.0' # 여기에는 공용 또는 VPC 주소를 사용할 수 있습니다.
   
gitlab_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는 주 사이트에서 내부 로드 밸런서 구성에 맞게 프론트엔드 포트를 가리켜야 합니다. PgBouncer 프론트엔드 포트를 사용하지 않습니다.

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

    • Patroni를 처음 설치하는 경우: 

      gitlab-ctl reconfigure

    • 이전에 작동하던 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
gitlab-ctl start patroni

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

Patroni가 도입되기 전에 Geo는 HA 설정에 대한 Linux 패키지 설치를 지원하지 않았습니다.

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

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

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

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

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

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

문제 해결

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