• すべて削除してやり直し
• マイグレーション作業
• 手動でデータベースにアクセス
• GUIでデータベースにアクセス
• Visual Studio CodeでGDKデータベースにアクセス
• FAQ
  • ActiveRecord::PendingMigrationError 春とともに
  • db:migratedatabase version is too old to be migrated エラー
• パフォーマンスに関するイシュー
  • コネクション・プーリングによる接続オーバーヘッドの削減

データベースのトラブルシューティングとデバッグ

このセクションでは、データベースの問題に遭遇したときに参照できるコピーパスタを紹介します。

最初のステップは、Slack でエラーを検索するか、Google でGitLab <my error> を検索することです。

利用可能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 データベースに対して実行するには、上記のコマンドのmain を置き換えてください。

手動でデータベースにアクセス

以下のコマンドのいずれかを使用してデータベースにアクセスします。

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. Visual Studio Codeで左のツールバーのPostgreSQL Explorerを選択します。
4. 新しいウィンドウの上部バーで、+ toAdd Database Connection を選択し、プロンプトに従って詳細を入力します：
   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 Extension for Visual Studio Code の詳しい使用方法については、拡張ドキュメントの使用法のセクションをお読みください。

FAQ

ActiveRecord::PendingMigrationError 春とともに

Springプリローダーでspecを実行すると、テストデータベースが壊れた状態になることがあります。マイグレーションを実行したり、テストデータベースを削除/リセットしたりしても効果はありません。

$ 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

解決するには、spec実行の間に存在する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

db:migratedatabase version is too old to be migrated エラー

現在のスキーマのバージョンがGitlab::Database ライブラリモジュールで定義されているMIN_SCHEMA_VERSION よりも古いことをdb:migrate が検出すると、ユーザーはこのエラーを受け取ります。

時間の経過とともに、コードベース内の古いマイグレーションをクリーンアップ/結合しているため、GitLabをすべての以前のバージョンからマイグレーションできるとは限りません。

場合によっては、このチェックをバイパスしたいこともあるでしょう。例えば、MIN_SCHEMA_VERSION よりも後のバージョンの GitLab スキーマを使用していて、以前の古いマイグレーションにロールバックした場合。この場合、再びマイグレーションを進めるには、SKIP_SCHEMA_VERSION_CHECK 環境変数を設定する必要があります。

bundle exec rake db:migrate SKIP_SCHEMA_VERSION_CHECK=true

パフォーマンスに関するイシュー

コネクション・プーリングによる接続オーバーヘッドの削減

特にPostgreSQLでは、新しい接続を処理するためにプロセス全体をフォークする必要があります。PostgreSQLでは特に、新しい接続を処理するためにプロセス全体をフォークする必要があります。しかし、いくつかの小さなクエリのためにプロセスをフォークすることは、結果的に高くつきます。新しいデータベース接続のピークを放置しておくと、性能の低下を引き起こし、完全な停止に至ることさえあります。

小規模で短時間のデータベース接続の急増に対処するインスタンスに対する実績のある解決策は、接続プーラとしてPgBouncerを実装することです。このプールは数千の接続を保持するために使用することができ、オーバーヘッドはほとんどありません。欠点は、使用パターンによって最大90%以上の性能向上と引き換えに、少量の待ち時間が追加されることです。

PgBouncerは様々なインストールに合わせて微調整することができます。詳しくはPgBouncerの微調整に関するドキュメントをご覧ください。