PostgreSQL

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

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

ここにドキュメント化されている一部の手順は、GitLabインスタンスを破損させる可能性があります。ご自身の責任においてご利用ください。

有料プランをご利用で、これらのコマンドの使用方法が不明な場合は、発生している問題についてサポートにお問い合わせください。

データベースコンソールを起動します

推奨される利用環境:

シングルノードインスタンス。
通常リーダーであるPatroniノード上の、スケールアウトされた環境またはハイブリッド環境。
スケールアウトされた環境またはハイブリッド環境（PostgreSQLサービスを実行しているサーバー上）。

sudo gitlab-psql

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

sudo gitlab-rails dbconsole --database main

docker exec -it <container-id> gitlab-psql

PostgreSQLのインストールに含まれるpsqlコマンドを使用します。

sudo -u git -H psql -d gitlabhq_production

ハイブリッド環境で、PostgreSQLがLinuxパッケージインストール（Omnibus）で実行されている場合は、これらのサーバーでローカルにデータベースコンソールを使用することをお勧めします。Linuxパッケージの詳細を参照してください。
外部のサードパーティPostgreSQLサービスの一部であるコンソールを使用します。
toolboxポッドでgitlab-rails dbconsoleを実行します。
- 詳細については、Kubernetesチートシートを参照してください。

コンソールを終了するには、quitと入力します。

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

このセクションは、GitLabドキュメント内の他の場所へのリンク用です。

手順

以下を含むLinuxパッケージインストールのためのデータベース手順:
- SSL：有効化、無効化、および検証。
- Write Ahead Log（WAL）のアーカイブの有効化。
- 外部（非Omnibus）PostgreSQLインストールの使用、およびそのバックアップ。
- ソケットに加えて、またはソケットの代わりに、TCP/IPでリッスン。
- 別の場所にデータを保存。
- GitLabデータベースの破壊的な再シード。
- パッケージ化されたPostgreSQLの更新に関するガイダンス（自動的に更新されないようにする方法を含む）。
外部PostgreSQLに関する情報。
外部PostgreSQLでGeoを実行しています。
HA用に構成されたPostgreSQLを実行している場合のアップグレード。
CI Runner内からPostgreSQLを使用します。
Linuxパッケージ開発ドキュメントから、LinuxパッケージインストールでのPostgreSQLバージョンの管理。
PostgreSQLのスケール
- gitlab-ctl patroni check-leaderおよびPgBouncerエラーのトラブルシューティングを含みます。
デベロッパーデータベースドキュメント。一部は本番環境用ではありません。以下を含みます:
- EXPLAINプランについて理解する

サポートトピック

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

参照:

インスタンスがプッシュでいっぱいになると、デッドロックが発生する可能性があります。GitLabコードが異常な状況でこの種の予期しない影響を与える可能性がある方法に関するコンテキストを提供しました。

ERROR: deadlock detected

3つの適用可能なタイムアウトがイシュー#30528で特定されています。推奨設定は次のとおりです:

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

イシュー#30528から引用:

「デッドロックが発生し、短期間でトランザクションを中断することでそれを解決する場合、すでに持っている再試行メカニズムにより、デッドロックした作業が再度試行され、連続して複数回デッドロックが発生する可能性は低くなります。」

サポートでは、タイムアウトの再構成（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を再構成します。

これらは、Linuxパッケージの設定です。顧客のPostgreSQLインストールやAmazon RDSなどの外部データベースが使用されている場合、これらの値は設定されず、外部で設定する必要があります。

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

PgBouncerが有効になっている場合、変更されたタイムアウトが意図したよりも多くのトランザクションに影響を与える可能性があるため、以下のアドバイスは適用されません。

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_db_config[:variables]"
```
別のタイムアウトが必要なアクション（たとえば、バックアップまたはRailsコンソールコマンド）を実行します。
/var/opt/gitlab/gitlab-rails/etc/database.ymlの編集を元に戻します。

(RE)INDEXの進捗レポートを監視する

状況によっては、CREATE INDEXまたはREINDEX操作の進捗状況を監視したい場合があります。たとえば、CREATE INDEXまたはREINDEX操作がアクティブであるかどうかを確認したり、操作がどのフェーズにあるかを確認したりするために、これを行うことができます。

前提要件:

PostgreSQLバージョン12以降を使用する必要があります。

CREATE INDEXまたはREINDEX操作を監視するには:

組み込みのpg_stat_progress_create_indexビューを使用します。

たとえば、データベースコンソールセッションから、次のコマンドを実行します:

SELECT * FROM  pg_stat_progress_create_index \watch 0.2

人間にとってわかりやすい出力の作成とデータをログファイルに書き込む方法の詳細については、このスニペットを参照してください。

トラブルシューティング

データベース接続が拒否されました

次のエラーが発生した場合は、安定した接続を確保するためにmax_connectionsが十分に高いかどうかを確認してください。

connection to server at "xxx.xxx.xxx.xxx", port 5432 failed: Connection refused
      Is the server running on that host and accepting TCP/IP connections?

psql: error: connection to server on socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432" failed:
FATAL:  sorry, too many clients already

max_connectionsを調整するには、複数のデータベース接続の構成を参照してください。

データベースは、データ損失のラップアラウンドを回避するためにコマンドを受け入れていません

このエラーは、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-ctl stopでGitLabを停止します。
次のコマンドを使用して、データベースをシングルユーザーモードにします:
```
/opt/gitlab/embedded/bin/postgres --single -D /var/opt/gitlab/postgresql/data gitlabhq_production
```
backend>プロンプトで、VACUUM;を実行します。このコマンドが完了するまでに数分かかる場合があります。
コマンドが完了するのを待ってから、Control + Dを押して終了します。
コマンドgitlab-ctl startでGitLabを起動します。

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に関する問題をトラブルシューティングする場合は、次のようにする必要があります:

一般的な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

拡張機能`btree_gist`が許可リストに登録されていません

PostgreSQL用Azureデータベース-フレキシブルサーバーにPostgreSQLをデプロイすると、次のエラーが発生する可能性があります:

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

このエラーを解決するには、インストールする前に拡張機能を許可リストに登録します。