メンテナンスRakeタスク

GitLabは、一般的なメンテナンス用のRakeタスクを提供します。

GitLabとシステム情報を収集する

このコマンドは、GitLabのインストールと、それが実行されているシステム情報を収集します。これらは、ヘルプを求めたり、イシューを報告したりする際に役立つ場合があります。マルチノード環境では、PostgreSQLソケットエラーを回避するために、GitLab Railsを実行しているノードでこのコマンドを実行します。

• Linuxパッケージインストール:

  sudo gitlab-rake gitlab:env:info

• 自己コンパイルによるインストール:

  bundle exec rake gitlab:env:info RAILS_ENV=production

出力例:

System information
System:         Ubuntu 20.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.7.6p219
Gem Version:    3.1.6
Bundler Version:2.3.15
Rake Version:   13.0.6
Redis Version:  6.2.7
Sidekiq Version:6.4.2
Go Version:     unknown

GitLab information
Version:        15.5.5-ee
Revision:       5f5109f142d
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     13.8
URL:            https://app.gitaly.gcp.gitlabsandbox.net
HTTP Clone URL: https://app.gitaly.gcp.gitlabsandbox.net/some-group/some-project.git
SSH Clone URL:  git@app.gitaly.gcp.gitlabsandbox.net:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:        14.12.0
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
- gitaly:       /var/opt/gitlab/git-data/repositories
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell


Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      15.5.5
- default Git Version:  2.37.1.gl1
- gitaly Address:       tcp://10.128.20.6:2305
- gitaly Version:       15.5.5
- gitaly Git Version:   2.37.1.gl1

GitLabのライセンス情報を表示する

このコマンドは、GitLabライセンスに関する情報と、使用されているシート数を示します。これは、GitLab Enterpriseインストールでのみ使用できます。ライセンスをGitLab Community Editionにインストールすることはできません。

これらは、サポートでチケットを発行する場合や、ライセンスパラメータをプログラムで確認する場合に役立つ場合があります。

• Linuxパッケージインストール:

  sudo gitlab-rake gitlab:license:info

• 自己コンパイルによるインストール:

  bundle exec rake gitlab:license:info RAILS_ENV=production

出力例:

Today's Date: 2020-02-29
Current User Count: 30
Max Historical Count: 30
Max Users in License: 40
License valid from: 2019-11-29 to 2020-11-28
Email associated with license: user@example.com

GitLabの設定をチェック

gitlab:check Rakeタスクは、次のRakeタスクを実行します:

• gitlab:gitlab_shell:check
• gitlab:gitaly:check
• gitlab:sidekiq:check
• gitlab:incoming_email:check
• gitlab:ldap:check
• gitlab:app:check
• gitlab:geo:check（Geoを実行している場合のみ）

各コンポーネントがインストールガイドに従ってセットアップされていることを確認し、見つかったイシューの修正を提案します。このコマンドは、アプリケーションサーバーから実行する必要があり、Gitalyのようなコンポーネントサーバーでは正しく動作しません。

次のトラブルシューティングガイドも参照してください:

• GitLab。
• Linuxパッケージインストール。

また、現在のシークレットを使用してデータベースの値を復号化するできることを確認する必要があります。

gitlab:checkを実行するには、次のように実行します:

• Linuxパッケージインストール:

  sudo gitlab-rake gitlab:check

• 自己コンパイルによるインストール:

  bundle exec rake gitlab:check RAILS_ENV=production

• Kubernetesのインストール:

  kubectl exec -it <toolbox-pod-name> -- sudo gitlab-rake gitlab:check

  HelmベースのGitLabインストールの特定のアーキテクチャにより、gitlab-shell、Sidekiq、およびsystemd関連ファイルへの接続検証で誤検知が発生する場合があります。これらの報告された失敗は予想されるものであり、実際にはイシューを示唆するものではありません。診断結果をレビューする際は無視してください。

SANITIZE=trueをgitlab:checkに使用して、出力からプロジェクト名を省略できます。

出力例:

