PostgreSQLバージョンの管理

PostgreSQLグローバル開発グループは通常、毎年1回、通常は第3四半期にPostgreSQLのメジャーバージョンをリリースします。私たちの目標は、PostgreSQLの新機能をサポートし採用することと、ユーザがアップグレードすることによるダウンタイムや管理コストのバランスをとることです。GitLabは常に2つのバージョンのPostgreSQLをサポートすることを目指しています。これは、新しいバージョンのPostgreSQLを追加する前に、私たちがサポートしている最も古いバージョンのPostgreSQLを削除し、最低限必要なPostgreSQLのバージョンをメジャーバージョン1つ上げることを意味します。PostgreSQLの削除はGitLabのメジャーリリースでのみ行われます。

ソフトウェアの定義

ソフトウェアの定義は

  • config/software/postgresql_old.rb
  • config/software/postgresql.rb
  • config/software/postgresql_new.rb

デフォルトバージョン

デフォルトでインストールされるバージョンは、「link bin files」ステップを使用して制御します。このステップで定義されたソフトウェアが新規インストールで使用されます。

アップグレード

postgresql_old またはpostgresql からpostgresql_newへのアップグレードには、gitlab-ctl pg-upgrade コマンド を使用します。

自動アップグレード

gitlab-ctl pg-upgrade コマンド はアップグレードの度に実行されます。インストール時に自動的にアップグレードされるPostgreSQLのバージョンと変更したい場合は、upgradeコマンドとrevertコマンドで使用されるデフォルトのバージョンを変更する必要があります。

古いバージョンの削除

古いバージョンを削除するときは、イシューでエピックを作成し、以下を追跡してください：

  1. Omnibusから古いバージョンを削除します。
  2. Helmのインストールから古いバージョンを削除してください。
  3. CIコストを最小化するために、古いバージョンをテストスイートから削除します（これを行う前に、.comが古いバージョンをまだ使っていないか確認してください）。
  4. GitLab ユーザードキュメントの PostgreSQL のそのバージョンへの参照を削除してください。
  5. PostgreSQLのメジャーバージョンが削除される3つ前のGitLabバージョンのリリースポストで、非推奨のお知らせの印刷を開始します。PostgreSQLのバージョンが3リリース以内に削除されるバージョンである場合、Omnibusで管理されているPostgreSQLデータベースであるか外部データベースであるかにかかわらず、管理UIとGitLabのアップグレード処理中に非推奨通知を印刷します。

削除については、以下の手順を実行してください：

  1. 走るgit rm config/software/postgresql_old.rb
  2. 走るgit mv config/software/postgresql{,_old}.rb
  3. config/software/postgresql_old.rb を編集し、名前をpostgresql から次のように変更します。postgresql_old
  4. 走るgit mv config/software/postgresql{_new,}.rb
  5. config/software/postgresql.rb を編集し、名前をpostgresql_new から次のように変更します。postgresql

新しいバージョンの追加

  1. 走るgit cp config/software/postgresql{,_new}.rb

  2. config/software/postgresql_new.rb を編集します。更新してください：

    1. name にpostgresql_new
    2. default_version 新しいバージョンへ
    3. version を新しいバージョンに、そしてsha256
    4. major_version 必要に応じて
  3. 新しいバージョンの PostgreSQL を完全なテストスイートに追加します。
  4. 新しいバージョンの PostgreSQL に対してgitlab-org/gitlab リポジトリのテストを毎晩実行してください。
  5. パッケージのビルドに両方のバージョンのPostgreSQLが含まれていることを確認してください。
  6. Helmのインストールでは、デフォルトのPostgreSQLのChartのバージョンが変更されている場合は更新してください。
  7. ユーザードキュメントを更新してください。

テスト

  1. GitLabは新しいバージョンのPostgreSQLで動作します。
  2. 新しいバージョンのPostgreSQL上でGitLabを10kリファレンスアーキテクチャのスケールでテストし、パフォーマンスの低下をチェックしてください。

以下の環境でのアップグレードと新規インストールのテスト：

  1. シングルノード
  2. Omnibusが管理する独立したデータベースノードでインストールします。
  3. クラスター内に3つ以上のデータベースノードを持つHAデータベースクラスタ。
  4. プライマリノードとセカンダリノードが 1 つずつの Geo インストール (postgresql とgeo-postgresql が同じセカンダリノード上にある)。
  5. プライマリに HA データベース クラスターを持つ Geo インストール。
  6. セカンダリに個別のデータベースと個別のトラッキングデータベースを持つ Geo インストール。
  7. Helmインストール。
  8. 最新バージョンへのアップグレードが機能することをテストした後、revert-pg-upgrade 、Geo セカンダリのスタンドアロン追跡データベースを含め、以前使用していたバージョンへのダウングレードが正常に行われることを確認します。
  9. デフォルトの PostgreSQL バージョンが変更された場合、外部の PostgreSQL データベースで GitLab のアップグレードをテストしてください。

  10. バックアップとリストア。デフォルトの PostgreSQL バージョンが変更される場合：

  11. シングルノードインストール、独立したデータベースノード、HAクラスタでの自動アップグレード。
  12. 外部のPostgreSQLデータベースを使用している場合の自動アップグレード。
  13. Geo インストールは自動アップグレードされません。

最低限必要なバージョンが変更される場合：

  1. 古いバージョンの Omnibus 管理 PostgreSQL がインストールされている場合、GitLab アップグレードはエラーになります。

上記のテストが手動で行われる場合、手動テストが実行された後に導入された変更を見逃してしまう危険性があります。できる限り多くのテストを自動化すべきです。

  1. パッケージのビルドにはPostgreSQLの両方のバージョンが含まれています。
  2. gitlab-ctl pg-upgrade 。

の場合libpq

pyscopg2 を含むいくつかのモジュールはPostgreSQLクライアントライブラリに依存してlibpqいます libpq。libpqこれは常に最新のバンドル版にリンクされるべきです。最新版を使用することで、.NET Frameworkの後方互換性に依存する libpqことになります。

既知のイシュー

Geo はストリーミングレプリケーションを使用しているため、PostgreSQL のメジャーアップグレード後にセカンダリデータベース全体を再同期する必要があります。これは数時間から数日のダウンタイムを引き起こす可能性があるため、Geo の顧客には自動アップグレードを推奨していません。12.10から、Geoが検出された場合、PostgreSQLの自動アップグレードは無効になります。