データベース設定

GitLabはPostgreSQLデータベース管理システムのみをサポートしています。

したがって、Linuxパッケージのインストールで使うデータベースサーバーには2つの選択肢があります：

  • Linuxパッケージのインストールに含まれるパッケージ化されたPostgreSQLサーバを使用する（設定不要、推奨）。
  • 外部のPostgreSQLサーバを使用します。

Linuxパッケージに同梱されているPostgreSQLデータベースサービスを使用します。

再設定とPostgreSQLの再起動

Linux パッケージインストールでは通常、gitlab.rb ファイルでサービスの設定が変更された場合、reconfigure 時にサービスを再起動します。PostgreSQLは、リロード（(HUP)）で有効になる設定もあれば、PostgreSQLを再起動しなければならない設定もあるという点でユニークです。管理者はPostgreSQLが再起動されるタイミングをより正確に制御したいと思うことが多いため、Linuxパッケージインストールでは、再起動ではなく、再設定時にPostgreSQLの再読み込みを行うように設定されています。つまり、再起動が必要なPostgreSQLの設定を変更した場合、再設定後に手動でPostgreSQLを再起動する必要があります。

GitLabの設定テンプレートは、どのPostgreSQLの設定が再起動を必要とし、どの設定が再読み込みのみを必要とするかを識別します。データベースに対してクエリを実行して、個々の設定に再起動が必要かどうかを調べることもできます。データベースコンソールをsudo gitlab-psql で起動し、次のクエリの<setting name> を変更する設定で置き換えてください：

SELECT name,setting FROM pg_settings WHERE context = 'postmaster' AND name = '<setting name>';

設定を変更することで再起動が必要になる場合、クエリは設定の名前と実行中のPostgreSQLインスタンスにおけるその設定の現在の値を返します。

PostgreSQLのバージョン変更時の自動再起動

デフォルトでは、Linuxパッケージのインストールでは、アップストリームドキュメントで推奨されているように、PostgreSQLのバージョンが変更されると自動的にPostgreSQLを再起動します。この動作は、postgresql とgeo-postgresqlで利用可能なauto_restart_on_version_change 設定を使用して制御することができます。

PostgreSQLのバージョン変更時の自動再起動を無効にするには、以下のようにしてください：

  1. /etc/gitlab/gitlab.rb を編集し、以下の行を追加します：

    # For PostgreSQL/Patroni
postgresql['auto_restart_on_version_change'] = false
   
# For Geo PostgreSQL
geo_postgresql['auto_restart_on_version_change'] = false

  2. GitLab を再設定します：

    sudo gitlab-ctl reconfigure
note
必要なライブラリの読み込みに関するエラーのようなものを避けるために、PostgreSQLのバージョンが変わったときにはPostgreSQLを再起動することを強く推奨します。

SSLの設定

Linuxパッケージインストールは自動的にPostgreSQLサーバのSSLを有効にしますが、デフォルトでは暗号化された接続と暗号化されていない接続の両方を受け付けます。SSLを強制するには、pg_hba.conf のhostssl 設定を使用する必要があります。詳細はpg_hba.conf ドキュメントを参照してください。

SSLのサポートは以下のファイルに依存します：

  • データベースの公開 SSL 証明書 (server.crt)。
  • SSL 証明書に対応する秘密鍵 (server.key)。
  • サーバーの証明書を検証するルート証明書バンドル (root.crt)。デフォルトでは、Linuxパッケージのインストールは/opt/gitlab/embedded/ssl/certs/cacert.pem の組み込み証明書バンドルを使用します。これは自己署名証明書には必要ありません。

Linux パッケージインストールでは、10 年間の自己署名証明書と秘密鍵が生成され使用されます。CA 署名証明書を使用したい場合、または自己署名証明書に置き換えたい場合は、以下の手順を使用します。

これらのファイルの場所は設定できますが、秘密鍵はユーザーが読める_必要が_あることに注意してくださいgitlab-psql 。Linuxのパッケージ・インストールはファイルの権限を管理してくれますが、パスがカスタマイズ gitlab-psqlされている場合は、ファイルが置かれているディレクトリにアクセスできるようにするgitlab-psql 必要が gitlab-psqlあります。

詳細はPostgreSQLのドキュメントを参照してください。

server.crt とserver.key は、GitLab にアクセスするためのデフォルトの SSL 証明書とは異なる可能性があることに注意してください。例えば、データベースの外部ホスト名がdatabase.example.com で、GitLab の外部ホスト名がgitlab.example.comだとします。この場合、*.example.com のワイルドカード証明書が必要になるか、2つの異なるSSL証明書が必要になります。

ssl_cert_file 、ssl_key_file 、ssl_ca_file ファイルは、PostgreSQLに証明書、鍵、バンドルをファイルシステム上のどこに置くかを指示します。これらの変更はpostgresql.confに適用されます。internal_certificate とinternal_key のディレクティブは、これらのファイルの内容を設定するために使用されます。内容は直接追加することも、以下の例のようにファイルから読み込むこともできます。

これらのファイルができたら、SSL を有効にします：

  1. /etc/gitlab/gitlab.rb を編集します：

    postgresql['ssl_cert_file'] = '/custom/path/to/server.crt'
postgresql['ssl_key_file'] = '/custom/path/to/server.key'
postgresql['ssl_ca_file'] = '/custom/path/to/bundle.pem'
postgresql['internal_certificate'] = File.read('/custom/path/to/server.crt')
postgresql['internal_key'] = File.read('/custom/path/to/server.key')

    相対パスはPostgreSQLデータディレクトリ（デフォルトでは/var/opt/gitlab/postgresql/data ）をルートとします。

  2. GitLabを再設定して設定変更を適用します。

  3. 変更を有効にするために PostgreSQL を再起動します：

    gitlab-ctl restart postgresql

    PostgreSQLの起動に失敗した場合は、ログ（例えば、/var/log/gitlab/postgresql/current ）で詳細を確認してください。

SSLを要求

  1. /etc/gitlab/gitlab.rb に以下を追加してください：

    gitlab_rails['db_sslmode'] = 'require'

  2. GitLabを再設定して設定変更を適用します。

  3. 変更を有効にするために PostgreSQL を再起動します：

    gitlab-ctl restart postgresql

    PostgreSQLの起動に失敗した場合は、ログ（例えば、/var/log/gitlab/postgresql/current ）で詳細を確認してください。

