PostgreSQL

Tier: Free, Premium, Ultimate Offering: Self-managed

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

caution
여기에 문서화된 일부 절차는 GitLab 인스턴스에 문제를 일으킬 수 있습니다.
사용은 귀하의 위험 부담 아래에서 진행하세요.

유료 계층에 있는 경우 유료 계층과
이 명령어를 사용하는 방법이 확실하지 않은 경우, 지원팀에 문의하여
문제가 발생한 경우 도움을 받으세요.

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

Linux package (Omnibus)

권장 사항:

  • 단일 노드 인스턴스.
  • Patroni 노드에서의 스케일 아웃 또는 하이브리드 환경, 일반적으로 리더.
  • PostgreSQL 서비스를 실행하는 서버에서의 스케일 아웃 또는 하이브리드 환경.
sudo gitlab-psql

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

sudo gitlab-rails db-console --database main
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 서비스의 일부인 콘솔을 사용하세요.
  • 툴박스 팟에서 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에서의 댓글은 이 두 가지 모두 리눅스 패키지 설치에 대해 최소 몇 분으로 설정해야 한다고 나타냅니다 (무한히 멈추지 않도록). 그러나 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 로그에서 다음과 같은 오류가 발생하는 경우, 문제를 해결하기 위해 기본 트랜잭션 격리를 커밋으로 설정하기에 대해 읽어보세요:

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.

지오 복제 오류

이와 같은 오류가 발생하면, 지오 복제 오류 해결 방법을 읽어보세요:

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

지오 구성 및 일반 오류 검토

지오 문제를 해결할 때는 다음을 수행해야 합니다:

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을 배포하면 이 오류가 발생할 수 있습니다:

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

이 오류를 해결하려면 설치하기 전에 확장 프로그램을 허용 목록에 추가하세요.