Checking Environment ...

Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version? ... OK (1.2.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... yes
post-receive hooks in repos are links: ... yes

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes

Checking Sidekiq ... Finished

Checking GitLab App...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config up to date? ... no
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Redis version >= 2.0.0? ... yes

Checking GitLab ... Finished

authorized_keysファイルを再構築する

場合によっては、authorized_keysファイルを再構築する必要があります。たとえば、アップグレード後にSSH経由でプッシュするとPermission denied (publickey)が表示され、ファイルgitlab-shell.logに404 Key Not Foundエラーが表示される場合などです。authorized_keysを再構築するには、次のように実行します:

• Linuxパッケージインストール:

  sudo gitlab-rake gitlab:shell:setup

• 自己コンパイルによるインストール:

  cd /home/git/gitlab
  sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production

出力例:

This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file.
Do you want to continue (yes/no)? yes

Redisキャッシュをクリアする

何らかの理由でダッシュボードに誤った情報が表示される場合は、Redisのキャッシュをクリアしてください。これを行うには、次のように実行します:

• Linuxパッケージインストール:

  sudo gitlab-rake cache:clear

• 自己コンパイルによるインストール:

  cd /home/git/gitlab
  sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production

アセットをプリコンパイルします。

バージョンアップグレード中に、間違ったCSSが発生したり、一部のアイコンが失われたりする可能性があります。その場合は、アセットを再度プリコンパイルしてみてください。

このRakeタスクは、セルフコンパイルインストールにのみ適用されます。詳細については、Linuxパッケージを実行しているときにこのトラブルシューティングを行う方法を参照してください。Linuxパッケージのガイダンスは、KubernetesおよびDockerのGitLabのデプロイにも適用される可能性がありますが、一般に、コンテナベースのインストールでは、アセットの欠落に関するイシューは発生しません。

• 自己コンパイルによるインストール:

  cd /home/git/gitlab
  sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production

Linuxパッケージのインストールでは、最適化されていないアセット（JavaScript、CSS）は、アップストリームGitLabのリリース時にフリーズされます。Linuxパッケージのインストールには、これらのアセットの最適化されたバージョンが含まれています。パッケージをインストールした後、本番マシンでJavaScript / CSSコードを変更しない限り、本番マシンでrake gitlab:assets:compileをやり直す理由はありません。アセットが破損している疑いがある場合は、Linuxパッケージを再インストールする必要があります。

リモートサイトへのTCP接続を確認する

プロキシのイシューを解決するには、GitLabのインストールが別のマシン（たとえば、PostgreSQLまたはWebサーバー）上のTCPサービスに接続できるかどうかを知る必要がある場合があります。このために、Rakeタスクが含まれています。

• Linuxパッケージインストール:

  sudo gitlab-rake gitlab:tcp_check[example.com,80]

• 自己コンパイルによるインストール:

  cd /home/git/gitlab
  sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production

排他的リースをクリア（危険）

GitLabは、共有ロックメカニズムであるExclusiveLeaseを使用して、共有リソースでの同時操作を防止します。例としては、リポジトリで定期的なガベージコレクションを実行することがあります。

非常に特殊な状況では、排他的リースによってロックされた操作は、ロックをリリースせずに失敗する可能性があります。期限切れになるまで待てない場合は、このタスクを実行して手動でクリアできます。

すべての排他的リースをクリアするには:

sudo gitlab-rake gitlab:exclusive_lease:clear

リースtypeまたはリースtype + idを指定するには、スコープを指定します:

# to clear all leases for repository garbage collection:
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*]

# to clear a lease for repository garbage collection in a specific project: (id=4)
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]

データベースの移行のステータスを表示する

GitLabのアップグレード時に移行が完了したことを確認する方法については、バックグラウンド移行のドキュメントを参照してください。

特定の移行のステータスを確認するには、次のRakeタスクを使用できます:

sudo gitlab-rake db:migrate:status

Geoセカンダリサイト上のトラッキングデータベースを確認するには、次のRakeタスクを使用できます:

sudo gitlab-rake db:migrate:status:geo

これにより、各移行のStatusがupまたはdownのテーブルが出力されます。例:

database: gitlabhq_production

 Status   Migration ID    Type     Milestone    Name
