PostgreSQL
이 페이지에는 GitLab 지원팀이 문제 해결 시 사용하는 PostgreSQL에 대한 정보가 포함되어 있습니다. GitLab은 이 정보를 공개하여 누구나 지원팀이 수집한 지식을 활용할 수 있도록 합니다.
만약 유료 등급에 속해 있고 이 명령어를 사용하는 방법을 모르겠다면, 지원팀에 문의하여 도움을 받을 수 있습니다.
데이터베이스 콘솔 시작
추천 대상:
- 단일 노드 인스턴스.
- 확장된 또는 하이브리드 환경, 보통 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
- 하이브리드 환경을 실행하고 PostgreSQL이 Linux 패키지 설치(Omnibus)에서 실행 중인 경우, 해당 서버에서 지역적으로 데이터베이스 콘솔을 사용하는 것이 권장됩니다. Linux 패키지 세부 정보를 참조하세요.
- 외부 제삼자 PostgreSQL 서비스에 포함된 콘솔을 사용합니다.
- 도구 상자 pod에서
gitlab-rails db-console
실행.- 자세한 내용은 Kubernetes cheat sheet를 참조하세요.
콘솔을 종료하려면 quit
를 입력하세요.
기타 GitLab PostgreSQL 문서
이 섹션은 GitLab 문서의 다른 위치에 대한 링크를 포함합니다.
절차
-
Linux 패키지 설치용 데이터베이스 절차는 다음을 포함합니다:
- SSL: 활성화, 비활성화, 검증.
- Write Ahead Log (WAL) archiving 활성화.
- 외부(Non-Omnibus) PostgreSQL 설치 사용 및 백업.
- 소켓 대신 TCP/IP 또는 그것과 함께 사용.
- 데이터를 다른 위치에 저장.
- GitLab 데이터베이스 파괴적 다시 생성.
- 패키지된 PostgreSQL의 업데이트 관련 안내, 자동 업데이트 비활성화 방법을 포함.
-
리눅스 패키지 설치용 PostgreSQL 버전 관리 개발 문서.
-
PostgreSQL 확장
-
문제 해결 포함
gitlab-ctl patroni check-leader
및 PgBouncer 오류.
-
문제 해결 포함
-
개발자 데이터베이스 문서,
일부 내용은 절대적으로 프로덕션용이 아닙니다. 포함된 내용:
- EXPLAIN 계획 이해.
지원 주제
데이터베이스 락
참조:
- 특별한 상황에서 인스턴스가 푸시로 통해 과도하게 경고를 받은 경우 데드락이 발생할 수 있습니다. 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 다시 구성해야 합니다.
일시적으로 질의 시간 초과 변경
일부 상황에서 GitLab 재구성을 다시 시작하지 않아도 다른 질의 시간 초과를 설정할 수 있는 경우가 있습니다. 이 경우 이러한 설정은 Puma와 Sidekiq를 다시 시작하는 대신 진행된 트랜잭션을 보다 잘 관리할 수 있습니다.
예를 들어, 다음과 같은 오류가 발생하여 백업 명령어의 출력에 다음과 같은 오류가 표시될 수 있습니다.
pg_dump: error: Error message from server: server closed the connection unexpectedly
PostgreSQL 로그에서도 다음과 같은 오류를 볼 수 있습니다.
canceling statement due to statement timeout
질의 시간 초과를 일시적으로 변경하려면:
- 편집기에서
/var/opt/gitlab/gitlab-rails/etc/database.yml
을 엽니다. -
statement_timeout
값을 무제한 질의 시간 초과로 설정하는 값인0
으로 설정합니다. -
이 값이 사용되는지 새로운 Rails 콘솔 세션에서 확인합니다.
sudo gitlab-rails runner "ActiveRecord::Base.connection_config[:variables]"
- 다른 타임아웃이 필요한 작업(예: 백업 또는 Rails 명령어)을 수행합니다.
-
/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
을 매뉴얼으로 실행하세요:
- 명령을 사용하여 GitLab을 중지합니다:
gitlab-ctl stop
. -
다음 명령을 사용하여 데이터베이스를 단일 사용자 모드로 설정합니다:
/opt/gitlab/embedded/bin/postgres --single -D /var/opt/gitlab/postgresql/data gitlabhq_production
-
backend>
프롬프트에서VACUUM;
을 실행합니다. 이 명령은 완료하는 데 몇 분이 걸릴 수 있습니다. - 명령이 완료될 때까지 기다린 다음 Control + D를 눌러 나가세요.
- 명령을 사용하여 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
이 오류를 해결하려면 설치 전에 확장을 허용 디렉터리에 추가하세요.