SSLの無効化

  1. /etc/gitlab/gitlab.rb に以下を追加してください：

    postgresql['ssl'] = 'off'

  2. GitLabを再設定して設定変更を適用します。

  3. 変更を有効にするために PostgreSQL を再起動します：

    gitlab-ctl restart postgresql

    PostgreSQLの起動に失敗した場合は、ログ（例えば、/var/log/gitlab/postgresql/current ）で詳細を確認してください。

SSLが使用されていることの確認

SSLがクライアントによって使用されているかどうかを確認するには、以下を実行します：

GitLab 14.2以降で：

sudo gitlab-rails dbconsole --database main

GitLab 14.1以前の場合：

sudo gitlab-rails dbconsole

起動時に以下のようなバナーが表示されます：

psql (9.6.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: on)
Type "help" for help.

クライアントがSSLを使用しているかどうかを調べるには、次のSQLクエリをイシューします：

SELECT * FROM pg_stat_ssl;

使用例：

gitlabhq_production=> select * from pg_stat_ssl;
 pid  | ssl | version |         cipher         | bits | compression |  clientdn
------+-----+---------+------------------------+------+-------------+------------
  384 | f   |         |                        |      |             |
  386 | f   |         |                        |      |             |
  998 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
  933 | f   |         |                        |      |             |
 1003 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1016 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1022 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1211 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1214 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1213 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1215 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
 1252 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           |
 1280 | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | /CN=gitlab
  382 | f   |         |                        |      |             |
  381 | f   |         |                        |      |             |
  383 | f   |         |                        |      |             |
(16 rows)
  1. ssl 列の下にt が表示されている行は有効です。
  2. clientdn に値がある行は、cert 認証方法を使用しています。

SSLクライアント認証の設定

クライアント SSL 証明書を使用して、データベース・サーバを認証できます。証明書の作成はomnibus-gitlab の範囲を超えていますが、既存の SSL 証明書管理ソリューションを持っているユーザーはこれを使用できます。

データベースサーバーの設定
  1. サーバ用の証明書と鍵を作成します。コモンネームはサーバのDNS名と同じにします。
  2. サーバの証明書、鍵、CAファイルをPostgreSQLサーバにコピーし、権限が正しいことを確認してください。
    1. 証明書はデータベースユーザが所有する必要があります（デフォルト：gitlab-psql ）。
    2. 鍵ファイルの所有者はデータベース・ユーザーでなければなりません。0400
    3. CAファイルはデータベースユーザーが所有し、その権限は0400
    note
    これらのファイルにはserver.crt またはserver.key というファイル名を使用しないでください。これらのファイル名はomnibus-gitlabの内部使用のために予約されています。

  3. gitlab.rb で以下のように設定されていることを確認してください：

    postgresql['ssl_cert_file'] = 'PATH_TO_CERTIFICATE'
postgresql['ssl_key_file'] = 'PATH_TO_KEY_FILE'
postgresql['ssl_ca_file'] = 'PATH_TO_CA_FILE'
postgresql['listen_address'] = 'IP_ADDRESS'
postgresql['cert_auth_addresses'] = {
'IP_ADDRESS' => {
  'database' => 'gitlabhq_production',
  'user' => 'gitlab'
}

    クライアントがデータベースへの接続に使用するサーバの IP アドレスをlisten_address に設定します。Ensurecert_auth_addresses には、IP アドレス、データベースへの接続を許可するデータベースとユーザーのリストが含ま cert_auth_addressesれます。cert_auth_addresses キーを指定するときに CIDR 表記を使用 cert_auth_addressesすると、IP アドレスの範囲を組み込むことができます。

  4. 新しい設定を有効にするには、gitlab-ctl reconfigure を実行し、gitlab-ctl restart postgresql を実行します。

Railsクライアントの設定

railsクライアントがサーバに接続するには、commonName をgitlab に設定した証明書と鍵が必要です。この証明書は、データベースサーバのssl_ca_file で指定されたCAファイルで信頼されている作成者によって署名されています。

  1. 設定gitlab.rb

    gitlab_rails['db_host'] = 'IP_ADDRESS_OR_HOSTNAME_OF_DATABASE_SERVER'
gitlab_rails['db_sslcert'] = 'PATH_TO_CERTIFICATE_FILE'
gitlab_rails['db_sslkey'] = 'PATH_TO_KEY_FILE'
gitlab_rails['db_rootcert'] = 'PATH_TO_CA_FILE'
  2. Railsクライアントで新しい設定を使用するためにgitlab-ctl reconfigure 。
  3. SSLが使用されていることを確認する」の手順に従って、認証が機能していることを確認します。

パッケージ化されたPostgreSQLサーバがTCP/IPで待ち受けるように設定します。

パッケージ化されたPostgreSQLサーバはTCP/IP接続を待ち受けるように設定することができますが、一部の重要でないスクリプトはUNIXソケットを期待し、誤動作する可能性があります。

データベースサービスでTCP/IPを使用する設定を行うには、gitlab.rb のpostgresql とgitlab_rails の両セクションを変更してください。

PostgreSQLブロックの設定

postgresql ブロックでは以下の設定が影響します：

  • listen_address:PostgreSQLがリッスンするアドレスを制御します。
  • port:PostgreSQLがリッスンするポートを制御します。デフォルトは5432 です。
  • md5_auth_cidr_addresses:パスワードによる認証後にサーバへの接続を許可するCIDRアドレスブロックのリストです。
  • trust_auth_cidr_addresses:認証なしでサーバーへの接続を許可する CIDR アドレスブロックのリスト。この設定には十分注意してください。 127.0.0.1/24 のループバックアドレスか、あるいは127.0.0.1/32のループバックアドレスに限定することをお勧めします。
  • sql_user:MD5 認証で使用するユーザ名を指定します。デフォルトはgitlab で、必須の設定ではありません。
  • sql_user_password:PostgreSQLがMD5認証で受け付けるパスワードを設定します。以下の例のsecuresqlpassword を使用可能なパスワードに置き換えてください。

  1. /etc/gitlab/gitlab.rb を編集します：

    postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432
postgresql['md5_auth_cidr_addresses'] = %w()
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/24)
postgresql['sql_user'] = "gitlab"
   
##! SQL_USER_PASSWORD_HASH can be generated using the command `gitlab-ctl pg-password-md5 gitlab`,
##! where `gitlab` is the name of the SQL user that connects to GitLab.
postgresql['sql_user_password'] = "SQL_USER_PASSWORD_HASH"
   
