• 모든 것을 삭제하고 처음부터 시작
• 마이그레이션 처리
• 수동으로 데이터베이스에 액세스
• GUI로 데이터베이스에 액세스
• Visual Studio Code로 GDK 데이터베이스에 액세스
• FAQ
  • ActiveRecord::PendingMigrationError와 Spring
  • db:migrate 데이터베이스 버전이 마이그레이션할 수 있는 버전보다 오래되었음 오류
• 성능 문제
  • 연결 풀링을 사용하여 연결 오버헤드 감소

데이터베이스의 문제 해결 및 디버깅

이 섹션은 일부 머리를 맞대며 데이터베이스 문제에 직면했을 때 참조로 사용할 수 있는 샘플 코드를 제공하는 데 도움을 주기 위한 것입니다.

첫 번째 단계는 슬랙에서 오류를 검색하거나 Google에서 GitLab <나의 오류>를 검색하는 것입니다.

사용 가능한 RAILS_ENV:

• production (일반적으로 본인의 주 GDK 데이터베이스에는 해당되지 않지만, Omnibus와 같은 다른 설치에 필요할 수 있습니다).
• development (이것이 본인의 주 GDK 데이터베이스입니다).
• test (RSpec와 같은 테스트에 사용됨).

모든 것을 삭제하고 처음부터 시작

모든 것을 삭제하고 빈 DB에서 다시 시작하려는 경우(약 1분 소요):

bundle exec rake db:reset RAILS_ENV=development

빈 DB에 샘플 데이터를 시드하려는 경우(약 4분 소요):

bundle exec rake dev:setup

모든 것을 삭제하고 샘플 데이터로 처음부터 다시 시작하려는 경우(약 4분 소요). 또한 db:reset를 실행하고 DB별 마이그레이션을 실행합니다:

bundle exec rake db:setup RAILS_ENV=development

테스트 DB에 문제가 있는 경우 중요 데이터가 포함되어 있지 않으므로 모든 것을 안전하게 삭제해도 됩니다:

bundle exec rake db:reset RAILS_ENV=test

마이그레이션 처리

• bundle exec rake db:migrate RAILS_ENV=development: MR에서 가져올 수 있는 보류 중인 마이그레이션을 실행합니다.
• bundle exec rake db:migrate:status RAILS_ENV=development: 모든 마이그레이션이 up 또는 down인지 확인합니다.
• bundle exec rake db:migrate:down:main VERSION=20170926203418 RAILS_ENV=development: 마이그레이션을 해제합니다.
• bundle exec rake db:migrate:up:main VERSION=20170926203418 RAILS_ENV=development: 마이그레이션을 설정합니다.
• bundle exec rake db:migrate:redo:main VERSION=20170926203418 RAILS_ENV=development: 특정 마이그레이션을 다시 실행합니다.

위 명령어에서 main을 ci 데이터베이스 대신에 실행하도록 변경합니다.

수동으로 데이터베이스에 액세스

다음 명령어 중 하나로 데이터베이스에 액세스합니다(모두 동일한 위치로 이동시킵니다).

gdk psql -d gitlabhq_development
bundle exec rails dbconsole -e development
bundle exec rails db -e development

• \q: 종료
• \dt: 모든 테이블 나열
• \d+ issues: issues 테이블의 열 나열
• CREATE TABLE board_labels();: board_labels라는 테이블 생성
• SELECT * FROM schema_migrations WHERE version = '20170926203418';: 마이그레이션이 실행되었는지 확인
• DELETE FROM schema_migrations WHERE version = '20170926203418';: 마이그레이션을 수동으로 제거

GUI로 데이터베이스에 액세스

대부분의 GUI(DataGrip, RubyMine, DBeaver)는 데이터베이스에 대한 TCP 연결이 필요하지만 기본적으로 데이터베이스는 UNIX 소켓에서 실행됩니다. 이러한 도구에서 데이터베이스에 액세스하려면 일부 단계가 필요합니다:

1. GDK 루트 디렉토리에서 다음을 실행합니다:

   gdk config set postgresql.host localhost
   

2. gdk.yml을 열고 다음 라인이 있는지 확인합니다:

   postgresql:
      host: localhost
   

3. GDK를 다시 구성합니다:

   gdk reconfigure
   

4. 데이터베이스 GUI에서 호스트로 localhost를, 포트로 5432를, 데이터베이스로 gitlabhq_development를 선택합니다. 각각의 대안으로 연결 문자열 postgresql://localhost:5432/gitlabhq_development를 사용할 수 있습니다.

새로운 연결은 이제 작동해야 합니다.

Visual Studio Code로 GDK 데이터베이스에 액세스

GDK를 사용하여 개발 중일 때 GitLab 데이터베이스를 살펴보기 위해 다음 지침을 사용하세요:

