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

이 섹션은 머리를 맞대고 고민하는 데이터베이스 문제에 직면했을 때 참고할 수 있는 복사 및 붙여넣기를 제공하는 데 도움을 주도록 돕기 위한 것입니다.

첫 번째 단계는 슬랙에서 오류를 검색하거나, 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: 특정 마이그레이션을 다시 실행합니다.

위 명령어의 mainmain 대신 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 Explorer 패널에 표시되고 gitlabhq_development 데이터베이스를 탐색할 수 있습니다. 연결하지 못하는 경우 GDK가 실행 중인지 확인하세요. PostgreSQL Explorer 확장 프로그램에 대한 자세한 사용 방법은 확장 프로그램 설명서의 사용 방법 섹션을 읽으세요.

자주 묻는 질문

Spring과 함께 발생하는 ActiveRecord::PendingMigrationError

Spring 사전 로더를 사용하여 명세를 실행할 때, 테스트 데이터베이스가 손상된 상태가 될 수 있습니다. 마이그레이션을 실행하거나 테스트 데이터베이스를 삭제/재설정하려고 해도 효과가 없을 수 있습니다.

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

ActiveRecord::PendingMigrationError:
  
  
  Migrations are pending. To resolve this issue, run:
    
    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 examples, 0 failures, 1 error occurred outside of examples

해결하려면 스펙 실행 사이에 존재하는 spring 서버와 앱을 중지시킬 수 있습니다.

$ ps aux | grep spring
eric             87304   1.3  2.9  3080836 482596   ??  Ss   10:12AM   4:08.36 spring app    | gitlab | started 6 hours ago | test mode
eric             37709   0.0  0.0  2518640   7524 s006  S    Wed11AM   0:00.79 spring server | gitlab | started 29 hours ago
$ kill 87304
$ kill 37709

database version is too old to be migrated 오류와 db:migrate

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

시간이 지남에 따라 코드베이스에서 오래된 마이그레이션을 정리/Merge하므로 이전 버전의 GitLab 스키마에서 GitLab을 마이그레이션할 수 없는 경우가 있습니다.

어떤 경우에는 이 확인을 우회할 수 있습니다. 예를 들어, 현재 MIN_SCHEMA_VERSION보다 나중에 있는 GitLab 스키마 버전으로 이동한 후에 다시 이전 버전의 마이그레이션으로 롤백한 경우입니다. 이 경우, 다시 앞으로 마이그레이션하려면 SKIP_SCHEMA_VERSION_CHECK 환경 변수를 설정해야 합니다.

bundle exec rake db:migrate SKIP_SCHEMA_VERSION_CHECK=true

성능 문제

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

새로운 데이터베이스 연결을 생성하는 것은 무료가 아니며 특히 PostgreSQL의 경우 각각 새로운 연결을 처리하기 위해 전체 프로세스를 포킹해야 합니다. 연결이 매우 오랫동안 유지된다면 문제가 되지 않지만, 몇 가지 작은 쿼리를 위해 프로세스를 포킹할 경우 비용이 발생할 수 있습니다. 관리되지 않은 상태에서 새로운 데이터베이스 연결이 급증하면 성능 저하를 일으키거나 심지어 완전한 중단으로 이어질 수 있습니다.

작고 짧은 수명의 데이터베이스 연결이 급증하는 인스턴스에 대한 입증된 해결책은 PgBouncer를 연결 풀러로 구현하는 것입니다. 이 연결 풀은 추가 비용이 거의 없이 수천 개의 연결을 보유하는 데 사용될 수 있습니다. 단점은 사용 패턴에 따라 90% 이상의 성능 향상을 위해 약간의 지연이 추가됩니다.

PgBouncer는 다양한 설치에 맞게 세밀하게 조정될 수 있습니다. 자세한 내용은 PgBouncer 세부 튜닝 문서를 참조하세요.