# force ssl on all connections defined in trust_auth_cidr_addresses and md5_auth_cidr_addresses
postgresql['hostssl'] = true

  2. GitLabを再設定し、PostrgreSQLを再起動します：

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart postgresql

ネットワーク経由で接続するクライアントやGitLabサービスは、PostgreSQLサーバに接続する際に設定に提供されたユーザ名とパスワードにsql_user 。また、これらの値はmd5_auth_cidr_addresses

GitLab Railsブロックの設定

gitlab-rails アプリケーションがネットワーク経由で PostgreSQL データベースに接続するように設定するには、いくつかの設定を行う必要があります：

  • db_host:データベースサーバの IP アドレスを設定する必要があります。これがPostgreSQLサービスと同じインスタンス上にある場合は、127.0.0.1 、パスワード認証を_必要と_しません。
  • db_port:接続するPostgreSQLサーバのポートを_設定_します。db_host 。
  • db_username:PostgreSQLに接続するユーザ名を設定します。デフォルトはgitlab です。
  • db_password:TCP/IP経由でPostgreSQLに接続する場合、また、上記の設定からpostgresql['md5_auth_cidr_addresses'] ブロックのインスタンスから接続する場合は、必ず指定してください。127.0.0.1 に接続し、postgresql['trust_auth_cidr_addresses'] を含むように設定した場合は不要です。

  1. /etc/gitlab/gitlab.rb を編集します：

    gitlab_rails['db_host'] = '127.0.0.1'
gitlab_rails['db_port'] = 5432
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "securesqlpassword"

  2. GitLabを再設定し、PostrgreSQLを再起動します：

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart postgresql

サービスの適用と再起動

前述の変更を行った後、管理者はgitlab-ctl reconfigure を実行してください。サービスがTCPをリッスンしていないというイシューが発生した場合は、gitlab-ctl restart postgresql でサービスを直接再起動してみてください。

Linuxパッケージの内部スクリプト（gitlab-psql など）の中には、PostgreSQLへの接続がUNIXソケットで処理されることを期待しているものがあり、正しく機能しないことがあります。UNIXソケットを無効にすることなくTCP/IPを有効にすることができます。

PostgreSQL WAL（Write Ahead Log）アーカイブの有効化

デフォルトでは、パッケージ化されたPostgreSQLのWALアーカイブは有効になっていません。WALアーカイブを有効にする場合は、以下を考慮してください：

  • WALレベルは’replica’以上である必要があります（9.6+のオプションはminimal 、replica 、またはlogical ）。
  • WALレベルを上げると、通常のオペレーションで消費されるストレージの量が増えます。

WALアーカイブを有効にするには

  1. /etc/gitlab/gitlab.rb を編集します：

    # Replication settings
postgresql['sql_replication_user'] = "gitlab_replicator"
postgresql['wal_level'] = "replica"
    ...
    ...
# Backup/Archive settings
postgresql['archive_mode'] = "on"
postgresql['archive_command'] = "/your/wal/archiver/here"
postgresql['archive_timeout'] = "60"

  2. 変更を有効にするためにGitLabを再設定します。その結果、データベースが再起動します。

PostgreSQL のデータを別のディレクトリに保存します。

デフォルトでは、全ては/var/opt/gitlab/postgresql 、postgresql['dir'] 属性で制御された場所に格納されます。

これは

  • データベースソケットは/var/opt/gitlab/postgresql/.s.PGSQL.5432 です。これはpostgresql['unix_socket_directory'] で制御されます。
  • gitlab-psql システムユーザーはHOME ディレクトリをこのディレクトリに設定します。これはpostgresql['home'] によって制御されます。
  • 実際のデータは/var/opt/gitlab/postgresql/data に保存されます。

PostgreSQLデータの場所を変更するには

caution
既存のデータベースがある場合は、まずデータを新しい場所に移動する必要があります。
caution
これは面倒なオペレーションです。既存のインストールでダウンタイムなしに行うことはできません。
  1. 既存のインストールであれば、GitLab を停止してください:gitlab-ctl stop.
  2. postgresql['dir'] を目的の場所に更新します。
  3. gitlab-ctl reconfigure を実行してください。
  4. GitLab の起動gitlab-ctl start.

PostgreSQL サーバのアップグレード

Linuxパッケージには、パッケージ化されたPostgreSQLサーバを（パッケージに含まれていれば）新しいバージョンに更新するためのgitlab-ctl pg-upgrade コマンドがあります。これは、特にオプトアウトしない限り、パッケージのアップグレード中にPostgreSQLをデフォルトの出荷時のバージョンに更新します。

caution
アップグレードする前に、コマンドを実行する前にこのセクションを十分に読むことがインポートです。シングルノードインストールの場合、このアップグレードにはダウンタイムが必要です。時間の長さはデータベースのサイズに依存します。
note
アップグレード中に何か問題が発生した場合は、omnibus-gitlab のイシュー・トラッカーに詳しい説明を添えてイシューを提起してください。

PostgreSQL のバージョンをアップグレードするには、以下のことを確認してください：

  • 現在の PostgreSQL のバージョンをサポートする GitLab の最新バージョンを実行していること。
  • 最近アップグレードした場合は、先に進む前にsudo gitlab-ctl reconfigure を実行してください。

  • データベースのコピーを 2 部作成するのに十分なディスク容量があります。十分な空き容量がない限り、アップグレードを試みないでください。

    • sudo du -sh /var/opt/gitlab/postgresql/data を使用してデータベースサイズを確認してください（またはデータベースパスを更新してください）。
    • sudo df -h を使用して使用可能な領域を確認します。データベースが存在するパーティションに十分な空き容量がない場合は、引数--tmp-dir $DIR をコマンドに渡してください。GitLab 13.3 以降では、利用可能なディスク容量のチェックが含まれており、要件を満たしていない場合はアップグレードを中止します。

上記のチェックリストが満たされていることを確認したら、アップグレードを続行できます：

sudo gitlab-ctl pg-upgrade
note
pg-upgrade 例えば、基礎となるコマンドの実行タイムアウトを設定できます (--timeout=1d2h3m4s5ms)。gitlab-ctl pg-upgrade -h を実行すると、全リストが表示されます。

