PostgreSQL

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

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

ここに記載されているいくつかの手順は、お使いの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サービスの一部であるコンソールを使用してください。
ツールボックスポッドでgitlab-rails dbconsoleを実行します。
- 詳細については、Kubernetesチートシートを参照してください。

マネージドPostgreSQLサービス（AWS RDSなど）を使用するクラウドネイティブデプロイの場合、データベース設定ファイルを直接変更することはできません。代わりに、クラウドサービスのパラメータグループまたは設定インターフェースを介してPostgreSQLパラメータを設定します。

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

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

このセクションは、GitLabドキュメントの他の場所にある情報へのリンクです。

手順

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

Supportトピック

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

参照:

インスタンスがプッシュで溢れると、デッドロックが発生する可能性があります。GitLabのコードが、異常な状況でこのような予期せぬ影響をどのように与えるかについて、コンテキストを提供します。

ERROR: deadlock detected

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

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

イシュー#30528からの引用:

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

Supportでは、タイムアウトを再構成する（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

Linuxパッケージインストールの場合

ステートメントタイムアウトを一時的に変更するには:

/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の編集を元に戻します。

クラウドネイティブデプロイの場合

マネージドPostgreSQLサービス（AWS RDS、Azure Database for PostgreSQL、Google Cloud SQLなど）を使用するクラウドネイティブデプロイの場合、データベース設定ファイルを直接変更することはできません。代わりに、クラウドサービスのパラメータグループまたは設定インターフェースを介してstatement_timeoutパラメータを設定します:

AWS RDS: データベースインスタンスに関連付けられたパラメータグループを変更し、statement_timeoutを0（無制限）に設定します。
Azure Database for PostgreSQL: Azureポータルでサーバーパラメータを更新し、statement_timeoutを0に設定します。
Google Cloud SQL: データベースフラグを変更し、statement_timeoutを0に設定します。

パラメータグループまたは設定に変更を加えた後、変更を有効にするためにデータベースインスタンスを再起動する必要がある場合があります。特定の指示については、クラウドプロバイダーのドキュメントを参照してください。

（再）インデックス進捗レポートの監視

特定の状況では、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`は許可リストにありません

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

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

このエラーを解決するには、インストール前に拡張機能を許可リストに追加してください。