--------------------------------------------------
   up     20240701074848  regular  17.2         AddGroupIdToPackagesDebianGroupComponents
   up     20240701153843  regular  17.2         AddWorkItemsDatesSourcesSyncToIssuesTrigger
   up     20240702072515  regular  17.2         AddGroupIdToPackagesDebianGroupArchitectures
   up     20240702133021  regular  17.2         AddWorkspaceTerminationTimeoutsToRemoteDevelopmentAgentConfigs
   up     20240604064938  post     17.2         FinalizeBackfillPartitionIdCiPipelineMessage
   up     20240604111157  post     17.2         AddApprovalPolicyRulesFkOnApprovalGroupRules

GitLab 17.1以降、移行はGitLabリリースケイデンスに準拠した順序で実行されます。

完了していないデータベースの移行を実行する

データベースの移行は、sudo gitlab-rake db:migrate:statusコマンドの出力で、完了していない状態になることがあり、downステータスが表示されます。

1. これらの移行を完了するには、次のRakeタスクを使用します:

   sudo gitlab-rake db:migrate

2. コマンドが完了したら、sudo gitlab-rake db:migrate:statusを実行して、すべての移行が完了したかどうかを確認します（upステータスになっているか）。

3. pumaおよびsidekiqサービスをホットリロードします:

   sudo gitlab-ctl hup puma
   sudo gitlab-ctl restart sidekiq

GitLab 17.1以降、移行はGitLabリリースケイデンスに準拠した順序で実行されます。

データベースのインデックスを再構築する

データベースのインデックスは、定期的に再構築して、領域を再利用し、時間の経過とともにインデックスの健全な肥大化レベルを維持できます。再インデックスは、定期的なcronジョブとして実行することもできます。肥大化の「健全な」レベルは、特定のインデックスに大きく依存しますが、通常は30%0未満である必要があります。

前提要件:

• この機能を使用するには、PostgreSQL 12以降が必要です。
• これらのインデックスタイプはnot supported（サポートされていません）：式のインデックスと、制約除外に使用されるインデックス。

再インデックスを実行する

次のタスクは、各データベースで最も肥大化している2つのインデックスのみを再構築します。3つ以上のインデックスを再構築するには、目的のすべてのインデックスが再構築されるまで、タスクを再度実行します。

1. 再インデックスタスクを実行します:

   sudo gitlab-rake gitlab:db:reindex

2. トラブルシューティングまたは実行を確認するには、application_json.logを確認してください。

再インデックス設定をカスタマイズする

小規模なインスタンスの場合、または再インデックスの動作を調整するには、Railsコンソールを使用してこれらの設定を変更できます:

sudo gitlab-rails console

次に、設定をカスタマイズします:

# Lower minimum index size to 100 MB (default is 1 GB)
Gitlab::Database::Reindexing.minimum_index_size!(100.megabytes)

# Change minimum bloat threshold to 30% (default is 20%, there is no benefit from setting it lower)
Gitlab::Database::Reindexing.minimum_relative_bloat_size!(0.3)

自動再インデックス

データベースサイズが大幅に大きい大規模なインスタンスの場合は、アクティビティーが低い期間に実行するようにスケジュールすることで、データベースの再インデックスを自動化します。

Cronジョブでスケジュールする

パッケージ化されたGitLabインストールの場合、cronジョブを使用します:

1. Cronジョブを編集します:

   sudo crontab -e

2. 優先スケジュールに基づいてエントリを追加します:

   1. オプション1: 静かな期間中に毎日実行する
   # Run database reindexing every day at 21:12
   # The log will be rotated by the packaged logrotate daemon
   12 21 * * * /opt/gitlab/bin/gitlab-rake gitlab:db:reindex >> /var/log/gitlab/gitlab-rails/cron_reindex.log 2>&1

   1. オプション2: 週末のみに実行する
   # Run database reindexing at 01:00 AM on weekends
   0 1 * * 0,6 /opt/gitlab/bin/gitlab-rake gitlab:db:reindex >> /var/log/gitlab/gitlab-rails/cron_reindex.log 2>&1

   1. オプション3: トラフィックの少ない時間帯に頻繁に実行する
   # Run database reindexing every 3 hours during night hours (22:00-07:00)
   0 22,1,4,7 * * * /opt/gitlab/bin/gitlab-rake gitlab:db:reindex >> /var/log/gitlab/gitlab-rails/cron_reindex.log 2>&1