gitlab-ctl pg-upgrade は以下のステップを実行します：

  1. データベースが既知の良好な状態であることを確認します。
  2. ディスクに十分な空き容量があるかどうかをチェックし、なければ中止します。--skip-disk-check フラグを追加することでこれをスキップできます。
  3. 既存のデータベースと不要なサービスをシャットダウンし、GitLabがページをデプロイできるようにします。
  4. /opt/gitlab/embedded/bin/ for PostgreSQL のシンボリックリンクを新しいバージョンのデータベースを指すように変更します。
  5. 既存のデータベースとロケールが一致する、新しい空のデータベースを含む新しいディレクトリを作成します。
  6. pg_upgrade ツールを使用して、古いデータベースから新しいデータベースにデータをコピーします。
  7. 古いデータベースを移動します。
  8. 新しいデータベースを目的の場所に移動します。
  9. sudo gitlab-ctl reconfigure を呼び出して必要な設定変更を行い、新しいデータベースサーバーを起動します。
  10. ANALYZE を実行してデータベース統計を生成します。
  11. 残りのサービスを開始し、デプロイページを削除します。
  12. この処理中にエラーが検出された場合、古いバージョンのデータベースに戻します。

アップグレードが完了したら、すべてが期待どおりに動作していることを確認します。

ANALYZE ステップ実行中の出力にエラーがあった場合、アップグレードはまだ動作していますが、データベースの統計情報が生成されるまではデータベースのパフォーマンスが低下します。ANALYZE を手動で実行すべきかどうかを判断するには、gitlab-psql を使用します：

sudo gitlab-psql -c "SELECT relname, last_analyze, last_autoanalyze FROM pg_stat_user_tables WHERE last_analyze IS NULL AND last_autoanalyze IS NULL;"

上記のクエリで行が返された場合は、ANALYZE を手動で実行できます：

sudo gitlab-psql -c 'SET statement_timeout = 0; ANALYZE VERBOSE;'

_GitLab インスタンスが正しく_動作していることを確認したら、古いデータベースファイルをクリーンアップします：

sudo rm -rf /var/opt/gitlab/postgresql/data.<old_version>
sudo rm -f /var/opt/gitlab/postgresql-version.old

GitLabの様々なバージョンに同梱されているPostgreSQLのバージョンの詳細は、Linuxパッケージに同梱されているPostgreSQLのバージョンに記載されています。

PostgreSQL の自動アップグレードのオプトアウト

GitLabパッケージのアップグレード時にPostgreSQLの自動アップグレードを行わないようにするには、以下を実行します：

sudo touch /etc/gitlab/disable-postgresql-upgrade

GitLab 16.2 以降

GitLab 16.2では、PostgreSQL 13.11と14.8がLinuxパッケージに同梱されています。パッケージのアップグレード中、データベースはPostgreSQL 14にアップグレードされません。PostgreSQL 14にアップグレードしたい場合は、手動で行う必要があります：

sudo gitlab-ctl pg-upgrade -V 14

PostgreSQL 14はGeoデプロイではサポートされておらず、将来のリリースでサポートされる予定です。

GitLab 16.0 以降

PostgreSQLバージョン12はサポートされなくなり、バイナリは削除されました。続行するには、管理者は

  1. インストールがPostgreSQL 13を使用していることを確認してください。

GitLab 15.11以降であること

GitLab 15.11では、以下の場合を除き、PostgreSQLは自動的に13.xにアップグレードされます：

以下の場合はアップグレードがスキップされます：

  • Patroni を使用してデータベースを高可用性で実行している場合。
  • データベースノードはGitLab Geo設定の一部です。
  • あなたは特にオプトアウトしています。
  • postgresql['version'] = 12 。gitlab.rb

フォールトトレラントおよびGeoインストールはPostgreSQL 13への手動アップグレードをサポートしています。

GitLab 15.0 以降

GitLab 15.0では、新規インストールのデフォルトはPostgreSQL 13です。

既存のシングルデータベースノードインスタンスは手動で更新することができます：

sudo gitlab-ctl pg-upgrade -V 13

PostgreSQL 12が削除されるまでは、互換性やテスト環境のために必要であれば、管理者はPostgreSQLのバージョンを固定することができます。

フォールトトレラントやGeoのインストールには追加の手順と計画が必要です。

GitLab 14.0 以降

PostgreSQLバージョン11はサポートされなくなり、バイナリは削除されました。続行するには、管理者は

  1. インストールがPostgreSQL 12を使用していることを確認してください。
  2. repmgrを使用している場合、patroniを使用するように変換してください。

パッケージ化されたPostgreSQLサーバーを以前のバージョンに戻します。

caution
このオペレーションは、_データを含む_現在のデータベースを前回のアップグレード前の状態に戻します。パッケージ化されたPostgreSQLデータベースをダウングレードする前に、必ずバックアップを作成してください。

複数の PostgreSQL バージョンが同梱されている GitLab バージョンでは、gitlab-ctl revert-pg-upgrade コマンドを使って、すでにアップグレード済みの PostgreSQL バージョンを以前のバージョンにダウングレードすることができます。このコマンドは、パッケージ内に2つ以上のPostgreSQLバージョンが同梱されているシナリオ（例えば、PostgreSQL 9.6.x、10.x、11.xが同梱されているGitLab 12.8）のために、ターゲットバージョンを指定する-V フラグもサポートしています。

ターゲットPostgreSQLのバージョンを12：

gitlab-ctl revert-pg-upgrade -V 12

ターゲットバージョンを指定しない場合、/var/opt/gitlab/postgresql-version.old にあるバージョンが利用可能であればそれを使用します。そうでなければ、GitLabに同梱されているデフォルトのバージョンにフォールバックします。

PostgreSQLのバージョンが1つしかない他のGitLabのバージョンでは、PostgreSQLのバージョンをダウングレードすることはできません。そのためには、GitLabを古いバージョンにダウングレードする必要があります。

複数のデータベース接続の設定

gitlab:db:decomposition:connection_status RakeタスクはGitLab 15.11で導入されました。

GitLab 16.0では、GitLabはデフォルトで同じPostgreSQLデータベースを指す2つのデータベース接続を使用します。

GitLab 16.0にアップグレードする前に、PostgreSQLのmax_connections 設定が十分に高く、利用可能な接続の50%以上が未使用として表示さ max_connectionsれることを確認してください。例えば、100に設定されていて75の接続が使用中と表示されているmax_connections 場合 max_connections、アップグレード前にmax_connections を少なくとも150に増やす必要があります。アップグレード後は、使用中の接続が倍の150になってしまうからです。

これは、以下の Rake タスクを実行することで確認できます：

sudo gitlab-rake gitlab:db:decomposition:connection_status

