PostgreSQL

このページでは、GitLabサポートチームがトラブルシューティングの際に使用しているPostgreSQLに関する情報を掲載しています。GitLabはこの情報を公開し、誰でもサポートチームが収集した知識を活用できるようにしています。

caution
ここに書かれている手順の中には、GitLabインスタンスを壊してしまうものもあるかもしれません。自己責任で使用してください。

有料版を使っていてこれらのコマンドの使い方がわからない場合は、サポートまでお問い合わせください。

データベースコンソールの起動

Linux package (Omnibus)

こんな人におすすめ

  • シングルノードインスタンス。
  • スケールアウトまたはハイブリッド環境、Patroniノード上、通常はリーダー。
  • スケールアウトまたはハイブリッド環境、PostgreSQLサービスを実行しているサーバ上。
sudo gitlab-psql

シングルノードインスタンス、WebまたはSidekiqノードではRailsデータベースコンソールを使うこともできますが、初期化に時間がかかります:

  • GitLab 14.2以降で

     sudo gitlab-rails db-console --database main
    
  • GitLab 14.1以前の場合:

     sudo gitlab-rails db-console
    
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サービスの一部であるコンソールを使用してください。
  • toolbox ポッドでgitlab-rails db-console を実行してください。

コンソールを終了するには、次のように入力します:quit.

その他の GitLab PostgreSQL ドキュメント

このセクションはGitLabドキュメントの他の情報へのリンクです。

手続き

サポートトピック

データベースのデッドロック

参考文献

ERROR: deadlock detected

イシュー#30528 では、3つのタイムアウトを設定しています:

deadlock_timeout = 5s
statement_timeout = 15s
idle_in_transaction_session_timeout = 60s

イシュー#30528より引用:

“デッドロックが発生し、しばらくしてトランザクションを中断することで解決する場合、すでにある再試行メカニズムがデッドロックが発生した作業を再試行させるので、連続して何度もデッドロックが発生することはないでしょう。”

note
サポートでは、タイムアウトの再設定(HTTPスタックにも適用されます)に対する私たちの一般的なアプローチは、回避策として一時的に行うことは許容されるというものです。それによって GitLab が使えるようになるのであれば、問題をより完全に理解し、ホットフィックスを実装したり、根本的な原因に対処する他の変更を行ったりする時間を稼ぐことができます。一般的に、根本的な原因が解決された後、タイムアウトは合理的なデフォルトに戻すべきです。

この場合、開発者からのガイダンスでは、deadlock_timeout またはstatement_timeout を削除し、3つ目の設定を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 を再設定してください。

note
これらはLinuxパッケージの設定です。顧客のPostgreSQLインストールやAmazon RDSのような外部データベースを使用している場合、これらの値は設定されません。

ステートメントタイムアウトの一時的な変更

caution
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 をコマンドgitlab-ctl stop で停止します。
  2. コマンドでデータベースをシングルユーザーモードにします:

    /opt/gitlab/embedded/bin/postgres --single -D /var/opt/gitlab/postgresql/data gitlabhq_production
    
  3. backend> プロンプトでVACUUM; を実行します。このコマンドの完了には数分かかることがあります。
  4. コマンドが完了するまで待ってから、Control +D を押して終了します。
  5. GitLab をコマンドgitlab-ctl start で起動します。

GitLab データベースの要件

データベースの要件を参照し、必要な拡張機能リストをレビューしてインストールしてください。

production/sidekiq ログでのシリアライズエラー

production/sidekiq のログにこの例のようなエラーが表示された場合は、の設定についてdefault_transaction_isolation をコミットされた に読み込んで問題を解決してください:

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 のトラブルシューティングを行う際には、以下のことを行ってください:

pg_dumppsql バージョンの不一致

この例のようなエラーが発生した場合は、パッケージ化されていない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

Extensionbtree_gist is not allow-listed を参照してください。

Azure Database for PostgreSQL - Flexible Server に PostgreSQL をデプロイすると、このエラーが発生する場合があります:

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

このエラーを解決するには、インストール前に拡張機能を allow-listしてください。