Kubernetesのデプロイの場合、CronJobリソースを使用して同様のスケジュールを作成し、再インデックスタスクを実行できます。

注

• データベースのインデックスの再構築はディスクを大量に使用するタスクであるため、オフピーク時にタスクを実行する必要があります。ピーク時にタスクを実行すると、肥大化が増加し、特定のクエリの実行速度が低下する可能性があります。
• このタスクには、復元するされるインデックス用に空きディスク領域が必要です。作成されたインデックスには_ccnewが付加されます。再インデックスタスクが失敗した場合、タスクを再度実行すると、一時的なインデックスがクリーンアップされます。
• データベースのインデックスの再構築が完了するまでの時間は、ターゲットデータベースのサイズによって異なります。数時間から数日かかる場合があります。
• このタスクはRedisロックを使用しているため、頻繁に実行するようにスケジュールしても安全です。別の再インデックスタスクが既に実行されている場合、操作は行われません。

データベースのスキーマをダンプする

まれに、すべてのデータベースの移行が完了していても、データベースのスキーマがアプリケーションコードで想定されるものと異なる場合があります。これが発生すると、GitLabで奇妙なエラーが発生する可能性があります。

データベースのスキーマをダンプするには:

SCHEMA=/tmp/structure.sql gitlab-rake db:schema:dump

このRakeタスクは、データベースのスキーマダンプを含む/tmp/structure.sqlファイルを作成します。

違いがあるかどうかを判断するには:

1. db/structure.sqlプロジェクトのgitlabファイルに移動します。GitLabバージョンに一致するブランチを選択します。たとえば、GitLab 16.2のファイルはhttps://gitlab.com/gitlab-org/gitlab/-/blob/16-2-stable-ee/db/structure.sqlです。
2. お使いのバージョンのdb/structure.sqlファイルと/tmp/structure.sqlを比較します。

スキーマの不整合についてデータベースをチェックする

このRakeタスクは、スキーマに不整合がないかデータベースをチェックし、それらをターミナルに出力します。このタスクは、GitLabサポートのガイダンスの下で使用される診断ツールです。データベースの不整合が予想される場合があるため、ルーチンチェックにタスクを使用しないでください。

gitlab-rake gitlab:db:schema_checker:run

データベースに関する情報と統計を収集する

gitlab:db:sosコマンドは、GitLabデータベースに関する設定、パフォーマンス、および診断データを収集して、イシューのトラブルシューティングを支援します。このコマンドの実行場所は、設定によって異なります。GitLabがインストールされている場所（(/gitlab)）を基準にして、このコマンドを実行してください。

• Scaled GitLab（スケールされたGitLab）：PumaまたはSidekiqサーバー上。
• Cloud native install（クラウドネイティブインストール）：ツールボックスポッド上。
• All other configurations（その他すべての設定）：GitLabサーバー上。

必要に応じてコマンドを変更します:

• Default path（デフォルト） パス - デフォルトのファイルパス（/var/opt/gitlab/gitlab-rails/tmp/sos.zip）でコマンドを実行するには、gitlab-rake gitlab:db:sosを実行します。
• Custom path（カスタム） パス - ファイルパスを変更するには、gitlab-rake gitlab:db:sos["/absolute/custom/path/to/file.zip"]を実行します。
• Zsh users（Zshユーザー） - Zsh設定を変更していない場合は、次のようにコマンド全体を引用符で囲む必要があります：gitlab-rake "gitlab:db:sos[/absolute/custom/path/to/file.zip]"

Rakeタスクは5分間実行されます。指定したパスに圧縮フォルダーが作成されます。圧縮フォルダーには、多数のファイルが含まれています。

オプションのクエリ統計データを有効にする

gitlab:db:sosRakeタスクは、pg_stat_statements拡張機能を使用して、遅いクエリのトラブルシューティングを行うためのデータを収集することもできます。

この拡張機能を有効にするのはオプションであり、PostgreSQLとGitLabを再起動する必要があります。このデータは、遅いデータベースによって引き起こされるGitLabのパフォーマンスイシューのトラブルシューティングに必要となる可能性があります。

前提要件:

• 拡張機能を有効または無効にするには、スーパーユーザー特権を持つPostgreSQLユーザーである必要があります。