タスクがmax_connections が十分に高いことを示せば、アップグレードを続行できます。

何らかの理由で単一接続のままにしておきたい場合、GitLab 15.11以前からGitLab 16.0にアップグレードする場合、または単一データベース接続に戻す場合は、/etc/gitlab/gitlab.rb でこの設定を更新してください：

gitlab_rails['databases']['ci']['enable'] = false

パッケージ化されていないPostgreSQLデータベース管理サーバーを使用する場合

デフォルトでは、GitLabはLinuxパッケージに含まれるPostgreSQLサーバーを使うように設定されています。外部のPostgreSQLインスタンスを使うように再設定することもできます。

caution
パッケージ化されていないPostgreSQLサーバーを使う場合は、データベース要件文書に従ってPostgreSQLが設定されていることを確認する必要があります。

  1. 編集/etc/gitlab/gitlab.rb ：

    # Disable the built-in Postgres
postgresql['enable'] = false
   
# Fill in the connection details for database.yml
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
gitlab_rails['db_host'] = '127.0.0.1'
gitlab_rails['db_port'] = 5432
gitlab_rails['db_username'] = 'USERNAME'
gitlab_rails['db_password'] = 'PASSWORD'

    これらの行の先頭にある# のコメント文字を削除することを忘れないでください。

    注意してください：

    • /etc/gitlab/gitlab.rb プレーンテキストのパスワードが含まれているため、ファイルの権限は0600 。

    • PostgreSQLは複数のアドレスで待ち受けることができます。

      gitlab_rails['db_host'] に複数のアドレスをカンマ区切りで指定した場合、リストの最初のアドレスが接続に使用されます。

  2. 変更を有効にするには、GitLabを再設定してください。

  3. データベースをシードします。

パッケージ化されていないPostgreSQLのUNIXソケット設定

GitLabにバンドルされているPostgreSQLサーバーではなく、（GitLabと同じシステムにインストールされている）自分のシステムのPostgreSQLサーバーを使いたい場合は、UNIXソケットを使うことで実現できます：

  1. /etc/gitlab/gitlab.rb を編集します：

    # Disable the built-in Postgres
postgresql['enable'] = false
   
# Fill in the connection details for database.yml
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
# The path where the socket lives
gitlab_rails['db_host'] = '/var/run/postgresql/'

  2. 変更を有効にするために GitLab を再設定します：

    sudo gitlab-ctl-reconfigure

SSLの設定

SSLを要求

  1. /etc/gitlab/gitlab.rb に以下を追加してください：

    gitlab_rails['db_sslmode'] = 'require'

  2. GitLabを再設定して設定変更を適用します。

  3. 変更を有効にするために PostgreSQL を再起動します：

    gitlab-ctl restart postgresql

    PostgreSQLの起動に失敗した場合は、ログ（例えば、/var/log/gitlab/postgresql/current ）で詳細を確認してください。

SSLを要求し、CAバンドルに対してサーバ証明書を検証してください。

PostgreSQLはなりすましを防ぐために、SSLを要求し、CAバンドルに対してサーバ証明書を検証するように設定することができます。gitlab_rails['db_sslrootcert'] で指定されるCAバンドルにはルート証明書と中間証明書の両方が含まれていなければなりません。

  1. /etc/gitlab/gitlab.rb に以下を追加してください：

    gitlab_rails['db_sslmode'] = "verify-full"
gitlab_rails['db_sslrootcert'] = "<full_path_to_your_ca-bundle.pem>"

    PostgreSQL サーバに Amazon RDS を使用している場合、gitlab_rails['db_sslrootcert'] 用の結合 CA バンドルをダウンロードし、使用していることを確認してください。これに関する詳細は、AWS の記事using SSL/TLS to Encrypt a Connection to a DB Instanceにあります。

  2. GitLabを再設定して設定変更を適用します。

  3. 変更を有効にするために PostgreSQL を再起動します：

    gitlab-ctl restart postgresql

    PostgreSQLの起動に失敗した場合は、ログ（例えば、/var/log/gitlab/postgresql/current ）で詳細を確認してください。

パッケージ化されていないPostgreSQLデータベースのバックアップとリストア

Rake backup create and restore taskを使うとき、GitLabはパッケージ化されたpg_dump コマンドを使ってデータベースのバックアップファイルを作成し、パッケージ化されたpsql コマンドを使ってバックアップをリストアしようとします。これは正しいバージョンでなければ動作しません。パッケージ化されたpg_dump とpsqlのバージョンを確認してください：

/opt/gitlab/embedded/bin/pg_dump --version
/opt/gitlab/embedded/bin/psql --version

これらのバージョンがパッケージ化されていない外部PostgreSQLと異なる場合、Rakeバックアップ作成タスクを実行しようとすると、以下のエラー出力が発生する可能性があります：

Dumping PostgreSQL database gitlabhq_production ... pg_dump: error: server version: 13.3; pg_dump version: 12.6
pg_dump: error: aborting because of server version mismatch

この例では、GitLab 14.1でデフォルトのPostgreSQLバージョン12.6ではなくPostgreSQLバージョン13.3を使用した場合にエラーが発生します。

この場合、データベースのバージョンに合ったツールをインストールし、以下の手順に従ってください。PostgreSQLクライアントツールをインストールする方法は複数あります。オプションについてはhttps://www.postgresql.org/download/ を参照してください。

正しいpsql とpg_dump ツールがシステムで使用できるようになったら、新しいツールをインストールした場所への正しいパスを使用して、以下の手順に従ってください：

  1. パッケージ化されていないバージョンにシンボリックリンクを追加します：

    ln -s /path/to/new/pg_dump /path/to/new/psql /opt/gitlab/bin/

  2. バージョンの確認

    /opt/gitlab/bin/pg_dump --version
/opt/gitlab/bin/psql --version

    パッケージ化されていない外部のPostgreSQLと同じになっているはずです。

これが終わったら、バックアップと リストアの両方のタスクを実行して、バックアップとリストアのタスクが正しい実行ファイルを使用していることを確認してください。

パッケージ化されていないPostgreSQLデータベースのアップグレード

データベースに接続しているすべてのプロセス（Puma、Sidekiq）を停止した後、外部データベースをアップグレードできます：

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

