PostgreSQL

Tier: Free, Premium, Ultimate Offering: Self-Managed형

이 페이지에는 GitLab 지원팀이 문제 해결 시 사용하는 PostgreSQL에 대한 정보가 포함되어 있습니다. GitLab은 이 정보를 공개하여 누구나 지원팀이 수집한 지식을 활용할 수 있도록 합니다.

caution
여기에 문서화된 일부 절차는 GitLab 인스턴스를 손상시킬 수 있습니다. 자신의 책임 하에 사용하세요.

만약 유료 등급에 속해 있고 이 명령어를 사용하는 방법을 모르겠다면, 지원팀에 문의하여 도움을 받을 수 있습니다.

데이터베이스 콘솔 시작

Linux 패키지 (Omnibus)

추천 대상:

  • 단일 노드 인스턴스.
  • 확장된 또는 하이브리드 환경, 보통 Patroni 노드나 리더에서.
  • 확장된 또는 하이브리드 환경, PostgreSQL 서비스를 실행하는 서버에서. 
sudo gitlab-psql

단일 노드 인스턴스나 웹 또는 Sidekiq 노드의 경우 Rails 데이터베이스 콘솔을 사용할 수도 있지만 초기화에 시간이 더 걸립니다. 

sudo gitlab-rails db-console --database main
도커
docker exec -it <container-id> gitlab-psql
자체 컴파일(소스)

설치 가이드의 PostgreSQL 설치에 포함된 psql 명령어를 사용합니다. 

sudo -u git -H psql -d gitlabhq_production
Helm 차트 (Kubernetes)
  • 하이브리드 환경을 실행하고 PostgreSQL이 Linux 패키지 설치(Omnibus)에서 실행 중인 경우, 해당 서버에서 지역적으로 데이터베이스 콘솔을 사용하는 것이 권장됩니다. Linux 패키지 세부 정보를 참조하세요.
  • 외부 제삼자 PostgreSQL 서비스에 포함된 콘솔을 사용합니다.
  • 도구 상자 pod에서 gitlab-rails db-console 실행.

콘솔을 종료하려면 quit를 입력하세요.

기타 GitLab PostgreSQL 문서

이 섹션은 GitLab 문서의 다른 위치에 대한 링크를 포함합니다.

절차

지원 주제

데이터베이스 락

참조: 

ERROR: deadlock detected

이 문제에 관한 세 가지 적용 가능한 타임아웃은 이슈 #30528에서 식별되었습니다. 권장 설정은 다음과 같습니다: 

deadlock_timeout = 5s
statement_timeout = 15s
idle_in_transaction_session_timeout = 60s

이슈 #30528에서 인용:

“데드락이 발생하고 짧은 기간 후에 트랜잭션을 중단하여 해결하면 이미 사용 중인 재시도 메커니즘은 데드락이 발생한 작업을 다시 시도하고, 여러 번 연속해서 데드락이 발생할 가능성은 낮습니다.”

일반적으로 지원에서 타임아웃을 다시 구성하는 접근 방식은 (HTTP 스택에도 적용됨) 임시적으로 문제를 해결하기 위해 수행됩니다. 이렇게 하면 고객이 GitLab을 사용할 수 있게 되어 문제를 더 완전히 이해하고, 핫 픽스를 구현하거나 기본 원인을 해결하는 다른 변경을 적용할 시간을 벌 수 있습니다. 일반적으로 원인이 해결된 후에 타임아웃은 합리적인 기본값으로 되돌려야 합니다. 일반적으로 타임아웃은 근본적인 원인이 해결될 때 합리적인 기본값으로 되돌려져야 합니다.

이 경우 개발팀으로부터 받은 지침은 deadlock_timeout 또는 statement_timeout을 삭제하지만 60초의 세 번째 설정은 남겨둘 것을 권장했습니다. idle_in_transaction 설정은 잠재적으로 몇 일 동안 매달릴 수 있는 세션에서 데이터베이스를 보호합니다. GitLab.com에 이러한 시간 초과를 도입하는데 관한 이슈에서 더 많은 토론이 있습니다.

PostgreSQL 기본값:

  • statement_timeout = 0 (무제한)
  • idle_in_transaction_session_timeout = 0 (무제한)

이슈 #30528의 코멘트에 따르면 이러한 기본값은 모든 Linux 패키지 설치에 대해 적어도 몇 분으로 설정되어야 하며(무한대로 매달리지 않도록), statement_timeout의 15초는 매우 짧으며 기반이 아주 효과적인 경우에만 효과가 있습니다.

현재 설정은 다음과 같이 확인할 수 있습니다. 

sudo gitlab-rails runner "c = ApplicationRecord.connection ; puts c.execute('SHOW statement_timeout').to_a ;
puts c.execute('SHOW deadlock_timeout').to_a ;
puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"

응답하는 데 시간이 걸릴 수 있습니다. 

{"statement_timeout"=>"1min"}
{"deadlock_timeout"=>"0"}
{"idle_in_transaction_session_timeout"=>"1min"}

이러한 설정은 /etc/gitlab/gitlab.rb에서 다음과 같이 업데이트할 수 있습니다. 

postgresql['deadlock_timeout'] = '5s'
postgresql['statement_timeout'] = '15s'
postgresql['idle_in_transaction_session_timeout'] = '60s'

저장한 후, 변경 사항이 적용되려면 GitLab 다시 구성해야 합니다.