1. Visual Studio Code를 설치하거나 엽니다.
2. PostgreSQL VS Code Extension을 설치합니다.
3. 왼쪽 툴바에서 PostgreSQL Explorer를 선택합니다.
4. 새 창의 상단줄에서 +를 선택하여 데이터베이스 연결 추가를 선택하고 프롬프트에 맞춰 세부 정보를 입력합니다:
   1. 호스트명: GDK 디렉토리의 PostgreSQL 폴더 경로(예: /dev/gitlab-development-kit/postgresql).
   2. 인증할 PostgreSQL 사용자: 보통 지역 사용자 이름(로컬 PostgreSQL 설치 중에 다르게 지정하지 않은 경우).
   3. PostgreSQL 사용자의 암호: PostgreSQL 설치 시 설정한 암호.
   4. 연결할 포트 번호: 5432 (기본값).
   5. SSL 연결 사용 여부? 이는 설치에 따라 다릅니다. 옵션은 다음과 같습니다:
      • 보안 연결 사용
      • 표준 연결 (기본값)
   6. 선택 사항. 연결할 데이터베이스: gitlabhq_development.
   7. 데이터베이스 연결의 표시 이름: gitlabhq_development.

데이터베이스 연결은 이제 PostgreSQL 탐색기 창에 표시되어 있으며 gitlabhq_development 데이터베이스를 살펴볼 수 있습니다. 연결할 수 없을 경우 GDK가 실행 중인지 확인하세요. Visual Studio Code용 PostgreSQL 탐색기 확장 사용에 대한 자세한 지침은 확장 프로그램 설명서의 사용 방법 섹션을 참조하세요.

FAQ

ActiveRecord::PendingMigrationError와 Spring

Spring pre-loader를 사용하여 스펙을 실행할 때, 테스트 데이터베이스가 손상될 수 있습니다. 마이그레이션을 실행하거나 테스트 데이터베이스를 삭제/재설정해도 효과가 없을 수 있습니다.

$ bundle exec spring rspec some_spec.rb
...
실패/Error: ActiveRecord::Migration.maintain_test_schema!

ActiveRecord::PendingMigrationError:


  마이그레이션이 대기 중입니다. 이 문제를 해결하려면 다음을 실행하세요:

    bin/rake db:migrate RAILS_ENV=test
# ~/.rvm/gems/ruby-2.3.3/gems/activerecord-4.2.10/lib/active_record/migration.rb:392:in `check_pending!'
...
0 예제, 0 실패, 1 예외가 예제 외부에서 발생했습니다

이 문제를 해결하려면 스펙 실행 간에 존재하는 spring 서버와 앱을 종료해야 합니다.

$ ps aux | grep spring
eric             87304   1.3  2.9  3080836 482596   ??  Ss   10:12AM   4:08.36 spring app    | gitlab | 6시간 전 시작 | 테스트 모드
eric             37709   0.0  0.0  2518640   7524 s006  S    수요일 11AM   0:00.79 spring server | gitlab | 29시간 전 시작
$ kill 87304
$ kill 37709

db:migrate 데이터베이스 버전이 마이그레이션할 수 있는 버전보다 오래되었음 오류

사용자는 db:migrate를 실행할 때 현재 스키마 버전이 Gitlab::Database 라이브러리 모듈에서 정의된 MIN_SCHEMA_VERSION보다 이전인 것을 감지하면 이 오류를 받게 됩니다.

시간이 지남에 따라 우리는 코드베이스에서 오래된 마이그레이션을 정리/병합하므로 이전 모든 버전에서 GitLab을 마이그레이션하는 것이 항상 가능한 것은 아닙니다.

경우에 따라 이를 우회해야 할 수 있습니다. 예를 들어, 여러분이 MIN_SCHEMA_VERSION보다 나중에 릴리즈된 GitLab 스키마 버전을 사용 중이었으며, 그 후에 이전으로 마이그레이션하여 이전 상태로 돌아간 경우입니다. 그런 경우에는 다시 앞으로 마이그레이션하려면 SKIP_SCHEMA_VERSION_CHECK 환경 변수를 설정해야 합니다.

bundle exec rake db:migrate SKIP_SCHEMA_VERSION_CHECK=true

성능 문제

연결 풀링을 사용하여 연결 오버헤드 감소

새로운 데이터베이스 연결을 만드는 데는 무료가 아니며, 특히 PostgreSQL에서는 각각의 새로운 연결을 처리하기 위해 전체 프로세스를 복제해야 합니다. 연결이 매우 오랜 시간동안 유지된다면, 이는 문제가 아닙니다. 그러나 여러 개의 작은 쿼리를 처리하기 위해 프로세스를 복제하는 것은 비용이 발생할 수 있습니다. 방치하게 되면, 새로운 데이터베이스 연결이 큰 피크를 일으켜 성능 저하를 유발하거나 완전한 장애로 이어질 수 있습니다.

작고 수명이 짧은 데이터베이스 연결의 폭증을 다루는 경우 검증된 해결책은 PgBouncer를 연결 풀러로 구현하는 것입니다. 이 연결 풀은 아주 작은 오버헤드로 수천 개의 연결을 유지할 수 있습니다. 그 단점은 몇몇 사용 패턴에 따라 90% 이상의 성능 향상을 가져오는 대신 교환으로 약간의 지연이 추가된다는 것입니다.

PgBouncer는 다양한 설치에 맞게 세밀하게 조정할 수 있습니다. 자세한 정보는 PgBouncer를 세부 조정하는 저희 문서를 참조하세요.