アップグレードを行う前に、以下の点に注意してください：

  • GitLab のリリースと PostgreSQL のバージョンの互換性を確認してください：
    • GitLabのどのバージョンでPostgreSQLの最低バージョンの要件が導入されたかをお読みください。
    • Linuxパッケージに同梱されているPostgreSQLのバージョンに対する重要な変更について読んでください：Linuxパッケージは、同梱されているPostgreSQLのメジャーリリースとの互換性がテストされています。
  • GitLabのバックアップやリストアを使用する場合、同じバージョンのGitLabを維持する_必要が_あります。GitLabのバージョンも新しいものにアップグレードする予定なら、まずPostgreSQLをアップグレードしてください。
  • バックアップと復元のRakeタスクは、データベースをバックアップし、PostgreSQLの後のバージョンに復元するために使うことができます。
  • そのLinuxパッケージリリースに同梱されていないPostgreSQLのバージョンがpostgresql['version'] で指定された場合、どのクライアントバイナリ（PostgreSQLのバックアップ/リストアバイナリなど）が有効になるかは互換性テーブルのデフォルトバージョンによって決まります。

以下の例は、PostgreSQL 12を実行しているデータベースホストからPostgreSQL 13を実行している別のデータベースホストへのアップグレードを示すもので、ダウンタイムが発生します：

  1. データベース要件に従って設定された新しいPostgreSQL 13データベースサーバをスピンアップします。

  2. 互換性のあるバージョンのpg_dump とpg_restore が GitLab Rails インスタンスで使用されていることを確認します。GitLabの設定を変更するには、/etc/gitlab/gitlab.rb を編集し、postgresql['version'] の値を指定します：

    postgresql['version'] = 13

  3. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

  4. GitLabを停止します（このステップはダウンタイムを引き起こすことに注意してください）：

    sudo gitlab-ctl stop
caution
インストールでPgBouncerを使っている場合、backupコマンドには追加のパラメータが必要です。

  1. データベースのみをバックアップするためにSKIPオプションを使用してバックアップRakeタスクを実行します。バックアップファイル名を控えておいてください。

    sudo gitlab-backup create SKIP=repositories,uploads,builds,artifacts,lfs,pages,registry

  2. PostgreSQL 12データベースホストをシャットダウンします。

  3. /etc/gitlab/gitlab.rb を編集し、gitlab_rails['db_host'] の設定を PostgreSQL 13 データベースホストを指すように更新します。

  4. GitLab を再設定します：

    sudo gitlab-ctl reconfigure
    caution
    インストールでPgBouncerを使っている場合、backupコマンドには追加のパラメータが必要です。

  5. 先に作成したデータベースのバックアップファイルを使ってデータベースをリストアし、”This task will now rebuild the authorized_keys file “と聞かれたら、必ず “No “と答えてください：

    # Use the backup timestamp https://docs.gitlab.com/ee/raketasks/backup_restore.html#backup-timestamp
sudo gitlab-backup restore BACKUP=<backup-timestamp>

  6. GitLab を起動します：

    sudo gitlab-ctl start

  7. PostgreSQLを新しいメジャーリリースにアップグレードした後：

    • (AWSが推奨する)Amazon RDS、または
    • データベースサーバーのCPU使用率が非常に高い（100％に近い）場合。

    テーブル統計を再作成することで、効率的なクエリプランが選択され、データベースサーバのCPU負荷が軽減されます。

    PostgreSQLデータベースコンソールで以下のクエリを実行してください：

    SET statement_timeout = 0; ANALYZE VERBOSE;

データベースのシード（新規インストールのみ）

caution
これは破壊的なコマンドです。既存のデータベースでは実行しないでください。

Linux パッケージのインストールでは、外部データベースはシードされません。以下のコマンドを実行してスキーマをインポートし、最初の管理ユーザーを作成します：

# Remove 'sudo' if you are the 'git' user
sudo gitlab-rake gitlab:setup

デフォルトのroot ユーザーにパスワードを指定する場合は、上記のgitlab:setup コマンドを実行する前に、/etc/gitlab/gitlab.rb でinitial_root_password 設定を指定してください：

gitlab_rails['initial_root_password'] = 'nonstandardpassword'

共有GitLab Runnerの初期登録トークンを指定したい場合は、gitlab:setup コマンドを実行する前に、/etc/gitlab/gitlab.rb でinitial_shared_runners_registration_token 設定を指定してください：

gitlab_rails['initial_shared_runners_registration_token'] = 'token'

パッケージ化された PostgreSQL のバージョンを固定します（新規インストールのみ）。

note
GitLab 14.1以降はPostgreSQL 12とPostgreSQL 13の両方が同梱されています。GitLab 14.0にはPostgreSQL 12のみが同梱されています。GitLab 13.3以降はPostgres 11とPostgres 12の両方が同梱されています。GitLab 13.0 から 13.2 は PostgreSQL 11 のみ対応。

Linuxパッケージのインストールでは、PostgreSQLはデフォルトのバージョンで初期化されます。

デフォルト以外のバージョンでPostgreSQLを初期化するには、postgresql['version'] 、最初の再構成の前にパッケージ化されたPostgreSQLのバージョンの1つをメジャーバージョンに設定します。例えば、GitLab 15.0では、postgresql['version'] = 12 、デフォルトのPostgreSQL 13の代わりにPostgreSQL 12を使うことができます。

caution
最初の再設定後にLinuxパッケージに同梱されているPostgreSQLを使用しているときにpostgresql['version'] 。データディレクトリが異なるバージョンのPostgreSQLで初期化されているというエラーが発生します。この場合は、パッケージ化されたPostgreSQLサーバを以前のバージョンに戻してくださいを参照してください。

以前にGitLabがインストールされていた環境に新規インストールを行う場合で、固定されたPostgreSQLのバージョンを使っている場合は、まずPostgreSQLに関連するフォルダがすべて削除されていることと、インスタンス上でPostgreSQLのプロセスが実行されていないことを確認してください。

トラブルシューティング

default_transaction_isolation 。read committed

production/sidekiq のログに以下のようなエラーが表示された場合：

ActiveRecord::StatementInvalid PG::TRSerializationFailure: ERROR:  could not serialize access due to concurrent update

データベースのdefault_transaction_isolation 設定が GitLab アプリケーションの要件と一致していない可能性があります。PostgreSQLデータベースに接続し、SHOW default_transaction_isolation; を実行することで、この設定を確認することができます。GitLabアプリケーションはread committed が設定されていることを期待しています。

このdefault_transaction_isolation の設定はpostgresql.conf ファイルに設定されています。設定を変更したら、データベースをリスタート/リロードする必要があります。この設定は、Linuxパッケージに含まれるパッケージ化されたPostgreSQLサーバーにデフォルトで入っています。