note
이 설정은 Linux 패키지 설정입니다. 고객의 PostgreSQL 설치나 Amazon RDS와 같은 외부 데이터베이스를 사용하는 경우에는 이러한 값이 설정되지 않으며 외부에서 설정해야 합니다.

일시적으로 질의 시간 초과 변경

caution
변경된 타임아웃이 의도한 것보다 더 많은 트랜잭션에 영향을 줄 수 있기 때문에 PgBouncer가 활성화된 경우 다음의 조언이 적용되지 않습니다.

일부 상황에서 GitLab 재구성을 다시 시작하지 않아도 다른 질의 시간 초과를 설정할 수 있는 경우가 있습니다. 이 경우 이러한 설정은 Puma와 Sidekiq를 다시 시작하는 대신 진행된 트랜잭션을 보다 잘 관리할 수 있습니다.

예를 들어, 다음과 같은 오류가 발생하여 백업 명령어의 출력에 다음과 같은 오류가 표시될 수 있습니다. 

pg_dump: error: Error message from server: server closed the connection unexpectedly

PostgreSQL 로그에서도 다음과 같은 오류를 볼 수 있습니다. 

canceling statement due to statement timeout

질의 시간 초과를 일시적으로 변경하려면:

  1. 편집기에서 /var/opt/gitlab/gitlab-rails/etc/database.yml을 엽니다.
  2. statement_timeout 값을 무제한 질의 시간 초과로 설정하는 값인 0으로 설정합니다.

  3. 이 값이 사용되는지 새로운 Rails 콘솔 세션에서 확인합니다. 

    sudo gitlab-rails runner "ActiveRecord::Base.connection_config[:variables]"
  4. 다른 타임아웃이 필요한 작업(예: 백업 또는 Rails 명령어)을 수행합니다.
  5. /var/opt/gitlab/gitlab-rails/etc/database.yml에서 편집한 부분을 되돌립니다.

문제 해결

데이터베이스가 wraparound 데이터 손실을 피하기 위해 명령을 받아들이지 않음

이 오류는 autovacuum이 실행을 완료하지 못하는 것을 의미합니다: 

ERROR: database is not accepting commands to avoid wraparound data loss in database "gitlabhq_production"

또는 

ERROR: failed to re-find parent key in index "XXX" for deletion target page XXX

오류를 해결하려면 VACUUM을 매뉴얼으로 실행하세요:

  1. 명령을 사용하여 GitLab을 중지합니다: gitlab-ctl stop.

  2. 다음 명령을 사용하여 데이터베이스를 단일 사용자 모드로 설정합니다: 

    /opt/gitlab/embedded/bin/postgres --single -D /var/opt/gitlab/postgresql/data gitlabhq_production
  3. backend> 프롬프트에서 VACUUM;을 실행합니다. 이 명령은 완료하는 데 몇 분이 걸릴 수 있습니다.
  4. 명령이 완료될 때까지 기다린 다음 Control + D를 눌러 나가세요.
  5. 명령을 사용하여 GitLab을 시작합니다: gitlab-ctl start.

GitLab 데이터베이스 요구 사항

데이터베이스 요구 사항을 확인하고 필요한 확장 디렉터리을 검토하고 설치하세요 (required extension list).

production/sidekiq 로그의 직렬화 오류

production/sidekiq 로그에서 다음 예와 같은 오류를 받는 경우, 문제를 해결하기 위해 default_transaction_isolation을 read committed로 설정하는 방법을 읽어보세요: 

ActiveRecord::StatementInvalid PG::TRSerializationFailure: ERROR: could not serialize access due to concurrent update

PostgreSQL 복제 슬롯 오류

다음 예와 같은 오류를 받는 경우, PostgreSQL HA 복제 슬롯 오류를 해결하는 방법에 대해 알아보세요: 

pg_basebackup: could not create temporary replication slot "pg_basebackup_12345": ERROR: all replication slots are in use
HINT: Free one or increase max_replication_slots.

Geo 복제 오류

다음 예와 같은 오류를 받는 경우, Geo 복제 오류를 해결하는 방법에 대해 알아보세요: 

ERROR: replication slots can only be used if max_replication_slots > 0

FATAL: could not start WAL streaming: ERROR: replication slot "geo_secondary_my_domain_com" does not exist

Command exceeded allowed execution time

PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device

Geo 구성 및 일반 오류 검토

Geo 문제 해결 시 다음을 수행해야 합니다:

  • 일반 Geo 오류를 검토합니다.
  • 호스트 및 포트를 다시 구성합니다.
  • 사용자 및 암호 매핑을 검토하고 수정합니다.

pg_dump 및 psql 버전 불일치

다음과 같은 오류를 받는 경우 비 패키지형 PostgreSQL 데이터베이스 백업 및 복원 방법에 대해 알아보세요: 

Dumping PostgreSQL database gitlabhq_production ... pg_dump: error: server version: 13.3; pg_dump version: 14.2
pg_dump: error: aborting because of server version mismatch

Extension btree_gist의 허용 디렉터리에 없음

Azure Database for PostgreSQL - Flexible Server에 PostgreSQL을 배포하는 경우 다음 오류가 발생할 수 있습니다: 

extension "btree_gist" is not allow-listed for "azure_pg_admin" users in Azure Database for PostgreSQL

이 오류를 해결하려면 설치 전에 확장을 허용 디렉터리에 추가하세요.