PostgreSQL

상세정보: Tier: Free, Premium, Ultimate Offering: Self-Managed

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

경고: 여기에 기록된 일부 절차는 GitLab 인스턴스를 손상시킬 수 있습니다. 사용에 주의하십시오.

유료 티어를 사용 중이고 이 명령어를 사용하는 방법을 잘 모르는 경우 지원팀에 문의하여 도움을 받으세요.

데이터베이스 콘솔 시작하기

Linux package (Omnibus)

권장 사항:

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

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

  • GitLab 14.2부터: 

    sudo gitlab-rails db-console --database main

  • GitLab 14.1 및 이전: 

    sudo gitlab-rails db-console
Docker
docker exec -it <container-id> gitlab-psql
Self-compiled (source)

PostgreSQL 설치의 일부인 psql 명령어를 사용하세요. 

sudo -u git -H psql -d gitlabhq_production
Helm chart (Kubernetes)
  • 하이브리드 환경을 실행하는 경우, PostgreSQL이 Linux 패키지 설치(Omnibus)에서 실행되고 있다면 해당 서버에서 로컬로 데이터베이스 콘솔을 사용하는 것이 권장됩니다. Linux 패키지에 대한 자세한 내용은 상세 정보를 참조하세요.
  • 외부 타사 PostgreSQL 서비스의 일부인 콘솔을 사용합니다.
  • toolbox 팟에서 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 스택에도 적용됨) 문제를 완전히 이해하거나 핫 픽스를 구현하거나 루트 원인을 해결하는 다른 변경을 진행하기 전에 일시적으로 수행하는 것입니다. 일반적으로 루트 원인이 해결되면 타임아웃을 기본값으로 다시 설정해야 합니다. 일반적으로 타임아웃은 상당한 기본값으로 돌아가야 합니다.

이 경우 개발팀으로부터의 지침은 deadlock_timeout 또는 statement_timeout를 삭제하고 세 번째 설정을 60초로 유지하는 것이었지만, idle_in_transaction 세팅은 일 수십일 동안 세션을 매달리게 하는 것을 피하기 위해 60초로 설정됩니다. 이에 대한 논의가 더 있으며, GitLab.com에 이러한 타임아웃을 도입하는 문제와 관련된 이슈에서 확인할 수 있습니다.

PostgreSQL 기본값:

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

이슈 #30528의 주석에 따르면 모든 리눅스 패키지 설치용으로 이 두 가지 설정을 최소한 몇 분으로 설정해야 하며, 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 재구성을 해야합니다.

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

문장 제한 시간 일시적으로 변경하기

경고: 다음의 조언은 적용되지 않습니다. 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에서 수정사항을 되돌립니다.

문제 해결

데이터 손실을 피하기 위해 데이터베이스가 명령을 수락하지 않음

이 오류는 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-ctl stop으로 GitLab을 중지합니다.

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

    /opt/gitlab/embedded/bin/postgres --single -D /var/opt/gitlab/postgresql/data gitlabhq_production
  3. backend> 프롬프트에서 VACUUM;을 실행합니다. 이 명령은 완료까지 몇 분이 걸릴 수 있습니다.
  4. 명령이 완료되기를 기다린 후, Control + D를 눌러 종료합니다.
  5. 명령어 gitlab-ctl start로 GitLab을 시작합니다.

GitLab 데이터베이스 요구 사항

데이터베이스 요구 사항을 참조하고 필요한 익스텐션 목록을 검토하고 설치합니다.

production/sidekiq 로그의 직렬화 오류

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

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의 문제를 해결할 때는 다음을 수행해야 합니다:

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

btree_gist 확장 기능은 허용 목록에 없습니다

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

"azure_pg_admin" 사용자의 Azure Database for PostgreSQL에서 "btree_gist" 확장이 허용 목록에 없습니다

이 오류를 해결하려면 설치하기 전에 확장 기능을 허용 목록에 추가해야 합니다.