ライブラリをロードできませんでした。plpgsql.so

データベースのマイグレーションを実行しているときや、PostgreSQL/Patroniのログに以下のようなエラーが表示されることがあります：

ERROR:  could not load library "/opt/gitlab/embedded/postgresql/12/lib/plpgsql.so": /opt/gitlab/embedded/postgresql/12/lib/plpgsql.so: undefined symbol: EnsurePortalSnapshotExists

このエラーはPostgreSQLのバージョン変更後にPostgreSQLを再起動しなかったために発生します。このエラーを修正するには、以下の手順を実行してください：

  1. 以下のコマンドのいずれかを実行してください：

    # For PostgreSQL
sudo gitlab-ctl restart postgresql
   
# For Patroni
sudo gitlab-ctl restart patroni
   
# For Geo PostgreSQL
sudo gitlab-ctl restart geo-postgresql

  2. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

データベースのアプリケーション設定

データベースの自動マイグレーションの無効化

複数のGitLabサーバーでデータベースを共有している場合、再設定中にマイグレーションステップを実行するノードの数を制限したいと思うでしょう。

/etc/gitlab/gitlab.rb を編集して追加します：

# Enable or disable automatic database migrations
# on all hosts except the designated deploy node
gitlab_rails['auto_migrate'] = false

/etc/gitlab/gitlab.rb プレーンテキストのパスワードが含まれているため、ファイル権限0600 を設定する必要があります。

上記の設定を持つホストが次に再設定された場合、マイグレーションステップは実行されません。

スキーマに関連したアップグレード後のエラーを避けるために、デプロイノードとしてマークされたホストはアップグレード中にgitlab_rails['auto_migrate'] = true 。

クライアント・ステートメント・タイムアウトの設定

Railsがデータベーストランザクションの完了を待ってからタイムアウトするまでの時間を、gitlab_rails['db_statement_timeout'] 。デフォルトでは、この設定は使用されません。

/etc/gitlab/gitlab.rb を編集します：

gitlab_rails['db_statement_timeout'] = 45000

この場合、クライアントstatement_timeout は 45 秒に設定されます。値はミリ秒単位で指定します。

接続タイムアウトの設定

RailsがPostgreSQL接続に成功してからタイムアウトするまでの時間は、gitlab_rails['db_connect_timeout'] 。デフォルトでは、この設定は使用されません：

  1. /etc/gitlab/gitlab.rb を編集します：

    gitlab_rails['db_connect_timeout'] = 5

  2. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

この場合、クライアントconnect_timeout は5秒に設定されます。値は秒単位で指定します。最小値は2秒です。これを<= 0 に設定するか、設定をまったく指定しないと、タイムアウトは無効になります。

TCP制御の設定

RailsのPostgreSQLアダプタは一連のTCP接続制御を提供しており、これをチューニングすることでパフォーマンスを向上させることができます。各パラメータの詳細についてはPostgreSQLのアップストリームドキュメントを参照してください。

Linuxパッケージはこれらの値にデフォルトを設定せず、代わりにPostgreSQLアダプタが提供するデフォルトを使用します。以下の表に示すパラメータを使用して、gitlab.rb でこれらの値を上書きし、gitlab-ctl reconfigure を実行してください。

PostgreSQLパラメータ｜gitlab.rb パラメータ｜-｜-｜｜keepalives ｜gitlab_rails['db_keepalives'] ｜keepalives_idle ｜gitlab_rails['db_keepalives_idle'] ｜keepalives_interval ｜gitlab_rails['db_keepalives_interval'] ｜keepalives_count ｜gitlab_rails['db_keepalives_count'] ｜tcp_user_timeout ｜gitlab_rails['db_tcp_user_timeout'] ｜。

データベースの自動再インデックス作成

GitLab 13.5 で導入されました。

caution
これは実験的な機能で、デフォルトでは有効になっていません。

データベースインデックスをバックグラウンドで再作成します（「再インデックス作成」と呼ばれます）。これは、インデックスに蓄積された肥大化した領域を除去し、健全で効率的なインデックスを維持するために使用できます。

インデックス再作成タスクはcronjobで定期的に開始することができます。cronjobを設定するには、gitlab_rails['database_reindexing']['enable'] をtrue に設定しなければなりません。

複数ノード環境では、この機能はアプリケーションホスト上でのみ有効にしてください。インデックス再作成処理はPgBouncerを経由することはできません。

デフォルトでは、週末（トラフィックの少ない時間帯）だけ1時間ごとにcronjobを開始します。

以下の設定を変更することでスケジュールを変更することができます：

  1. /etc/gitlab/gitlab.rb を編集します：

    gitlab_rails['database_reindexing']['hour'] = '*'
gitlab_rails['database_reindexing']['minute'] = 0
gitlab_rails['database_reindexing']['month'] = '*'
gitlab_rails['database_reindexing']['day_of_month'] = '*'
gitlab_rails['database_reindexing']['day_of_week'] = '0,6'

  2. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

パッケージ化された PostgreSQL を HA/Geo クラスターにデプロイ

GitLab HAクラスタのアップグレード

PatroniクラスタのPostgreSQLバージョンをアップグレードするには、PatroniクラスタのPostgreSQLメジャーバージョンのアップグレードを参照してください。

GitLab HA Repmgrクラスタのアップグレード

note
PostgreSQL 12にアップグレードする場合は、RepmgrからPatroniに切り替える必要があります。

これらの手順は、Repmgrを使用している場合に古いGitLabクラスターをPostgreSQL 11にアップグレードするために提供されています。

PostgreSQLが高可用性に設定されている場合、pg-upgrade 、PostgreSQLが稼働しているすべてのノードで実行する必要があります。他のノードはスキップすることができますが、データベースノードと同じGitLabバージョンを実行している必要があります。

以下の手順に従って、データベースノードをアップグレードしてください：

  1. セカンダリノードはプライマリノードより先にアップグレードする必要があります。
    1. セカンダリノードで、/etc/gitlab/gitlab.rb を編集して、以下を含めます：
    # Replace X with the number of DB nodes + 1