1. データベースコンソールで、以下を実行します:

   CREATE EXTENSION pg_stat_statements;

2. 拡張機能が動作していることを確認します:

   SELECT extname FROM pg_extension WHERE extname = 'pg_stat_statements';
   SELECT * FROM pg_stat_statements LIMIT 10;

重複するCI/CDタグについてデータベースをチェックする

このRakeタスクは、ciデータベースのtagsテーブルで重複するタグをチェックします。このイシューは、長期間にわたって複数のメジャーアップグレードが行われたインスタンスに影響を与える可能性があります。次のコマンドを実行して重複するタグを検索し、重複するタグを参照するタグの割り当てを書き換えて、代わりに元のタグを使用します。

sudo gitlab-rake gitlab:db:deduplicate_tags

このコマンドをドライランモードで実行するには、環境変数DRY_RUN=trueを設定します。

PostgreSQL照合バージョンの不一致を検出する

PostgreSQL照合チェッカー:

• データベースとオペレーティングシステム間の照合バージョンの不一致を検出し、インデックスの破損を引き起こす可能性があります。PostgreSQLは、文字列照合（並べ替えおよび比較ルール）にオペレーティングシステムのglibcライブラリを使用します。
• 照合の不一致が原因で破損しやすいことがわかっている、事前定義されたインデックスセットで、破損のスポットチェック（重複検出）を実行します。これらのインデックスは、照合の不一致が原因で破損しやすいことがわかっています。

基盤となるglibcライブラリを変更するオペレーティングシステムのアップグレード後に、このタスクを実行します。

前提要件:

• PostgreSQL 13以降。

PostgreSQL照合の不一致と、関連するインデックスの破損をすべてのデータベースでチェックするには:

sudo gitlab-rake gitlab:db:collation_checker

特定のデータベースをチェックするには:

# Check main database
sudo gitlab-rake gitlab:db:collation_checker:main

# Check CI database
sudo gitlab-rake gitlab:db:collation_checker:ci

テーブルサイズの制限を調整する

デフォルトでは、データベースのパフォーマンスに影響を与える可能性のある、実行時間の長いクエリを回避するために、1 GBを超えるテーブルはスキップされます。MAX_TABLE_SIZE環境変数を設定して、テーブルサイズのしきい値を調整できます。

# Set custom table size limit (in bytes)
# to increase the max table size threshold to 10 GB
MAX_TABLE_SIZE=10737418240 sudo gitlab-rake gitlab:db:collation_checker:main

実行時間の長いクエリに対するPgBouncerの回避

トラブルシューティングセクションのステートメントタイムアウトエラーの解決を参照してください。

出力例

問題が見つからない場合:

Checking for PostgreSQL collation mismatches on main database...
No collation mismatches detected on main.
Found 8 indexes to corruption spot check.
No corrupted indexes detected.

不一致が検出された場合、タスクは、影響を受けるインデックスを修正するための修正手順を提供します。

不一致がある場合の出力例:

Checking for PostgreSQL collation mismatches on main database...
⚠️ COLLATION MISMATCHES DETECTED on main database!
2 collation(s) have version mismatches:
  - en_US.utf8: stored=428.1, actual=513.1
  - es_ES.utf8: stored=428.1, actual=513.1

Found 8 indexes to corruption spot check.
Affected indexes that need to be rebuilt:
  - index_projects_on_name (btree) on table projects
    • Issues detected: duplicates
    • Affected columns: name
    • Type: UNIQUE
    • Needs deduplication: Yes

REMEDIATION STEPS:
1. Put GitLab into maintenance mode
2. Run the following SQL commands:

# Step 1: Check for duplicate entries in unique indexes
SELECT name, COUNT(*), ARRAY_AGG(id) FROM projects GROUP BY name HAVING COUNT(*) > 1 LIMIT 1;

# If duplicates exist, you may need to use gitlab:db:deduplicate_tags or similar tasks
# to fix duplicate entries before rebuilding unique indexes.

# Step 2: Rebuild affected indexes
# Option A: Rebuild individual indexes with minimal downtime:
REINDEX INDEX CONCURRENTLY index_projects_on_name;

# Option B: Alternatively, rebuild all indexes at once (requires downtime):
REINDEX DATABASE main;

