- PgBouncer가 장애 허용 GitLab 설치의 일부인 경우
- PgBouncer가 장애 허용이 아닌 GitLab 설치의 일부인 경우
- 백업
- 모니터링 활성화
- 관리 콘솔
- PgBouncer 우회 절차
- 세부 조정
- 문제 해결
번들된 PgBouncer 서비스 사용하기
gitlab-ee
패키지에 번들로 제공되지만 무료로 사용할 수 있습니다.
지원을 받으려면 Premium 구독이 필요합니다.PgBouncer는 장애 조치 시나리오에서 서버 간 데이터베이스 연결을 원활하게 이관하는 데 사용됩니다. 또한, 결함 허용 설정이 아닌 환경에서는 연결을 풀링하여 응답 시간을 단축하고 리소스 사용량을 줄일 수 있습니다.
GitLab Premium에는 관리 가능한 PgBouncer의 번들 버전이 포함되어 있으며, /etc/gitlab/gitlab.rb
를 통해 관리할 수 있습니다.
PgBouncer가 장애 허용 GitLab 설치의 일부인 경우
이 내용은 새 위치로 이동되었습니다.
PgBouncer가 장애 허용이 아닌 GitLab 설치의 일부인 경우
-
gitlab-ctl pg-password-md5 pgbouncer
명령을 사용하여PGBOUNCER_USER_PASSWORD_HASH
를 생성하세요. -
gitlab-ctl pg-password-md5 gitlab
명령을 사용하여SQL_USER_PASSWORD_HASH
를 생성하세요. 나중에 일반 텍스트 SQL_USER_PASSWORD를 입력하세요. -
데이터베이스 노드에서
/etc/gitlab/gitlab.rb
에서 다음이 설정되어 있는지 확인하세요.postgresql['pgbouncer_user_password'] = 'PGBOUNCER_USER_PASSWORD_HASH' postgresql['sql_user_password'] = 'SQL_USER_PASSWORD_HASH' postgresql['listen_address'] = 'XX.XX.XX.Y' # XX.XX.XX.Y는 postgresql이 수신 대기해야하는 노드의 IP 주소입니다. postgresql['md5_auth_cidr_addresses'] = %w(AA.AA.AA.B/32) # AA.AA.AA.B는 pgbouncer 노드의 IP 주소입니다.
-
gitlab-ctl reconfigure
를 실행하세요.데이터베이스가 이미 실행 중이었던 경우,gitlab-ctl restart postgresql
을 실행하여 다시 시작해야 합니다. -
PgBouncer를 실행하는 노드에서
/etc/gitlab/gitlab.rb
에서 다음이 설정되어 있는지 확인하세요.pgbouncer['enable'] = true pgbouncer['databases'] = { gitlabhq_production: { host: 'DATABASE_HOST', user: 'pgbouncer', password: 'PGBOUNCER_USER_PASSWORD_HASH' } }
데이터베이스당 추가 구성 매개변수를 전달할 수 있습니다.
pgbouncer['databases'] = { gitlabhq_production: { ... pool_mode: 'transaction' } }
이러한 매개변수를 사용할 때 주의하십시오. 매개변수의 완전한 디렉터리은 PgBouncer 문서를 참조하십시오.
-
gitlab-ctl reconfigure
를 실행하세요. -
Puma를 실행하는 노드에서
/etc/gitlab/gitlab.rb
에서 다음이 설정되어 있는지 확인하세요.gitlab_rails['db_host'] = 'PGBOUNCER_HOST' gitlab_rails['db_port'] = '6432' gitlab_rails['db_password'] = 'SQL_USER_PASSWORD'
-
gitlab-ctl reconfigure
를 실행하세요. -
이 시점에서 인스턴스는 PgBouncer를 통해 데이터베이스에 연결해야 합니다. 문제가 있는 경우 문제 해결 섹션을 참조하세요.
백업
PgBouncer 연결을 통해 GitLab을 백업하거나 복원하지 마세요. GitLab 장애를 유발시킵니다.
이에 대해 자세히 알아보고 백업을 다시 구성하는 방법을 참조하세요.
모니터링 활성화
- GitLab 12.0에서 도입되었습니다.
모니터링을 활성화하면 모든 PgBouncer 서버에서 활성화해야 합니다.
-
/etc/gitlab/gitlab.rb
을 만들거나 편집하여 다음 구성을 추가하세요.# Prometheus를 위한 서비스 탐지 활성화 consul['enable'] = true consul['monitoring_service_discovery'] = true # 자리 표시자 교체 # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z # 이는 Consul 서버 노드의 주소로 교체합니다 consul['configuration'] = { retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z), } # 수출자가 수신 대기할 네트워크 주소 설정 node_exporter['listen_address'] = '0.0.0.0:9100' pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
-
구성을 컴파일하려면
sudo gitlab-ctl reconfigure
를 실행하세요.
관리 콘솔
Linux 패키지 설치에서는 PgBouncer 관리 콘솔에 자동으로 연결하는 명령이 제공됩니다. 자세한 지침은 PgBouncer 문서를 참조하세요.
세션을 시작하려면 다음을 실행하고 pgbouncer
사용자의 암호를 제공하세요.
sudo gitlab-ctl pgb-console
인스턴스에 대한 기본 정보를 얻으려면:
pgbouncer=# show databases; show clients; show servers;
name | host | port | database | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-----------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
gitlabhq_production | 127.0.0.1 | 5432 | gitlabhq_production | | 100 | 5 | | 0 | 1
pgbouncer | | 6432 | pgbouncer | pgbouncer | 2 | 0 | statement | 0 | 0
(2 rows)
type | user | database | state | addr | port | local_addr | local_port | connect_time | request_time | ptr | link
| remote_pid | tls
------+-----------+---------------------+--------+-----------+-------+------------+------------+---------------------+---------------------+-----------+------
+------------+-----
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44590 | 127.0.0.1 | 6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x12444c0 |
| 0 |
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44592 | 127.0.0.1 | 6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x12447c0 |
| 0 |
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44594 | 127.0.0.1 | 6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x1244940 |
| 0 |
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44706 | 127.0.0.1 | 6432 | 2018-04-24 22:14:22 | 2018-04-24 22:16:31 | 0x1244ac0 |
| 0 |
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44708 | 127.0.0.1 | 6432 | 2018-04-24 22:14:22 | 2018-04-24 22:15:15 | 0x1244c40 |
| 0 |
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44794 | 127.0.0.1 | 6432 | 2018-04-24 22:15:15 | 2018-04-24 22:15:15 | 0x1244dc0 |
| 0 |
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44798 | 127.0.0.1 | 6432 | 2018-04-24 22:15:15 | 2018-04-24 22:16:31 | 0x1244f40 |
| 0 |
C | pgbouncer | pgbouncer | active | 127.0.0.1 | 44660 | 127.0.0.1 | 6432 | 2018-04-24 22:13:51 | 2018-04-24 22:17:12 | 0x1244640 |
| 0 |
(8 rows)
type | user | database | state | addr | port | local_addr | local_port | connect_time | request_time | ptr | link | rem
ote_pid | tls
------+--------+---------------------+-------+-----------+------+------------+------------+---------------------+---------------------+-----------+------+----
--------+-----
S | gitlab | gitlabhq_production | idle | 127.0.0.1 | 5432 | 127.0.0.1 | 35646 | 2018-04-24 22:15:15 | 2018-04-24 22:17:10 | 0x124dca0 | |
19980 |
(1 row)
PgBouncer 우회 절차
Linux 패키지 설치
일부 데이터베이스 변경은 PgBouncer를 통하지 않고 직접 수행해야 합니다.
주로 영향을 받는 작업은 데이터베이스 복원 및 데이터베이스 마이그레이션을 통한 GitLab 업그레이드입니다.
-
기본 노드를 찾으려면 데이터베이스 노드에서 다음을 실행합니다:
sudo gitlab-ctl patroni members
-
수행 중인 응용 프로그램 노드의
/etc/gitlab/gitlab.rb
를 편집하고, 데이터베이스 primary의 호스트 및 포트로gitlab_rails['db_host']
및gitlab_rails['db_port']
를 업데이트합니다. -
재구성을 실행합니다:
sudo gitlab-ctl reconfigure
작업이 완료되면 PgBouncer를 사용하도록 다시 전환하세요:
-
/etc/gitlab/gitlab.rb
를 PgBouncer를 가리키도록 다시 변경합니다. -
재구성을 실행합니다:
sudo gitlab-ctl reconfigure
Helm 차트 설치
고가용성 배포에는 Linux 패키지 기반의 이유와 동일한 이유로 PgBouncer를 우회해야 합니다. Helm 차트 설치에 대해:
- 데이터베이스 백업 및 복원 작업은 toolbox 컨테이너에서 수행됩니다.
- 마이그레이션 작업은 마이그레이션 컨테이너에서 수행됩니다.
각 서브차트에서 PostgreSQL 포트를 재정의해야 합니다. 이렇게 하면 이러한 작업이 직접 PostgreSQL에 연결되어 실행될 수 있습니다:
세부 조정
PgBouncer의 기본 설정은 대부분의 설치에 적합합니다. 특정 경우에는 메모리 과다 사용으로 인한 메모리 고갈을 방지하거나 가능한 처리량을 늘리기 위해 성능 및 리소스에 특화된 변수를 변경해야 할 수 있습니다.
Linux 패키지 설치의 해당 변수 및 해당 문서는 공식 PgBouncer 문서에서 찾을 수 있습니다.
Linux 패키지 설치의 가장 관련된 변수 및 기본값은 다음과 같습니다:
-
pgbouncer['max_client_conn']
(기본값:2048
, 서버 파일 디스크립터 제한에 따라 달라짐) 이것은 PgBouncer의 “프론트엔드” 풀입니다: Rails에서 PgBouncer로의 연결. -
pgbouncer['default_pool_size']
(기본값:100
) 이것은 PgBouncer의 “백엔드” 풀입니다: PgBouncer에서 데이터베이스로의 연결.
default_pool_size
의 이상적인 수는 데이터베이스 풀 크기를 정의하는 데 충분해야 합니다. 아래에 나열된 각 서비스의 인스턴스 수를 사용하여 다음과 같은 공식으로 데이터베이스 풀 크기를 계산할 수 있습니다:
-
puma
:max_threads + headroom
(기본값14
)-
max_threads
는gitlab['puma']['max_threads']
로 구성됩니다 (기본값:4
) -
headroom
는DB_POOL_HEADROOM
환경 변수를 통해 구성할 수 있습니다 (기본값:10
)
-
-
sidekiq
:max_concurrency + 1 + headroom
(기본값:31
)-
max_concurrency
는sidekiq['max_concurrency']
로 구성됩니다 (기본값:20
) -
headroom
는DB_POOL_HEADROOM
환경 변수를 통해 구성할 수 있습니다 (기본값:10
)
-
-
geo-logcursor
:1+headroom
(기본값:11
)-
headroom
는DB_POOL_HEADROOM
환경 변수를 통해 구성할 수 있습니다 (기본값:10
)
-
default_pool_size
를 계산하려면 puma
, sidekiq
및 geo-logcursor
의 각 인스턴스 수를 위에 나열된 것과 같이 사용하여 각각이 사용할 수 있는 연결 수를 곱합니다. 총합이 권장되는 default_pool_size
입니다.
내부 로드 밸런서와 함께 둘 이상의 PgBouncer를 사용하는 경우, 인스턴스 수로 default_pool_size
를 나눌 수 있어 각각에 고르게 분산된 부하를 보장할 수 있습니다.
pgbouncer['max_client_conn']
은 PgBouncer가 받아 들일 수 있는 연결의 하드 제한입니다. 이를 변경할 필요는 거의 없을 것입니다. 이 제한에 도달하는 경우 내부 로드 밸런서와 함께 추가 PgBouncer를 추가할 수 있습니다.
Geo 추적 데이터베이스를 가리키는 PgBouncer의 제한을 설정할 때, 불규칙적으로만 그 데이터베이스에 액세스하는 puma
를 무시해도 될 것입니다.
문제 해결
PgBouncer를 통한 연결에 문제가 있는 경우, 항상 로그를 확인할 곳은 다음과 같습니다:
sudo gitlab-ctl tail pgbouncer
추가로, 관리 콘솔의 show databases
출력에서 확인할 수 있습니다. 출력에서 gitlabhq_production
데이터베이스의 host
필드에 값이 있는 것을 예상할 것입니다. 또한, current_connections
는 1보다 커야 합니다.
메시지: LOG: invalid CIDR mask in address
Geo 문서에서 제안된 해결책을 참조하세요.
메시지: LOG: invalid IP mask "md5": Name or service not known
Geo 문서에서 제안된 해결책을 참조하세요.