postgresql['max_replication_slots'] = X
    1. gitlab-ctl reconfigure を実行して設定を更新します。
    2. 新しい設定でPostgreSQLを再起動するためにsudo gitlab-ctl restart postgresql 。
    3. PostgreSQLのセカンダリノードでpg-upgrade を実行すると、そのノードはクラスターから削除されます。
    4. 全てのセカンダリノードがpg-upgrade を使用してアップグレードされると、ユーザはプライマリノードのみが存在するシングルノードクラスタになります。
    5. pg-upgradeセカンダリノードでは、既存のデータはプライマリノードのデータに置き換えられるため、新しいバージョンに合わせて更新されません。しかし、既存のデータはバックアップの場所に移動されます。
  2. すべてのセカンダリノードのアップグレードが完了したら、プライマリノードでpg-upgrade を実行します。
    1. プライマリ・ノードで、/etc/gitlab/gitlab.rb を編集して以下を含めます：
    # Replace X with the number of DB nodes + 1
postgresql['max_replication_slots'] = X
    1. gitlab-ctl reconfigure を実行して設定を更新します。
    2. 新しい設定でPostgreSQLを再起動するためにsudo gitlab-ctl restart postgresql 。
    3. プライマリノードでは、pg-upgrade 、既存のデータを新しいPostgreSQLのバージョンに合わせて更新します。

  3. 各セカンダリノードで以下のコマンドを実行して、セカンダリノードを再作成します。

    gitlab-ctl repmgr standby setup MASTER_NODE_NAME

  4. repmgrクラスタが元の状態に戻っているか確認します。

    gitlab-ctl repmgr cluster show

HAクラスタでのアップグレードのトラブルシューティング

ある時点で、HAセットアップにアップグレードする前にバンドルされたPostgreSQLがノード上で動作していた場合、古いデータディレクトリが残っている可能性があります。これは、gitlab-ctl reconfigure 、そのノードで使用するPostgreSQLユーティリティのバージョンをダウングレードする原因となります。これを防ぐには、ディレクトリを移動（または削除）してください：

  • mv /var/opt/gitlab/postgresql/data/ /var/opt/gitlab/postgresql/data.$(date +%s)

セカンダリノードをgitlab-ctl repmgr standby setup MASTER_NODE_NAME で再作成する際に以下のエラーが発生した場合は、postgresql['max_replication_slots'] = X (X は DB ノードの数 + 1) が/etc/gitlab/gitlab.rb に含まれていることを確認してください：

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はデフォルトでPostgreSQLのストリーミングレプリケーションに依存しているため、GitLabのアップグレード時やPostgreSQLのアップグレード時に考慮すべき点があります。

Geo で PostgreSQL をアップグレードする際の注意点

caution
Geo を使用している場合、PostgreSQL のアップグレードにはすべてのセカンダリのダウンタイムが必要です。

Geo を使用している場合、PostgreSQL をアップグレードすると、Geoセカンダリへの PostgreSQL レプリケーションを再初期化する必要があるため、すべてのセカンダリでダウンタイムが発生します。これはPostgreSQLのストリーミングレプリケーションの仕組みによるものです。レプリケーションの再初期化はプライマリからすべてのデータを再度コピーするため、データベースのサイズと利用可能な帯域幅に大きく依存しますが、長い時間がかかります。例えば、転送速度が30Mbps、データベースサイズが100GBの場合、再同期には約8時間かかります。詳細はPostgreSQLのドキュメントを参照してください。

PostgreSQLの自動アップグレードの無効化

GitLab 12.1からGitLab 12.9までは、GitLabパッケージのアップグレードはPostgreSQLをバージョン10.xにアップグレードしようとします。GitLab 12.10以降では、Geoを使用している場合、PostgreSQLのアップグレードは無人で行われません。

GitLab 12.1からGitLab 12.9にアップグレードする前に、意図しないダウンタイムを避けるために、PostgreSQLの無人アップグレードを無効にし、GitLabパッケージのアップグレードとは別に手動でPostgreSQLをアップグレードすることを強くお勧めします。

PostgreSQL の無人アップグレードを無効にするには、postgresql またはgeo-postgresqlを実行しているすべてのノードで以下を実行します：

sudo touch /etc/gitlab/disable-postgresql-upgrade

Geo 使用時に PostgreSQL をアップグレードする方法

PostgreSQLをアップグレードするには、レプリケーションスロットの名前とレプリケーションユーザーのパスワードが必要です。

  1. Geoプライマリのデータベースノードで既存のレプリケーションスロットの名前を見つけ、実行します：

    sudo gitlab-psql -qt -c 'select slot_name from pg_replication_slots'

    ここでslot_name が見つからない場合、または出力が返されない場合は、Geo セカンダリが健全でない可能性があります。その場合は、セカンダリが健全でレプリケーションが機能していることを確認してください。

  2. レプリケーションユーザーのパスワードを集めます。これは手順 1 で Geo をセットアップする際に設定したものです。プライマリ サイトを設定します。

  3. Geo プライマリの PostgreSQL を手動でアップグレードします。Geo プライマリのデータベースノードで実行します：

    sudo gitlab-ctl pg-upgrade

    次のステップを開始する前にプライマリデータベースのアップグレードが完了するのを待ちます。その後、セカンダリデータベースと並行してトラッキングデータベースをアップグレードできます。

  4. Geo セカンダリの PostgreSQL を手動でアップグレードします。Geoセカンダリデータベースと 追跡データベースで実行します：

    sudo gitlab-ctl pg-upgrade

  5. コマンドを使用して、Geoセカンダリデータベースのデータベースレプリケーションを再起動します：

    sudo gitlab-ctl replicate-geo-database --slot-name=SECONDARY_SLOT_NAME --host=PRIMARY_HOST_NAME

    プライマリのレプリケーションユーザーのパスワードの入力を求められます。SECONDARY_SLOT_NAME を上記の最初のステップで取得したスロット名に置き換えてください。

  6. Geo セカンダリデータベース上でGitLabを再設定し、pg_hba.conf ファイルを更新します。これはreplicate-geo-database がプライマリのファイルをセカンダリにレプリケートするために必要です。

  7. puma,sidekiq,geo-logcursor を再起動します。

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

  8. https://your_primary_server/admin/geo/nodes に移動し、すべてのノードが正常であることを確認します。

PostgreSQLデータベースへの接続

PostgreSQLデータベースに接続する必要がある場合、アプリケーションユーザーとして接続することができます：

GitLab 14.2以降で：

sudo gitlab-rails dbconsole --database main

GitLab 14.1以前の場合：

sudo gitlab-rails dbconsole

またはPostgreSQLのスーパーユーザーとして：

sudo gitlab-psql -d gitlabhq_production