# Step 3: Refresh collation versions
ALTER DATABASE main REFRESH COLLATION VERSION;

3. Take GitLab out of maintenance mode

PostgreSQLの照合順序の問題と、それがデータベースインデックスにどのように影響するかについて詳しくは、PostgreSQLのOSアップグレードに関するドキュメントを参照してください。

破損したデータベースインデックスの修復

インデックス修復ツールは、データの整合性の問題を引き起こす可能性のある、破損または欠落しているデータベースインデックスを修正します。このツールは、照合順序の不一致やその他の破損の問題によって影響を受ける、特定の問題のあるインデックスに対応します。このツール:

• 一意のインデックスが破損している場合、データを重複排除します。
• データの整合性を維持するために参照を更新します。
• 正しい設定でインデックスを再構築または作成します。

インデックスを修復する前に、ドライランモードでツールを実行して、潜在的な変更を分析します:

sudo DRY_RUN=true gitlab-rake gitlab:db:repair_index

次の出力例は、変更点を示しています:

INFO -- : DRY RUN: Analysis only, no changes will be made.
INFO -- : Running Index repair on database main...
INFO -- : Processing index 'index_merge_request_diff_commit_users_on_name_and_email'...
INFO -- : Index is unique. Checking for duplicate data...
INFO -- : No duplicates found in 'merge_request_diff_commit_users' for columns: name,email.
INFO -- : Index exists. Reindexing...
INFO -- : Index reindexed successfully.

すべてのデータベース内の既知の問題のあるすべてのインデックスを修復するには:

sudo gitlab-rake gitlab:db:repair_index

このコマンドは、各データベースを処理し、インデックスを修復します。例:

INFO -- : Running Index repair on database main...
INFO -- : Processing index 'index_merge_request_diff_commit_users_on_name_and_email'...
INFO -- : Index is unique. Checking for duplicate data...
INFO -- : No duplicates found in 'merge_request_diff_commit_users' for columns: name,email.
INFO -- : Index does not exist. Creating new index...
INFO -- : Index created successfully.
INFO -- : Index repair completed for database main.

特定のデータベースのインデックスを修復するには:

# Repair indexes in main database
sudo gitlab-rake gitlab:db:repair_index:main

# Repair indexes in CI database
sudo gitlab-rake gitlab:db:repair_index:ci

実行時間の長いクエリに対するPgBouncerの回避

トラブルシューティングセクションのステートメントタイムアウトエラーの解決を参照してください。

トラブルシューティング

アドバイザリロック接続情報

db:migrate Rakeタスクを実行すると、次のような出力が表示されることがあります:

main: == [advisory_lock_connection] object_id: 173580, pg_backend_pid: 5532
main: == [advisory_lock_connection] object_id: 173580, pg_backend_pid: 5532

返されるメッセージは情報提供を目的としたものであり、無視できます。

gitlab:env:info Rakeタスク実行時のPostgreSQLソケットエラー

Gitalyなどの非Railsノードでsudo gitlab-rake gitlab:env:infoを実行すると、次のエラーが表示されることがあります:

PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?

これは、マルチノード環境では、gitlab:env:info Rakeタスクは、GitLab Railsを実行しているノードでのみ実行する必要があるためです。

ステートメントタイムアウトエラーの解決

GitLabインスタンスでPgBouncerを使用しており、データベースのメンテナンスタスク（照合順序チェッカーやインデックス修復など）中にステートメントタイムアウトが発生した場合は、直接PostgreSQL接続を使用してPgBouncerを回避します。

# Example with direct connection
GITLAB_BACKUP_PGUSER=postgres GITLAB_BACKUP_PGHOST=localhost sudo gitlab-rake gitlab:db:collation_checker

GITLAB_BACKUP_PGUSER=postgres GITLAB_BACKUP_PGHOST=localhost sudo gitlab-rake gitlab:db:repair_index

サポートされている環境変数:

• GITLAB_BACKUP_PGHOST
• GITLAB_BACKUP_PGUSER
• GITLAB_BACKUP_PGPORT
• GITLAB_BACKUP_PGPASSWORD

PgBouncerの回避方法と、サポートされている環境変数の完全なリストについて詳しくは、PgBouncerを回避する手順を参照してください。