• データベースコンソールの起動
• その他の GitLab PostgreSQL ドキュメント
  • 手続き
• サポートトピック
  • データベースのデッドロック
  • ステートメントタイムアウトの一時的な変更
• トラブルシューティング
  • ラップアラウンド・データ・ロスを避けるためにデータベースがコマンドを受け付けない
  • GitLab データベースの要件
  • production/sidekiq ログでのシリアライズエラー
  • PostgreSQLレプリケーションスロットエラー
  • Geoレプリケーションエラー
  • Geo 設定とよくあるエラーのレビュー
  • pg_dump とpsql バージョンの不一致
  • Extensionbtree_gist is not allow-listed を参照してください。

PostgreSQL

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

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

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

sudo gitlab-psql

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

sudo -u git -H psql -d gitlabhq_production

コンソールを終了するには、次のように入力します: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パッケージインストールにおけるPostgreSQLバージョンの管理。

• PostgreSQLのスケーリング
  • gitlab-ctl patroni check-leader 、PgBouncerエラーのトラブルシューティングを含みます。
• 開発者向けのデータベースドキュメント。を含みます：
  • EXPLAIN計画の理解。

サポートトピック

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

参考文献

• イシュー #1 GitLab 12.1、PostgreSQL 10.7 でデッドロック。
• GitLab 12.1.6とGoogle doc (内部).
• イシュー#2 インスタンスにプッシュが殺到するとデッドロックが発生する可能性があります。GitLabのコードが通常とは異なる状況でこのような予期せぬ効果をもたらす可能性があることを説明しました。

ERROR: deadlock detected

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

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

イシュー#30528より引用：

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

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

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

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

• 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

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してください。