Geo 데이터베이스 복제

Tier: Premium, Ultimate Offering: Self-Managed

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

note
GitLab 설치에 외부 PostgreSQL 인스턴스(리눅스 패키지 설치로 관리되지 않음)가 사용된다면 역할은 모든 필요한 구성 단계를 수행할 수 없습니다. 이 경우 외부 PostgreSQL 인스턴스를 사용하는 Geo 프로세스를 대신 사용하십시오.
note
설정 프로세스의 단계는 문서화된 순서대로 완료해야 합니다. 그렇지 않으면 직전 단계를 모두 완료한 후 진행해야 합니다(../setup/index.md#using-linux-package-installations).

주의:
Secondary 사이트가 primary 사이트와 동일한 GitLab Enterprise Edition 버전을 실행중인지 확인하세요. Primary 사이트에 Premium 또는 Ultimate 가입 라이선스가 추가되었는지 확인하세요.

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

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

단일 인스턴스 데이터베이스 복제는 설정이 쉽고, 클러스터형 대안과 동일한 Geo 기능을 제공합니다. 단일 컴퓨터에서 실행되는 설정이나 나중에 클러스터 설치를 위해 Geo를 평가하는 경우 유용합니다.

단일 인스턴스는 Patroni를 사용하여 고가용성 아키텍처에 권장됩니다. 클러스터링된 설치로 PostgreSQL 복제를 설정하는 방법은 아래 지침에 따릅니다. 또한, 다중 노드 데이터베이스 복제 지침을 참조하여 Patroni 클러스터를 사용하여 복제를 설정할 수 있습니다.

PostgreSQL 복제

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

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

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

  • Linux 패키지를 사용하고 있으며 (따라서 PostgreSQL 12 이상을 사용 중임) 이 패키지에는 pg_basebackup 도구가 포함되어 있습니다.
  • Primary 사이트가 이미 설정되어 있으며 PostgreSQL(또는 해당 버전)을 리눅스 패키지 설치로 관리하고 있으며, 모든 사이트에서 동일한 PostgreSQL 버전, OS 및 GitLab을 실행 중입니다.

경고:
Geo는 스트리밍 복제시 작동합니다. 논리적 복제는 현재 지원되지 않습니다. 논의 중인 지원 문제가 있습니다.

단계 1. Primary 사이트 구성

  1. GitLab primary 사이트에 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'] = '<site_name_here>'

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

    gitlab-ctl reconfigure

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

    gitlab-ctl set-geo-primary-node

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

  5. gitlab 데이터베이스 사용자의 암호를 정의하십시오:

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

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

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

    # `gitlab-ctl pg-password-md5 gitlab`로 생성된 해시로 채웁니다
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
   
# Puma 또는 Sidekiy를 실행하는 모든 노드는 아래와 같이 데이터베이스 암호를 지정해야 합니다. 고가용성 설정이 있는 경우 이 값은 모든 애플리케이션 노드에 있어야 합니다.
gitlab_rails['db_password'] = '<your_db_password_here>'

  6. 복제 사용자 데이터베이스 암호를 정의하십시오.

    /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

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

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

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

  7. /etc/gitlab/gitlab.rb를 편집하여 역할을 geo_primary_role로 설정하십시오(Geo 역할을 참조): 

    ## Geo Primary 역할
roles(['geo_primary_role'])

  8. PostgreSQL이 네트워크 인터페이스에서 수신 대기하도록 구성하십시오:

    보안상의 이유로 PostgreSQL은 기본적으로 모든 네트워크 인터페이스에서 수신 대기하지 않습니다. 그러나 Geo는 secondary 사이트가 primary 사이트의 데이터베이스에 연결할 수 있어야합니다. 이로 인해 각 사이트의 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'] Primary 사이트의 공용 또는 VPC 사설 주소
    postgresql['md5_auth_cidr_addresses'] Primary 사이트 및 Secondary 사이트의 공용 또는 VPC 사설 주소

    Google Cloud Platform, SoftLayer 또는 기타 가상 사설망(VPC)을 제공하는 공급업체를 사용하는 경우 postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에 primary 및 secondary 사이트의 “비공개/내부” 주소를 사용하는 것이 좋습니다.

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

    note
    0.0.0.0 또는 *를 listen_address로 사용해야하는 경우 postgresql['md5_auth_cidr_addresses'] 설정에 127.0.0.1/32를 추가하여 127.0.0.1을 통한 Rails 접속을 허용해야합니다. 자세한 내용은 issue 5258을 참조하십시오.

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

    아래의 내용을 각 사이트의 네트워크 구성에 적합한 주소로 변경하여 /etc/gitlab/gitlab.rb를 편집하십시오: 

    ##
## Primary 주소
## - '<primary_node_ip>'를 사용하는 Geo primary 노드의 공용 또는 VPC 주소로 대체합니다
##
postgresql['listen_address'] = '<primary_site_ip>'
   
##
# PostgreSQL 클라이언트가 primary 및 secondary IP에서 인증할 수 있도록 허용합니다. 이 IP는 예를 들어 CIDR 형식의 공용 또는 VPC 주소인 ['198.51.100.1/32', '198.51.100.2/32']일 수 있습니다
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
   
##
## 복제 설정
##
# postgresql['max_replication_slots'] = 1 # 여러 개 이상의 Geo secondary 노드가 있다면 해당 숫자를 설정하십시오
# postgresql['max_wal_senders'] = 10
# postgresql['wal_keep_segments'] = 10

  9. PostgreSQL이 사설 주소에서 듣도록 변경된 데이터베이스 리슨 및 복제 슬롯 변경 내용이 적용되도록 /etc/gitlab/gitlab.rb를 저장하고 GitLab을 다시 구성하십시오: 

    gitlab-ctl reconfigure

    변경 내용이 실행되도록 PostgreSQL을 다시 시작하십시오: 

    gitlab-ctl restart postgresql

  10. PostgreSQL 서버가 원격 연결을 수락하도록 설정되어 있으므로 netstat -plnt | grep 5432를 실행하여 PostgreSQL이 primary 사이트의 사설 주소에서 포트 5432에서 수신 대기하는지 확인하십시오.

  11. GitLab을 다시 구성할 때 자동으로 인증을 생성합니다. 이는 조회 도중의 데이터 손실을 방지하기 위해 PostgreSQL 트래픽을 자동으로 보호하기 위해 자동으로 사용됩니다. 그러나 Secondary 사이트는 해당 인증서의 사본이 필요합니다. Primary 사이트의 PostgreSQL server.crt 파일을 실행하여 복사합니다(위 명령을 사용하여). 복사본을 클립보드에 복사하거나 로컬 파일에 붙여넣기하십시오. 해당 인증서는 민감한 데이터가 아닙니다.

    그러나이 인증서는 일반적인 PostgreSQL 공용 이름(CN)으로 만들어졌습니다. 따라서 복제 시 verify-ca 모드를 사용해야합니다. 그렇지 않으면 호스트 이름 불일치로 오류가 발생합니다.

  12. 선택 사항. SSL 인증서를 직접 생성하고 PostgreSQL을 위해 SSL을 매뉴얼으로 구성하는 대신 생성된 인증서를 사용하십시오.

    적어도 SSL 인증서 및 키가 필요합니다. postgresql['ssl_cert_file'] 및 postgresql['ssl_key_file'] 값을 데이터베이스 SSL 문서에 따라 전체 경로로 설정하십시오.

    이를 통해 데이터베이스 복제 용으로 verify-full SSL 모드를 사용하고 CN과 일치하는지 여부를 확인하는 추가 혜택을 얻을 수 있습니다.

    CN이 일치하는 경우 복제 오류 없이 verify-full SSL 모드를 사용할 수 있도록 앞서 설정한 인증서(사용 정보postgresql['ssl_cert_file'])를 계속 사용할 수 있습니다.

단계 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 사용자가 기본 사이트의 데이터베이스에 연결할 수 있는지 테스트합니다 (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의 내용과 일치하는지 확인하세요.

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

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

  8. PostgreSQL 구성:

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

    /etc/gitlab/gitlab.rb를 편집하고 아래 내용을 추가하고, IP 주소를 네트워크 구성에 적합한 주소로 변경하세요: 

    ##
## Secondary address
## - '<secondary_site_ip>'를 Geo 보조 사이트의 공용 또는 VPC 주소로 교체하세요
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']
   
##
## Database credentials password (defined previously 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를 제거해야 합니다.

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

    gitlab-ctl reconfigure

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

    gitlab-ctl restart postgresql

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

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

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

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을 사용하는 사용자가 자동으로 생성된 인증서를 사용하면 명령이 실패합니다. 이 명령에는 여러 가지 추가 옵션이 있습니다. 모든 옵션을 보려면 --help를 사용하세요. 몇 가지 팁은 다음과 같습니다: - PostgreSQL이 비표준 포트에서 청취하는 경우, --port=를 추가하세요. - 데이터베이스가 30분 이내에 전송할 수 없을 정도로 크다면 타임아웃을 증가해야 합니다. 초기 복제에 1시간 이내로 완료될 것으로 예상되면 --backup-timeout=3600을 사용하세요. - PostgreSQL TLS 인증을 완전히 건너뛰려면 --sslmode=disable을 전달하세요 (예: 네트워크 경로가 안전하다고 알고 있는 경우 또는 site-to-site VPN을 사용하는 경우). 이는 공용 인터넷상에서 안전하지 않습니다! - PostgreSQL 문서에서 각 sslmode에 대해 자세히 읽을 수 있습니다. 위의 지침은 매뉴얼으로 스니핑하는 자 또는 적극적인 “중간자” 공격자에 대응하여 보호를 보장하도록 신중하게 작성되었습니다. - 보조 사이트로 구현을 맞추고자 한다면, 명령행에 --force를 추가해야 합니다. - 복구 단계를 비활성화하려고 하며, 제품용 머신이 아닌 경우, --skip-backup을 추가합니다. - PgBouncer를 사용 중이면 데이터베이스 호스트를 직접 타겟으로 지정해야 합니다. - 기본 사이트에서 Patroni를 사용 중이라면 현재 리더 호스트를 타겟으로 정해야 합니다. - 로드 밸런서 프록시(예: HAProxy)를 사용 중이며 이것이 기본 사이트의 Patroni 리더를 타겟팅하고 있다면, 로드 밸런서 프록시를 대상으로 정해야 합니다.

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

PgBouncer 지원 (옵션)

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

당신이 Geo primary 사이트를 지원하는 노드 클러스터와 Geo 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
# 비밀번호 입력: <여기에_복제_비밀번호_입력>
# 비밀번호 확인: <여기에_복제_비밀번호_입력>
# 950233c0dfc2f39c64cf30457c3b7f1e

    /etc/gitlab/gitlab.rb를 수정하세요: 

    # `gitlab-ctl pg-password-md5 gitlab_replicator`로 생성된 해시로 채웁니다.
postgresql['sql_replication_password'] = '<귀하의_복제_비밀번호의_md5_해시>'

  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`로 생성된 해시로 채웁니다.
postgresql['sql_replication_password'] = '<귀하의_복제_비밀번호의_md5_해시>'

  2. 초기 복제 설정 중에 gitlab-ctl replicate-geo-database 명령어는 복제 유저 계정의 평문 비밀번호를 두 곳에 작성합니다:

    • gitlab-geo.conf: 기본적으로 PostgreSQL 데이터 디렉터리에 있는, /var/opt/gitlab/postgresql/data/gitlab-geo.conf에 작성되는 PostgreSQL 복제 프로세스에서 사용됩니다.
    • .pgpass: 기본적으로 /var/opt/gitlab/postgresql/.pgpass에 위치하는 gitlab-psql 사용자에서 사용됩니다.

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

    sudo gitlab-ctl restart postgresql

Multi-node 데이터베이스 복제

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

Patroni가 도입되기 전에 Geo는 secondary 사이트에서 HA 설정을 위한 리눅스 패키지 설치를 지원하지 않았습니다.

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

  1. secondary 사이트에서 HA 설정을 위해 설치하는 것과 유사하게, secondary 사이트에 Consul 클러스터를 설정해야 합니다.
  2. 영구적 복제 슬롯 구성하기
  3. 내부 로드 밸런서 구성하기
  4. PgBouncer 노드 구성하기
  5. 단일 노드 기계에서 Standby 클러스터 구성하기

이러한 지침을 따르면 단일 노드를 사용하는 _Standby 클러스터_가 생성됩니다. 이를 통해 위의 지침을 따라 추가적인 Patroni 노드를 추가할 수 있습니다.

Patroni 지원

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

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

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

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

제대로 된 제품 운영 및 보안을 위해서는 적어도 다음이 필요합니다:

  • 3개의 컨설 노드 (primary 및 secondary 사이트)
  • 2개의 Patroni 노드 (primary 및 secondary 사이트)
  • 1개의 PgBouncer 노드 (primary 및 secondary 사이트)
  • 1개의 내부 로드 밸런서 (primary 사이트에만)

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

비밀번호 자격 증명과 다른 데이터베이스 최선의 방법을 사용해야 합니다.

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

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

주 사이트의 Patroni 리더 인스턴스에서 시작하는 각 Patroni 인스턴스를 실행하는 노드에서:

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

    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]
}
   
# 각 secondary마다 고유한 이름을 따르는 복제 슬롯을 설정해야 합니다:
#
# 설정 구문: 'unique_slotname' => { 'type' => 'physical' },
# 우리는 논리적 복제 유형에 대한 영구 복제 슬롯 설정을 지원하지 않습니다.
patroni['replication_slots'] = {
  'geo_secondary' => { 'type' => 'physical' }
}
   
patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 8 # Patroni/reserved 슬롯 수의 2배를 사용합니다 (3개의 patroni + 1개의 Geo secondary에 대한 예약 슬롯).
patroni['postgresql']['max_replication_slots'] = 8 # Patroni/reserved 슬롯 수의 2배를 사용합니다 (3개의 patroni + 1개의 Geo secondary에 대한 예약 슬롯).
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = '평문_포스트그리SQL_복제_비밀번호'
   
# 모든 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
]
   
# 모든 secondary 인스턴스를 나열합니다. 모든 secondary가 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' # 여기에 공용 또는 VPC 주소를 사용할 수 있습니다

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

    gitlab-ctl reconfigure
단계 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
    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를 하고 루트로 로그인합니다: 

    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. .pgpass 파일을 만들어서 Consul이 PgBouncer를 다시로드 할 수 있도록 합니다. 물어볼 때 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를 하고 루트로 로그인합니다: 

    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'] = '내부 로드 밸런서 주 사이트 IP'
patroni['standby_cluster']['port'] = 내부 로드 밸런서 주 사이트 포트
patroni['standby_cluster']['primary_slot_name'] = 'geo_secondary' # 또는 이전에 설정한 고유한 복제 슬롯 이름
patroni['username'] = 'PATRONI_API_USERNAME'
patroni['password'] = 'PATRONI_API_PASSWORD'
patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'
patroni['use_pg_rewind'] = true
patroni['postgresql']['max_wal_senders'] = 5 # 하나의 레플리카당 최소 세 개, 추가 레플리카당 두 개 추가
patroni['postgresql']['max_replication_slots'] = 5 # 하나의 레플리카당 최소 세 개, 추가 레플리카당 두 개 추가
   
postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
postgresql['sql_replication_password'] = 'POSTGRESQL_REPLICATION_PASSWORD_HASH'
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
postgresql['listen_address'] = '0.0.0.0' # 여기에 공개 또는 VPC 주소를 사용할 수 있습니다.
   
gitlab_rails['db_password'] = 'POSTGRESQL_PASSWORD'
gitlab_rails['enable'] = true
gitlab_rails['auto_migrate'] = false

    patroni['standby_cluster']['host'] 및 patroni['standby_cluster']['port']를 구성할 때: - 내부 로드 밸런서 주 사이트 IP은 주 내부 로드 밸런서 IP를 가리켜야 합니다. - 내부 로드 밸런서 주 사이트 포트는 주 Patroni 클러스터 리더용으로 구성된 프론트엔드 포트를 가리켜야 합니다. PgBouncer 프론트엔드 포트를 사용하면 안 됩니다.

  3. 변경 사항이 적용되도록 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
gitlab-ctl start patroni

Patroni로 단일 추적 데이터베이스 노드를 이전하는 방법

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

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

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

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

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

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

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

문제 해결

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