正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

GitLab 16アップグレードノート

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

このページでは、GitLab 16のマイナーバージョンとパッチバージョンのアップグレード情報を提供します。以下について手順を確認してください:

  • お使いのインストールタイプ。
  • 現在のバージョンと移行先バージョンとの間にあるすべてのバージョン。

Helmチャートインストールに関する追加情報については、Helmチャート7.0アップグレードノートを参照してください。

15.11からのアップグレード時に注意すべき問題

  • PostgreSQL 12は、GitLab 16以降ではサポートされていません。GitLab 16.0以降にアップグレードする前に、PostgreSQLを少なくともバージョン13.6にアップグレードしてください。

  • GitLabインスタンスが最初に15.11.0、15.11.1、または15.11.2にアップグレードされた場合、データベーススキーマが正しくありません。16.xにアップグレードする前に、回避策を実行してください。

  • 16.0以降、GitLab Self-Managedインストールでは、デフォルトのデータベース接続数が、1つではなく、2つになりました。この変更により、PostgreSQL接続の数が2倍になります。これにより、GitLabのSelf-ManagedバージョンはGitLab.comと同様に動作するようになり、GitLabのSelf-ManagedバージョンでCI機能用に別のデータベースを有効にするための第一歩となります。16.0にアップグレードする前に、PostgreSQLの最大接続数を増やす必要があるかどうかを判断してください。

    • この変更は、Linuxパッケージ（Omnibus）、GitLab Helmチャート、GitLab Operator、GitLab Dockerイメージ、および自己コンパイルインストールによるインストール方法に適用されます。
    • 2番目のデータベース接続は無効にできます。

  • ほとんどのインストールでは、アップグレードパスで最初に経由する必要があるバージョンが16.3であるため、16.0、16.1、および16.2をスキップできます。すべての場合において、これらの中間バージョンに関するノートを確認する必要があります。

    一部のGitLabインストールでは、使用する機能と環境のサイズに応じて、これらの中間バージョンを経由する必要があります:

    • 16.0.8: ユーザーテーブルに多数のレコードを持つインスタンス。詳細については、長時間実行されるユーザータイプのデータ変更を参照してください。
    • 16.1.5: NPMパッケージレジストリを使用するインスタンス。
    • 16.2.8: 多数のパイプライン変数（履歴パイプラインを含む）を持つインスタンス。

    インスタンスが影響を受けており、これらの経由バージョンをスキップする場合:

    • アップグレードの完了に数時間かかることがあります。
    • すべてのデータベース変更が完了するまで、インスタンスは500エラーを生成します。その後、PumaとSidekiqを再起動する必要があります。
    • Linuxパッケージインストールの場合、タイムアウトが発生するため、手動による回避策で移行を完了する必要があります。

  • GitLab 16.0では、プロジェクトサイズに対する制限の適用に関して変更が導入されました。Self-Managedでこれらの制限を使用する場合、制限に達したプロジェクトでは、同じグループ内の影響を受けないGitリポジトリにプッシュするときにエラーメッセージが表示されます。エラーは、多くの場合、ゼロバイトの制限（limit of 0 B）を超えていることを示します。

    プッシュは成功しますが、エラーが表示されるため、自動化で問題が発生する可能性があります。イシューの詳細をご覧ください。このバグはGitLab 16.5以降で修正されています。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

  • GitLab 16にアップグレードする前に、GitalyおよびPraefectの設定構造を変更する必要があります。To avoid data loss（データ損失を回避するため）、最初にPraefectを再構成し、新しい設定の一部として、メタデータ検証を無効にします。詳細については、以下を参照してください:

  • Gitデータを/var/opt/gitlab/git-data/repositories以外の場所に保存するようにGitalyを再構成した場合、パッケージ化されたGitLab 16.0以降では、ディレクトリ構造は自動的に作成されません。詳細と回避策については、イシューをお読みください。

16.11.0

  • JSON Webトークン（IDトークン）がgroups_directフィールドに追加されました。
    • GitLab CI/CD IDトークンを使用してサードパーティサービスで認証する場合、この変更によりHTTPヘッダーサイズが増加する可能性があります。ヘッダーが大きくなりすぎると、プロキシサーバーがリクエストを拒否する可能性があります。
    • 可能であれば、受信システムのヘッダー制限を増やします。
    • 詳細については、イシュー467253を参照してください。
  • GitLab 16.11にアップグレードすると、大規模な環境とデータベースを持つ一部のユーザーは、Web UIでソースコードページを読み込む際にタイムアウトが発生する可能性があります。
    • これらのタイムアウトは、パイプラインデータのPostgreSQLクエリが遅く、内部の60秒のタイムアウトを超えることが原因です。
    • Gitリポジトリを引き続きクローンできるほか、リポジトリデータに対するその他のリクエストも機能します。
    • これが原因で影響を受けていることを確認する手順や、PostgreSQLで実行して修正するためのハウスキーピングなど、詳細については、イシュー472420を参照してください。

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

GitLab 16.11では、次の場合を除き、PostgreSQLは自動的に14.xにアップグレードされます:

  • Patroniを使用して高可用性でデータベースを実行している。
  • データベースノードがGitLab Geo構成の一部である。
  • PostgreSQLの自動アップグレードを明示的にオプトアウトしている。
  • /etc/gitlab/gitlab.rbにpostgresql['version'] = 13がある。

耐障害性およびGeoインストールは、PostgreSQL 14への手動アップグレードをサポートしています。詳しくは、HA/GeoクラスターにデプロイされたパッケージPostgreSQLを参照してください。

Geoインストール

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

  • GitLab 16.11からGitLab 17.2までのバージョンでは、PostgreSQLインデックスが欠落しているため、CPU使用率が高くなったり、ジョブアーティファクトの検証の進行が遅くなったり、Geoメトリクスのステータスアップデートが遅延またはタイムアウトしたりする可能性があります。インデックスはGitLab 17.3で追加されました。インデックスを手動で追加するには、Geoトラブルシューティング - ジョブアーティファクトの検証中にプライマリでCPU使用率が高くなるを参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.11すべてなし
    17.0すべてなし
    17.1すべてなし
    17.2すべてなし

  • Geoレプリケーションが機能している場合でも、セカンダリサイトのGeoレプリケーションの詳細は空に見えます。イシュー468509を参照してください。既知の回避策はありません。このバグはGitLab 17.4で修正されました。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.1116.11.5 - 16.11.10なし
    17.0すべて17.0.7
    17.1すべて17.1.7
    17.2すべて17.2.5
    17.3すべて17.3.1

16.10.0

GitLab 16.10以降にアップグレードする際に、次のエラーが発生する可能性があります:

PG::UndefinedColumn: ERROR:  column namespace_settings.delayed_project_removal does not exist

このエラーは、列を削除する移行が実行された後に、その削除された列を参照する移行が実行されると発生する可能性があります。このバグの修正は、16.11のリリースで計画されています。

問題を回避するには:

  1. 列を一時的に再作成します。gitlab-psqlを使用するか、データベースに手動で接続して、次を実行します:

    ALTER TABLE namespace_settings ADD COLUMN delayed_project_removal BOOLEAN DEFAULT NULL;

  2. 保留中の移行を適用します:

    gitlab-ctl reconfigure

  3. 最終的な確認をします:

    gitlab-ctl upgrade-check

  4. 列を削除します。gitlab-psqlを使用するか、データベースに手動で接続して、次を実行します:

    ALTER TABLE namespace_settings DROP COLUMN delayed_project_removal;

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

GitLab 16.10のLinuxパッケージインストールには、Patroniの新しいメジャーバージョンへのアップグレード（バージョン2.1.0からバージョン3.0.1）が含まれています。

高可用性（HA) （3,000ユーザー以上）を有効にするリファレンスアーキテクチャの1つを使用している場合は、Patroniを使用するLinuxパッケージインストール用のPostgreSQLレプリケーションとフェイルオーバーを使用しています。

これが該当する場合は、マルチノードインスタンスのアップグレード方法について、ダウンタイムを伴うマルチノードアップグレードをお読みください。

バージョン2.1.0とバージョン3.0.1の間で導入された変更点の詳細については、Patroniリリースノートを参照してください。

Geoインストール

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

16.9.0

GitLab 16.9.0へのアップグレード中に、次のエラーが発生する可能性があります:

PG::UndefinedTable: ERROR:  relation "p_ci_pipeline_variables" does not exist

すべての移行が完了し、すべてのRailsノードとSidekiqノードが再起動されていることを確認してください。このバグの修正は、16.9.1のリリースで計画されています。

Geoインストール

  • コンテナレプリケーションのバグにより、誤って設定されたセカンダリが、失敗したコンテナレプリケーションを成功としてマークする可能性があります。後続の検証では、チェックサムの不一致により、コンテナは失敗としてマークされます。回避策は、セカンダリの設定を修正することです。Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    すべてすべて16.10.2

  • GitLab 16.5のバグにより、パーソナルスニペットがセカンダリGeoサイトにレプリケートされていません。これにより、Geoフェイルオーバーが発生した場合に、パーソナルスニペットデータが失われる可能性があります。問題の詳細と回避策については、イシュー439933を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.7すべてなし
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • プライマリサイトとセカンダリサイトのチェックサムが一致しないため、コンテナレジストリイメージのサブセットで検証エラーが発生する可能性があります。イシュー442667に詳細が記載されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失の直接的なリスクはありませんが、検証は成功していません。現時点では、既知の回避策はありません。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

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

  • Sidekiqのmin_concurrencyオプションとmax_concurrencyオプションは、GitLab 16.9.0で非推奨となり、GitLab 17.0.0で削除される予定です。GitLab 16.9.0以降では、GitLab 17.0.0で破壊的な変更を回避するために、新しいconcurrencyオプションを設定し、min_concurrencyオプションとmax_concurrencyオプションを削除してください。

16.8.0

  • GitLab 16.8.0および16.8.1では、一時的にRedis 6.2が必要でした。GitLab 16.8.2では、Redis 6.0との互換性が復元されました。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

Geoインストール

  • PostgreSQLバージョン14は、GitLab 16.7以降の新規インストールのデフォルトです。既知の問題のため、既存のGeoセカンダリサイトはPostgreSQLバージョン14にアップグレードできません。詳細については、イシュー7768を参照してください。すべてのGeoサイトは、同じバージョンのPostgreSQLを実行する必要があります。GitLab 16.7から16.8.1で新しいGeoセカンダリサイトを追加するには、設定に基づいて次のいずれかの操作を行う必要があります:

    • 最初のGeoセカンダリサイトを追加するには: 新しいGeoセカンダリサイトをセットアップする前に、プライマリサイトをPostgreSQL 14にアップグレードしてください。プライマリサイトがすでにPostgreSQL 14を実行している場合は、特別な操作は必要ありません。
    • すでに1つ以上のGeoセカンダリがあるデプロイに新しいGeoセカンダリサイトを追加するには:
      • 既存のすべてのサイトがPostgreSQL 13を実行している場合は、ピン留めしたPostgreSQLバージョン13を使用して新しいGeoセカンダリサイトをインストールします。
      • 既存のすべてのサイトがPostgreSQL 14を実行している場合は、: 特別な操作は必要ありません。
      • 新しいGeoセカンダリサイトをデプロイに追加する前に、既存のすべてのサイトをGitLab 16.8.2以降およびPostgreSQL 14にアップグレードしてください。

  • GitLab 16.5のバグにより、パーソナルスニペットがセカンダリGeoサイトにレプリケートされていません。これにより、Geoフェイルオーバーが発生した場合に、パーソナルスニペットデータが失われる可能性があります。問題の詳細と回避策については、イシュー439933を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.7すべてなし
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • プライマリサイトとセカンダリサイトのチェックサムが一致しないため、コンテナレジストリイメージのサブセットで検証エラーが発生する可能性があります。イシュー442667に詳細が記載されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失の直接的なリスクはありませんが、検証は成功していません。現時点では、既知の回避策はありません。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

16.7.0

  • GitLab 16.7は、必須アップグレードストップです。これにより、GitLab 16.7以前に導入されたすべてのデータベース変更が、すべてのSelf-Managedインスタンスに実装されていることが保証されます。依存する変更は、GitLab 16.8以降でリリースできます。イシュー429611に詳細が記載されています。

    • アップグレードパスで16.6をスキップすると、16.7にアップグレードした後、インスタンスがGitLab 16.6リリースからのバックグラウンドデータベース移行を処理するときに、パフォーマンス問題が発生する可能性があります。16.6.0アップグレードノートでci_builds移行の詳細をお読みください。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

Linuxパッケージのインストールには、次の特定の情報が適用されます:

  • GitLab 16.7以降、PostgreSQL 14は、Linuxパッケージでインストールされるデフォルトバージョンです。パッケージアップのグレード中に、データベースはPostgreSQL 14にアップグレードされません。PostgreSQL 14へのアップグレードは、手動で行う必要があります。

    PostgreSQL 13を使用する場合は、/etc/gitlab/gitlab.rbでpostgresql['version'] = 13を設定する必要があります。

Geoインストール

  • PostgreSQLバージョン14は、GitLab 16.7以降の新規インストールのデフォルトです。既知の問題のため、既存のGeoセカンダリサイトはPostgreSQLバージョン14にアップグレードできません。詳細については、イシューを参照してください。すべてのGeoサイトは、同じバージョンのPostgreSQLを実行する必要があります。GitLab 16.7から16.8.1で新しいGeoセカンダリサイトを追加するには、設定に基づいて次のいずれかの操作を行う必要があります:

    • 1つ目のGeoセカンダリサイトを追加する場合: 新しいGeoセカンダリサイトをセットアップする前に、プライマリサイトをPostgreSQL 14にアップグレードしてください。プライマリサイトがすでにPostgreSQL 14を実行している場合は、特別な操作は必要ありません。
    • すでに1つ以上のGeoセカンダリがあるデプロイメントに、新しいGeoセカンダリサイトを追加する場合:
      • 既存のすべてのサイトがPostgreSQL 13を実行している場合は、: ピン留めしたPostgreSQLバージョン13を使用して、新しいGeoセカンダリサイトをインストールします。
      • 既存のすべてのサイトがPostgreSQL 14を実行している場合は、: 特別な操作は必要ありません。
      • 新しいGeoセカンダリサイトをデプロイに追加する前に、既存のすべてのサイトをGitLab 16.8.2以降およびPostgreSQL 14にアップグレードしてください。

  • プライマリサイトとセカンダリサイトの間でチェックサムが一致しないため、一部のプロジェクトで検証エラーが発生する可能性があります。詳細は、このイシューで追跡されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失のリスクはありません。ユーザーがGeoセカンダリサイトから、影響を受けたプロジェクトをクローンすると、常にプライマリサイトにリダイレクトされます。現時点では、既知の回避策はありません。現在、修正に取り組んでいます。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.616.6.0 - 16.6.516.6.6
    16.716.7.0 - 16.7.316.7.4

  • GitLab 16.5のバグにより、パーソナルスニペットがセカンダリGeoサイトにレプリケートされていません。これにより、Geoフェイルオーバーが発生した場合に、パーソナルスニペットデータが失われる可能性があります。問題の詳細と回避策については、イシュー439933を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.7すべてなし
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

16.6.0

  • GitLab 16.6では、プライマリキーを64ビットにアップグレードする一環として、CIジョブテーブル（ci_builds）のすべての行を書き換えるバックグラウンド移行が導入されています。ci_buildsは、ほとんどのGitLabインスタンスで最大のテーブルの1つであるため、この移行は通常よりも積極的に実行され、妥当な時間で完了できるようになっています。通常、バックグラウンド移行は行のバッチ間で一時停止しますが、この移行は一時停止しません。

    そのため、Self-Managed環境で次のパフォーマンス問題が発生する可能性があります:

    • ディスクI/Oが通常よりも高くなります。これは、クラウドプロバイダーがホストする、ディスクI/Oが制限されているインスタンスでは特に問題になります。
    • 古い行（デッドタプル）を削除し、その他の関連するハウスキーピングを実行するために、Autovacuumがバックグラウンドでより頻繁に実行される可能性があります。
    • PostgreSQLによって非効率なクエリプランが選択されると、クエリの実行速度が一時的に低下する可能性があります。これは、テーブル上の変更量によってトリガーされる可能性があります。

    回避策:

    • 管理者エリアで実行中の移行を一時停止します。

    • 適切なクエリプランが選択されるように、データベースコンソールでテーブル統計を手動で再作成します:

      SET statement_timeout = 0;
VACUUM FREEZE VERBOSE ANALYZE public.ci_builds;

  • GitLab 16.6へのアップグレード後、古いCI環境破棄ジョブが起動する可能性があります。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

Geoインストール

  • プライマリサイトとセカンダリサイトの間でチェックサムが一致しないため、一部のプロジェクトで検証エラーが発生する可能性があります。詳細は、このイシューで追跡されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失のリスクはありません。ユーザーがGeoセカンダリサイトから、影響を受けたプロジェクトをクローンすると、常にプライマリサイトにリダイレクトされます。現時点では、既知の回避策はありません。現在、修正に取り組んでいます。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.616.6.0 - 16.6.516.6.6
    16.716.7.0 - 16.7.316.7.4

  • GitLab 16.5のバグにより、パーソナルスニペットがセカンダリGeoサイトにレプリケートされていません。これにより、Geoフェイルオーバーが発生した場合に、パーソナルスニペットデータが失われる可能性があります。問題の詳細と回避策については、イシュー439933を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.7すべてなし
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

16.5.0

  • GitalyではGit 2.42.0以降が必要です。自己コンパイルされたインストールでは、Gitalyが提供するGitバージョンを使用する必要があります。

  • リグレッションにより、グループをナビゲートする際にHTTP 500エラーが発生することがあります。GitLab 16.6以降にアップグレードすると、この問題は解決します。

  • リグレッションにより、選択されていない高度な検索ファセットが読み込まれない場合があります。16.6以降にアップグレードすると、この問題は解決します。

  • unique_batched_background_migrations_queued_migration_versionインデックスは16.5で導入され、デプロイ後の移行DeleteOrphansScanFindingLicenseScanningApprovalRules2は、ゼロダウンタイムアップグレードを実行中に、この一意の制約を破る可能性があります。エラーを修正する回避策は、イシュー#437291で入手できます:

    PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint
"unique_batched_background_migrations_queued_migration_version"
DETAIL:  Key (queued_migration_version)=(20230721095222) already exists.

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

  • SSHクローンURLは、/etc/gitlab/gitlab.rbでgitlab_rails['gitlab_ssh_host']を設定することでカスタマイズできます。この設定は、有効なホスト名である必要があります。以前は、リポジトリクローンURLにカスタムホスト名とポートを表示するために使用される任意の文字列を指定できました。

    たとえば、GitLab 16.5より前は、次の設定が機能していました:

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com:2222"

    GitLab 16.5以降では、ホスト名とポートを個別に指定する必要があります:

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com"
gitlab_rails['gitlab_shell_ssh_port'] = 2222

    設定を変更したら、必ずGitLabを再構成してください:

    sudo gitlab-ctl reconfigure

Geoインストール

Geoを使用するインストールには、特定の情報が適用されます:

  • いくつかのPrometheusメトリクスが、16.3.0で誤って削除されました。そのため、ダッシュボードとアラートが中断する可能性があります:

    影響を受けるメトリクス16.5.2以降で復元されたメトリクス16.3以降で利用可能な代替手段
    geo_repositories_synced√geo_project_repositories_synced
    geo_repositories_failed√geo_project_repositories_failed
    geo_repositories_checksummed√geo_project_repositories_checksummed
    geo_repositories_checksum_failed√geo_project_repositories_checksum_failed
    geo_repositories_verified√geo_project_repositories_verified
    geo_repositories_verification_failed√geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatchいいえ利用不可
    geo_repositories_retrying_verificationいいえ利用不可
    • 影響を受けるバージョン:
      • 16.3.0 - 16.5.1
    • 修正を含むバージョン:
      • 16.5.2以降

    詳細については、イシュー429617を参照してください。

  • オブジェクトストレージの検証がGitLab 16.4で追加されました。イシューにより、一部のGeoインストールでメモリ使用量が高くなっていると報告されており、プライマリ上のGitLabアプリケーションが応答しなくなる可能性があります。

    オブジェクトストレージを使用するようインストールを構成していて、GitLab管理のオブジェクトストレージレプリケーションを有効にしている場合、インストールが影響を受ける可能性があります

    これが修正されるまで、回避策としてオブジェクトストレージの検証を無効にします。プライマリサイトのいずれかのRailsノードで、次のコマンドを実行します:

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.416.4.0 - 16.4.216.4.3
    16.516.5.0 - 16.5.116.5.2

  • GitLab 16.3でグループWikiの検証が追加された後、存在しないグループWikiリポジトリに、検証失敗という誤ったフラグが立てられています。この問題は、実際のレプリケーションや検証の失敗の結果ではなく、Geo内にリポジトリが存在しないために起こる内部の無効な状態が原因であり、ログにエラーが記録され、検証の進行状態で、これらのグループWikiリポジトリが失敗状態としてレポートされます。

    問題の詳細と回避策については、イシュー426571を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.516.5.0 - 16.5.116.5.2

  • プライマリサイトとセカンダリサイトの間でチェックサムが一致しないため、一部のプロジェクトで検証エラーが発生する可能性があります。詳細は、このイシューで追跡されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失のリスクはありません。ユーザーがGeoセカンダリサイトから、影響を受けたプロジェクトをクローンすると、常にプライマリサイトにリダイレクトされます。現時点では、既知の回避策はありません。現在、修正に取り組んでいます。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.616.6.0 - 16.6.516.6.6
    16.716.7.0 - 16.7.316.7.4

  • GitLab 16.5のバグにより、パーソナルスニペットがセカンダリGeoサイトにレプリケートされていません。これにより、Geoフェイルオーバーが発生した場合に、パーソナルスニペットデータが失われる可能性があります。問題の詳細と回避策については、イシュー439933を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.7すべてなし
    16.816.8.0 - 16.8.316.8.4
    16.916.9.0 - 16.9.116.9.2

  • GitLab 16.5で発生し、17.0で修正されたバグにより、GitLab PagesデプロイファイルがセカンダリGeoサイトで孤立するという事象が発生しています。Pagesのデプロイがローカルに保存されている場合、これにより、残りのストレージがゼロになり、フェイルオーバーが発生した場合にデータが失われる可能性があります。問題の詳細と回避策については、イシュー457159を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.716.7.8
    16.816.8.0 - 16.8.716.8.8
    16.916.9.0 - 16.9.816.9.9
    16.1016.10.0 - 16.10.616.10.7
    16.1116.11.0 - 16.11.316.11.4

16.4.0

  • グループパスの更新については、16.3で導入されたデータベースインデックスを使用するバグ修正が適用されました。

    16.3より前のバージョンから16.4にアップグレードする場合は、使用する前にデータベースでANALYZE packages_packages;を実行する必要があります。

  • GitLab 16.4以降にアップグレードする際に、次のエラーが発生する可能性があります:

    main: == 20230830084959 ValidatePushRulesConstraints: migrating =====================
main: -- execute("SET statement_timeout TO 0")
main:    -> 0.0002s
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT force_push_regex_size_constraint;")
main:    -> 0.0004s
main: -- execute("RESET statement_timeout")
main:    -> 0.0003s
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT delete_branch_regex_size_constraint;")
rails aborted!
StandardError: An error has occurred, all later migrations canceled:

PG::CheckViolation: ERROR:  check constraint "delete_branch_regex_size_constraint" of relation "push_rules" is violated by some row

    これらの制約により、エラーが返される可能性があります:

    • author_email_regex_size_constraint
    • branch_name_regex_size_constraint
    • commit_message_negative_regex_size_constraint
    • commit_message_regex_size_constraint
    • delete_branch_regex_size_constraint
    • file_name_regex_size_constraint
    • force_push_regex_size_constraint

    エラーを修正するには、push_rulesテーブル内で511文字の制限を超えるレコードを見つけます。

    -- replace `delete_branch_regex` with a name of the field used in constraint
SELECT id FROM push_rules WHERE LENGTH(delete_branch_regex) > 511;

    プッシュルールがプロジェクト、グループ、インスタンスのいずれに属しているかを確認するには、Railsコンソールで次のスクリプトを実行します:

    # replace `delete_branch_regex` with a name of the field used in constraint
long_rules = PushRule.where("length(delete_branch_regex) > 511")

array = long_rules.map do |lr|
  if lr.project
    "Push rule with ID #{lr.id} is configured in a project #{lr.project.full_name}"
  elsif lr.group
    "Push rule with ID #{lr.id} is configured in a group #{lr.group.full_name}"
  else
    "Push rule with ID #{lr.id} is configured on the instance level"
  end
end

puts "Total long rules: #{array.count}"
puts array.join("\n")

    該当するプッシュルールレコードの正規表現フィールドの値の長さを小さくしてから、移行を再試行してください。

    影響を受けるプッシュルールが多すぎて、GitLab UIから更新できない場合は、GitLabサポートにお問い合わせください。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

  • GitLab 16.4以降では、GitLabシークレットとカスタムフックのパスを設定する新しい方法が推奨されています:
    1. 設定[gitlab] secret_fileを更新して、GitLabシークレットトークンのパスを設定します。
    2. カスタムフックがある場合は、設定[hooks] custom_hooks_dirを更新して、サーバー側のカスタムフックのパスを設定します。
    3. [gitlab-shell] dir設定を削除します。

Geoインストール

Geoを使用するインストールには、特定の情報が適用されます:

  • いくつかのPrometheusメトリクスが、16.3.0で誤って削除されました。そのため、ダッシュボードとアラートが中断する可能性があります:

    影響を受けるメトリクス16.5.2以降で復元されたメトリクス16.3以降で利用可能な代替手段
    geo_repositories_synced√geo_project_repositories_synced
    geo_repositories_failed√geo_project_repositories_failed
    geo_repositories_checksummed√geo_project_repositories_checksummed
    geo_repositories_checksum_failed√geo_project_repositories_checksum_failed
    geo_repositories_verified√geo_project_repositories_verified
    geo_repositories_verification_failed√geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatchいいえ利用不可
    geo_repositories_retrying_verificationいいえ利用不可
    • 影響を受けるバージョン:
      • 16.3.0 - 16.5.1
    • 修正を含むバージョン:
      • 16.5.2以降

    詳細については、イシュー429617を参照してください。

  • オブジェクトストレージの検証がGitLab 16.4で追加されました。イシューにより、一部のGeoインストールでメモリ使用量が高くなっていると報告されており、プライマリ上のGitLabアプリケーションが応答しなくなる可能性があります。

    オブジェクトストレージを使用するようインストールを構成していて、GitLab管理のオブジェクトストレージレプリケーションを有効にしている場合、インストールが影響を受ける可能性があります

    これが修正されるまで、回避策としてオブジェクトストレージの検証を無効にします。プライマリサイトのいずれかのRailsノードで、次のコマンドを実行します:

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.416.4.0 - 16.4.216.4.3
    16.516.5.0 - 16.5.116.5.2

  • 同期状態が保留状態のままになるイシューにより、影響を受けるアイテムのレプリケーションが無期限に停止し、フェイルオーバーが発生した場合にデータが失われるリスクがあります。これは主にリポジトリの同期に影響しますが、コンテナレジストリの同期にも影響を与える可能性があります。データ損失のリスクを回避するために、修正済みのバージョンにアップグレードすることをおすすめします。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.316.3.0 - 16.3.516.3.6
    16.416.4.0 - 16.4.116.4.2

  • GitLab 16.3でグループWikiの検証が追加された後、存在しないグループWikiリポジトリに、検証失敗という誤ったフラグが立てられています。この問題は、実際のレプリケーションや検証の失敗の結果ではなく、Geo内にリポジトリが存在しないために起こる内部の無効な状態が原因であり、ログにエラーが記録され、検証の進行状態で、これらのグループWikiリポジトリが失敗状態としてレポートされます。

    問題の詳細と回避策については、イシュー426571を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.516.5.0 - 16.5.116.5.2

  • プライマリサイトとセカンダリサイトの間でチェックサムが一致しないため、一部のプロジェクトで検証エラーが発生する可能性があります。詳細は、このイシューで追跡されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失のリスクはありません。ユーザーがGeoセカンダリサイトから、影響を受けたプロジェクトをクローンすると、常にプライマリサイトにリダイレクトされます。現時点では、既知の回避策はありません。現在、修正に取り組んでいます。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.616.6.0 - 16.6.516.6.6
    16.716.7.0 - 16.7.316.7.4

16.3.0

  • Update to GitLab 16.3.5 or later（GitLab 16.3.5以降にアップデート）してください。これにより、GitLab 16.3.3および16.3.4でデータベースのディスクスペースを過剰に使用するイシュー425971を回避できます。

  • データベースに重複したNPMパッケージがないことを保証するために、一意のインデックスが追加されました。重複したNPMパッケージがある場合は、最初に16.1にアップグレードする必要があります。そうしないと、PG::UniqueViolation: ERROR: could not create unique index "idx_packages_on_project_id_name_version_unique_when_npm"のエラーが発生する可能性があります。

  • Goアプリケーションの場合、crypto/tls: verifying certificate chains containing large RSA keys is slow (CVE-2023-29409)（crypto/tls: 大規模なRSAキーを含む証明書チェーンの検証が遅い (CVE-2023-29409)）により、RSAキーのハード制限が8192ビットに設定されました。GitLabでのGoアプリケーションのコンテキストでは、RSAキーを以下のために設定できます:

    アップグレードする前に、上記のアプリケーションのいずれかでRSAキーのサイズ（openssl rsa -in <your-key-file> -text -noout | grep "Key:"）を確認する必要があります。

  • BackfillCiPipelineVariablesForPipelineIdBigintConversionバックグラウンド移行は、EnsureAgainBackfillForCiPipelineVariablesPipelineIdIsFinishedポストデプロイ移行で完了します。GitLab 16.2.0では、ci_pipeline_variablesテーブルのbigint pipeline_id値をバックフィルする バッチバックグラウンド移行が導入されました。この移行は、大規模なGitLabインスタンスでは完了までに長い時間がかかる場合があります（あるケースでは、5,000万行の処理に4時間かかったと報告されています）。アップグレードのダウンタイムが長引くのを避けるために、16.3にアップグレードする前に、移行が正常に完了していることを確認してください。

    データベースコンソールで、ci_pipeline_variablesテーブルのサイズを確認できます:

    select count(*) from ci_pipeline_variables;

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

Linuxパッケージのインストールには、次の特定の情報が適用されます:

  • GitLab 16.0では、新しいバージョンのOpenSSH Serverを持つ、アップグレードされたベースDockerイメージを発表しました。新しいバージョンでは、SSH RSA SHA-1署名の受け入れがデフォルトで無効になるという意図しない結果が生じました。この問題は、非常に古いSSHクライアントを使用しているユーザーにしか影響しないはずです。

    SHA-1署名が利用できなくなる問題を回避するには、ユーザーはSSHクライアントを更新する必要があります。セキュリティ上の理由から、アップストリームライブラリでSHA-1署名を使用することが推奨されていないためです。

    ユーザーはSSHクライアントをすぐにアップグレードできないため、移行期間を考慮して、GitLab 16.3以降では、DockerfileのGITLAB_ALLOW_SHA1_RSA環境変数がサポートされています。GITLAB_ALLOW_SHA1_RSAがtrueに設定されている場合、この非推奨のサポートが再び有効になります。

    セキュリティのベストプラクティスを促進し、アップストリームの推奨事項に従うため、この環境変数はGitLab 17.0までのみ利用可能になり、その時点でサポートを停止する予定です。

    詳細については、以下を参照してください:

Geoインストール

Geoを使用するインストールには、特定の情報が適用されます:

  • セカンダリGeoサイトに対するgit pullは、そのセカンダリサイトが最新の状態であっても、プライマリGeoサイトにプロキシされます。セカンダリGeoサイトに対してgit pullリクエストを行うリモートユーザーを高速化するためにGeoを使用している場合は、影響を受けます。

    • 影響を受けるバージョン:
      • 16.3.0 - 16.3.3
    • 修正を含むバージョン:
      • 16.3.4以降

    詳細については、イシュー425224を参照してください。

  • いくつかのPrometheusメトリクスが、16.3.0で誤って削除されました。そのため、ダッシュボードとアラートが中断する可能性があります:

    影響を受けるメトリクス16.5.2以降で復元されたメトリクス16.3以降で利用可能な代替手段
    geo_repositories_synced√geo_project_repositories_synced
    geo_repositories_failed√geo_project_repositories_failed
    geo_repositories_checksummed√geo_project_repositories_checksummed
    geo_repositories_checksum_failed√geo_project_repositories_checksum_failed
    geo_repositories_verified√geo_project_repositories_verified
    geo_repositories_verification_failed√geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatchいいえ利用不可
    geo_repositories_retrying_verificationいいえ利用不可
    • 影響を受けるバージョン:
      • 16.3.0 - 16.5.1
    • 修正を含むバージョン:
      • 16.5.2以降

    詳細については、イシュー429617を参照してください。

  • 同期状態が保留状態のままになるイシューにより、影響を受けるアイテムのレプリケーションが無期限に停止し、フェイルオーバーが発生した場合にデータが失われるリスクがあります。これは主にリポジトリの同期に影響しますが、コンテナレジストリの同期にも影響を与える可能性があります。データ損失のリスクを回避するために、修正済みのバージョンにアップグレードすることをおすすめします。

  • プライマリサイトとセカンダリサイトの間でチェックサムが一致しないため、一部のプロジェクトで検証エラーが発生する可能性があります。詳細については、イシュー427493で追跡されています。データはセカンダリサイトに正しくレプリケートされているため、データ損失のリスクはありません。ユーザーがGeoセカンダリサイトから、影響を受けたプロジェクトをクローンすると、常にプライマリサイトにリダイレクトされます。既知の回避策はありません。修正を含むバージョンにアップグレードする必要があります。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.616.6.0 - 16.6.516.6.6
    16.716.7.0 - 16.7.316.7.4

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.316.3.0 - 16.3.516.3.6
    16.416.4.0 - 16.4.116.4.2

  • GitLab 16.3でグループWikiの検証が追加された後、存在しないグループWikiリポジトリに、検証失敗という誤ったフラグが立てられています。この問題は、実際のレプリケーションや検証の失敗の結果ではなく、Geo内にリポジトリが存在しないために起こる内部の無効な状態が原因であり、ログにエラーが記録され、検証の進行状態で、これらのグループWikiリポジトリが失敗状態としてレポートされます。

    問題の詳細と回避策については、イシュー426571を参照してください。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    16.3すべてなし
    16.4すべてなし
    16.516.5.0 - 16.5.116.5.2

16.2.0

  • 従来のLDAP設定が原因でNoMethodError: undefined method 'devise' for User:Classエラーが発生する場合があります。このエラーは、tls_optionsハッシュで指定されていないTLSオプション（ca_fileなど）がある場合、または従来のgitlab_rails['ldap_host']オプションを使用する場合に発生します。詳細については、設定の回避策を参照してください。

  • GitLabデータベースがバージョン15.11.0 - 15.11.2（両端のバージョンを含む）で作成またはアップグレードされた場合、GitLab 16.2へのアップグレードでは次のエラーで失敗します:

    PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

    詳細と回避策については、こちらを参照してください。

  • GitLab 16.2以降へのアップグレード中に、次のエラーが発生する可能性があります:

    main: == 20230620134708 ValidateUserTypeConstraint: migrating =======================
main: -- execute("ALTER TABLE users VALIDATE CONSTRAINT check_0dd5948e38;")
rake aborted!
StandardError: An error has occurred, all later migrations canceled:
PG::CheckViolation: ERROR:  check constraint "check_0dd5948e38" of relation "users" is violated by some row

    詳細については、イシュー421629を参照してください。

  • GitLab 16.2以降にアップグレードした後、次のエラーが発生する可能性があります:

    PG::NotNullViolation: ERROR:  null value in column "source_partition_id" of relation "ci_sources_pipelines" violates not-null constraint

    この問題を解決するには、SidekiqとPumaのプロセスを再起動する必要があります。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

Linuxパッケージのインストールには、次の特定の情報が適用されます:

  • GitLab 16.2の時点では、PostgreSQL 13.11と14.8の両方がLinuxパッケージに同梱されています。パッケージアップのグレード中に、データベースはPostgreSQL 14にアップグレードされません。PostgreSQL 14にアップグレードするには、手動でアップグレードする必要があります:

    sudo gitlab-ctl pg-upgrade -V 14

    PostgreSQL 14はGeoデプロイではサポートされておらず、将来のリリースで計画されています。

  • 16.2では、Redisを6.2.11から7.0.12にアップグレードしています。このアップグレードには完全な下位互換性があるはずです。

    Redisは、gitlab-ctl reconfigureの一部として自動的に再起動しません。そのため、再設定の実行後にsudo gitlab-ctl restart redisを手動で実行して、新しいRedisバージョンが使用されるようにする必要があります。再起動が実行されるまで、インストールされているRedisバージョンが実行中のものとは異なることを示す警告が、再設定の実行の最後に表示されます。

    Redis HAクラスターをアップグレードするには、ゼロダウンタイムの手順に従ってください。

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

Geoインストール

Geoを使用するインストールには、特定の情報が適用されます:

  • ジョブアーティファクトがオブジェクトストレージに保存されるように設定され、direct_uploadが有効になっている場合、新しいジョブアーティファクトはGeoによって複製されません。このバグは、GitLabバージョン16.1.4、16.2.3、16.3.0以降で修正されています。
    • 影響を受けるバージョン:GitLabバージョン16.1.0 - 16.1.3および16.2.0 - 16.2.2。
    • 影響を受けるバージョンを実行している場合、同期されたように見えるアーティファクトが、実際にはセカンダリサイトに存在しない可能性があります。影響を受けるアーティファクトは、16.1.5、16.2.5、16.3.1、16.4.0、またはそれ以降にアップグレードすると、自動的に再同期されます。必要に応じて、影響を受けるジョブアーティファクトを手動で再同期できます。

セカンダリサイトからのLFSオブジェクトのクローン作成で、プライマリサイトからダウンロードされる

LFSオブジェクトのGeoプロキシロジックのバグにより、セカンダリサイトに対するすべてのLFSクローンリクエストは、セカンダリサイトが最新の状態であってもプライマリにプロキシされます。これにより、プライマリサイトの負荷が増加し、セカンダリサイトからクローンを作成するユーザーがLFSオブジェクトへアクセスするのに時間がかかる可能性があります。

GitLab 15.1では、プロキシがデフォルトで有効になっていました。

次の場合、影響はありません:

  • LFSオブジェクトを使用するようにインストールが設定されていない場合
  • リモートユーザーを高速化するためにGeoを使用していない場合
  • リモートユーザーを高速化するためにGeoを使用しているが、プロキシを無効にしている場合
影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
15.1 - 16.2すべて16.3以降

回避策: 考えられる回避策は、プロキシを無効にすることです。セカンダリサイトは、クローン作成時にレプリケートされていないLFSファイルの処理に失敗します。

16.1.0

  • BackfillPreparedAtMergeRequestsバックグラウンド移行は、FinalizeBackFillPreparedAtMergeRequestsポストデプロイ移行で完了します。GitLab 15.10.0では、merge_requestsテーブルのprepared_at値をバックフィルする バッチバックグラウンド移行が導入されました。この移行は、大規模なGitLabインスタンスでは、完了するまでに数日かかる場合があります。16.1.0にアップグレードする前に、移行が正常に完了していることを確認してください。

  • GitLab 16.1.0には、重複したNPMパッケージを破棄するためにマークするバッチバックグラウンド移行MarkDuplicateNpmPackagesForDestructionが含まれています。16.3.0以降にアップグレードする前に、移行が正常に完了していることを確認してください。

  • BackfillCiPipelineVariablesForBigintConversionバックグラウンド移行は、EnsureBackfillBigintIdIsCompletedポストデプロイ移行で完了します。GitLab 16.0.0では、ci_pipeline_variablesテーブルのbigint id値をバックフィルするバッチバックグラウンド移行が導入されました。この移行は、大規模なGitLabインスタンスでは完了までに長い時間がかかる場合があります（あるケースでは、5,000万行の処理に4時間かかったと報告されています）。アップグレードのダウンタイムが長引くのを避けるために、16.1にアップグレードする前に、移行が正常に完了していることを確認してください。

    データベースコンソールで、ci_pipeline_variablesテーブルのサイズを確認できます:

    select count(*) from ci_pipeline_variables;

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

  • Puma Worker Killerに関連する設定をpuma.rb設定ファイルから削除する必要があります。これらの設定は削除されているためです。詳細については、puma.rb.exampleファイルを参照してください。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

Geoインストール

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

Geoを使用するインストールには、特定の情報が適用されます:

  • 一部のプロジェクトのインポートでは、プロジェクトの作成時にWikiリポジトリが初期化されません。詳細と回避策については、こちらを参照してください。
  • SSFへのプロジェクトデザインの移行により、存在しないデザインリポジトリに、検証失敗という誤ったフラグが立てられています。この問題は、実際のレプリケーションや検証の失敗の結果ではなく、Geo内にリポジトリが存在しないために起こる内部の無効な状態が原因であり、ログにエラーが記録され、検証の進行状態で、これらのデザインリポジトリが失敗状態としてレポートされます。プロジェクトをインポートしていなくても、この問題の影響を受ける可能性があります。
    • 影響を受けるバージョン:GitLabバージョン16.1.0 - 16.1.2
    • 修正を含むバージョン:GitLab 16.1.3以降。
  • ジョブアーティファクトがオブジェクトストレージに保存されるように設定され、direct_uploadが有効になっている場合、新しいジョブアーティファクトはGeoによって複製されません。このバグは、GitLabバージョン16.1.4、16.2.3、16.3.0以降で修正されています。
    • 影響を受けるバージョン:GitLabバージョン16.1.0 - 16.1.3および16.2.0 - 16.2.2。
    • 影響を受けるバージョンを実行している場合、同期されたように見えるアーティファクトが、実際にはセカンダリサイトに存在しない可能性があります。影響を受けるアーティファクトは、16.1.5、16.2.5、16.3.1、16.4.0、またはそれ以降にアップグレードすると、自動的に再同期されます。必要に応じて、影響を受けるジョブアーティファクトを手動で再同期できます。
    • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

プロジェクト作成時にWikiリポジトリが初期化されない

影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
15.11すべてなし
16.0すべてなし
16.116.1.0 - 16.1.216.1.3以降

一部のプロジェクトのインポートでは、プロジェクトの作成時にWikiリポジトリが初期化されません。プロジェクトWikiをSSFに移行して以来、存在しないWikiリポジトリに、検証失敗という誤ったフラグが立てられています。この問題は、実際のレプリケーションや検証の失敗の結果ではなく、Geo内にリポジトリが存在しないために起こる内部の無効な状態が原因であり、ログにエラーが記録され、検証の進行状態で、これらのWikiリポジトリが失敗状態としてレポートされます。プロジェクトをインポートしていない場合、この問題の影響は受けません。

16.0.0

  • /etc/gitlab/gitlab.rbファイルに非ASCII文字が含まれている場合、Sidekiqがクラッシュします。イシュー412767の回避策に従って、これを修正できます。

  • デフォルトでは、Sidekiqジョブはdefaultキューとmailersキューにのみルーティングされます。その結果、すべてのSidekiqプロセスはこれらのキューもリッスンして、すべてのキューですべてのジョブが処理されるようにします。ルーティングルールを設定している場合、この動作は適用されません。

  • GitLab Dockerイメージを実行するには、Docker 20.10.10以降が必要です。古いバージョンは、起動時にエラーを返します。

  • Azureストレージを使用するコンテナレジストリが空で、タグがゼロになっている可能性があります。破壊的な変更の手順に従って、これを修正できます。

  • 通常、PgBouncerを使用する環境でのバックアップは、GITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    Affected releases（影響を受けるリリース）:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

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

Linuxパッケージのインストールには、次の特定の情報が適用されます:

  • PostgreSQL 12のバイナリは削除されました。

    アップグレードする前に、Linuxパッケージインストールの管理者は、インストールでPostgreSQL 13を使用していることを確認する必要があります。

  • GitLabにバンドルされていたGrafanaは非推奨となり、サポートされなくなりました。GitLab 16.3で削除されます。

  • これにより、openssh-serverが1:8.9p1-3にアップグレードされます。

    OpenSSH 8.7リリースノートにリストされている非推奨事項のため、古いOpenSSHクライアントでssh-keyscan -t rsaを使用して公開キー情報を取得できなくなりました。

    回避策は、別のキータイプを使用するか、クライアントOpenSSHを8.7以上のバージョンにアップグレードすることです。

  • GitLab 16.0以降ですべてのpraefect['..']設定が引き続き機能するように、Praefect設定を新しい構造に移行します。

  • GitLab 16.0以降ですべてのgitaly['..']設定が引き続き機能するように、Gitaly設定を新しい構造に移行します。

有効期限のないアクセストークン

有効期限のないアクセストークンは無期限に有効であるため、アクセストークンが漏洩した場合、セキュリティリスクとなります。

GitLab 16.0以降にアップグレードすると、有効期限のないパーソナルアクセストークン 、プロジェクトアクセストークン 、またはグループアクセストークンには、アップグレード日から1年後の有効期限が自動的に設定されます。

この自動有効期限が適用される前に、混乱を最小限に抑えるため、次の手順を実行してください:

  1. 有効期限のないアクセストークンを特定します。
  2. それらのトークンに有効期限を付与します。

詳細については、以下を参照してください:

Geoインストール

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

Geoを使用するインストールには、特定の情報が適用されます:

  • 一部のプロジェクトのインポートでは、プロジェクトの作成時にWikiリポジトリが初期化されません。詳細と回避策については、こちらを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

Gitaly設定構造の変更点

GitLab 16.0では、LinuxパッケージのGitaly設定構造が変更され、自己コンパイルによるインストールで使用されるGitaly設定構造と一貫性が保たれるようになりました。

この変更の結果、gitaly['configuration']の下の単一のハッシュには、ほとんどのGitaly設定が保持されます。一部のgitaly['..']設定オプションは、GitLab 16.0以降でも引き続き使用されます:

  • enable
  • dir
  • bin_path
  • env_directory
  • env
  • open_files_ulimit
  • consul_service_name
  • consul_service_meta

既存の設定を新しい構造に移動して移行します。git_data_dirsは、GitLab 18.0までサポートされています。新しい構造は、GitLab 15.10以降でサポートされています。

Migrate to the new structure（新しい構造に移行する）

Gitalyクラスタを実行している場合は、first（最初に）Praefectを新しい設定構造に移行します。この変更をテストしたら、Gitalyノードに進みます。設定構造の変更の一部としてGitalyが誤って設定されている場合、リポジトリの検証によって、Gitaly Cluster (Praefect)が機能するために必要なメタデータが削除されます。設定の誤りを防ぐために、Praefectでリポジトリの検証を一時的に無効にします。

  1. Gitaly Cluster (Praefect)を実行している場合は、すべてのPraefectノードでリポジトリの検証が無効になっていることを確認してください。verification_interval: 0を設定し、gitlab-ctl reconfigureで適用します。
  2. 新しい構造を設定に適用するには、次の手順に従います:
    1. ...を古いキーの値に置き換えます。
    2. git_data_dirsを置き換えるようにstorageを設定する場合は、以下のスクリプトに示すように、append /repositories to value of path（の値にを付加）します。このステップを完了しないと、設定が修正されるまでGitリポジトリにアクセスできなくなります。この設定ミスにより、メタデータが削除される可能性があります。
    3. 以前に値を設定していないキーはスキップしてください。
    4. （推奨）すべてのハッシュキーに対して末尾のコンマを含め、キーの順序が変更されたり、キーが追加されたりしても、ハッシュが有効な状態を維持できるようにします。
  3. gitlab-ctl reconfigureで変更を適用します。
  4. GitLabでGitリポジトリの機能をテストします。
  5. 移行が完了したら、設定から古いキーを削除し、gitlab-ctl reconfigureを再実行します。
  6. （Gitaly Clusterを実行している場合は推奨）verification_interval: 0を削除して、Praefectリポジトリの検証を元に戻します。

新しい構造は、次のスクリプトでドキュメント化されており、古いキーについては、新しいキーの上のコメントで説明されています。

storageに更新したことを再確認してください。pathの値に/repositoriesを付加する必要があります。

gitaly['configuration'] = {
  # gitaly['socket_path']
  socket_path: ...,
  # gitaly['runtime_dir']
  runtime_dir: ...,
  # gitaly['listen_addr']
  listen_addr: ...,
  # gitaly['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # gitaly['tls_listen_addr']
  tls_listen_addr: ...,
  tls: {
    # gitaly['certificate_path']
    certificate_path: ...,
    # gitaly['key_path']
    key_path: ...,
  },
  # gitaly['graceful_restart_timeout']
  graceful_restart_timeout: ...,
  logging: {
    # gitaly['logging_level']
    level: ...,
    # gitaly['logging_format']
    format: ...,
    # gitaly['logging_sentry_dsn']
    sentry_dsn: ...,
    # gitaly['logging_ruby_sentry_dsn']
    ruby_sentry_dsn: ...,
    # gitaly['logging_sentry_environment']
    sentry_environment: ...,
    # gitaly['log_directory']
    dir: ...,
  },
  prometheus: {
    # gitaly['prometheus_grpc_latency_buckets']. The old value was configured as a string
    # such as '[0, 1, 2]'. The new value must be an array like [0, 1, 2].
    grpc_latency_buckets: ...,
  },
  auth: {
    # gitaly['auth_token']
    token: ...,
    # gitaly['auth_transitioning']
    transitioning: ...,
  },
  git: {
    # gitaly['git_catfile_cache_size']
    catfile_cache_size: ...,
    # gitaly['git_bin_path']
    bin_path: ...,
    # gitaly['use_bundled_git']
    use_bundled_binaries: ...,
    # gitaly['gpg_signing_key_path']
    signing_key: ...,
    # gitaly['gitconfig']. This is still an array but the type of the elements have changed.
    config: [
      {
        # Previously the elements contained 'section', and 'subsection' in addition to 'key'. Now
        # these all should be concatenated into just 'key', separated by dots. For example,
        # {section: 'first', subsection: 'middle', key: 'last', value: 'value'}, should become
        # {key: 'first.middle.last', value: 'value'}.
        key: ...,
        value: ...,
      },
    ],
  },
  # Storage was previously configured with the gitaly['storage'] or 'git_data_dirs' parameters. Use
  # the following instructions to migrate. For 'git_data_dirs', migrate only the 'path' to the
  # gitaly['configuration'] and leave the rest untouched.
  storage: [
    {
      # gitaly['storage'][<index>]['name']
      #
      # git_data_dirs[<name>]. The storage name was configured as a key in the map.
      name: ...,
      # gitaly['storage'][<index>]['path']
      #
      # git_data_dirs[<name>]['path']. Use the value from git_data_dirs[<name>]['path'] and append '/repositories' to it.
      #
      # For example, if the path in 'git_data_dirs' was '/var/opt/gitlab/git-data', use
      # '/var/opt/gitlab/git-data/repositories'. The '/repositories' extension was automatically
      # appended to the path configured in `git_data_dirs`.
      path: ...,
    },
  ],
  hooks: {
    # gitaly['custom_hooks_dir']
    custom_hooks_dir: ...,
  },
  daily_maintenance: {
    # gitaly['daily_maintenance_disabled']
    disabled: ...,
    # gitaly['daily_maintenance_start_hour']
    start_hour: ...,
    # gitaly['daily_maintenance_start_minute']
    start_minute: ...,
    # gitaly['daily_maintenance_duration']
    duration: ...,
    # gitaly['daily_maintenance_storages']
    storages: ...,
  },
  cgroups: {
    # gitaly['cgroups_mountpoint']
    mountpoint: ...,
    # gitaly['cgroups_hierarchy_root']
    hierarchy_root: ...,
    # gitaly['cgroups_memory_bytes']
    memory_bytes: ...,
    # gitaly['cgroups_cpu_shares']
    cpu_shares: ...,
    repositories: {
      # gitaly['cgroups_repositories_count']
      count: ...,
      # gitaly['cgroups_repositories_memory_bytes']
      memory_bytes: ...,
      # gitaly['cgroups_repositories_cpu_shares']
      cpu_shares: ...,
    }
  },
  # gitaly['concurrency']. While the structure is the same, the string keys in the array elements
  # should be replaced by symbols as elsewhere. {'key' => 'value'}, should become {key: 'value'}.
  concurrency: ...,
  # gitaly['rate_limiting']. While the structure is the same, the string keys in the array elements
  # should be replaced by symbols as elsewhere. {'key' => 'value'}, should become {key: 'value'}.
  rate_limiting: ...,
  pack_objects_cache: {
    # gitaly['pack_objects_cache_enabled']
    enabled: ...,
    # gitaly['pack_objects_cache_dir']
    dir: ...,
    # gitaly['pack_objects_cache_max_age']
    max_age: ...,
  }
}

Praefect設定構造の変更点

GitLab 16.0では、LinuxパッケージのPraefect設定構造が変更され、自己コンパイルによるインストールで使用されるPraefect設定構造と一貫性が保たれるようになりました。

この変更の結果、praefect['configuration']の下の単一のハッシュには、ほとんどのPraefect設定が保持されます。一部のpraefect['..']設定オプションは、GitLab 16.0以降でも引き続き使用されます:

  • enable
  • dir
  • log_directory
  • env_directory
  • env
  • wrapper_path
  • auto_migrate
  • consul_service_name

既存の設定を新しい構造に移動して移行します。新しい構造は、GitLab 15.9以降でサポートされています。

Migrate to the new structure（新しい構造に移行する）

first（最初に）、Praefectを新しい設定構造に移行します。この変更をテストしたら、Gitalyノードに進みます。設定構造の変更の一部としてGitalyが誤って設定されている場合、リポジトリの検証によって、Gitaly Cluster (Praefect)が機能するために必要なメタデータが削除されます。設定の誤りを防ぐために、Praefectでリポジトリの検証を一時的に無効にします。

  1. 新しい構造を設定に適用する場合:
    • ...を古いキーの値に置き換えます。
    • 次のスクリプトに示すように、verification_interval: 0を使用してリポジトリの検証を無効にします。
    • 以前に値を設定していないキーはスキップしてください。
    • （推奨）すべてのハッシュキーに対して末尾のコンマを含め、キーの順序が変更されたり、キーが追加されたりしても、ハッシュが有効な状態を維持できるようにします。
  2. gitlab-ctl reconfigureで変更を適用します。
  3. GitLabでGitリポジトリの機能をテストします。
  4. 移行が完了したら、設定から古いキーを削除し、gitlab-ctl reconfigureを再実行します。

新しい構造は、次のスクリプトでドキュメント化されており、古いキーについては、新しいキーの上のコメントで説明されています。

praefect['configuration'] = {
  # praefect['listen_addr']
  listen_addr: ...,
  # praefect['socket_path']
  socket_path: ...,
  # praefect['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # praefect['tls_listen_addr']
  tls_listen_addr: ...,
  # praefect['separate_database_metrics']
  prometheus_exclude_database_from_default_metrics: ...,
  auth: {
    # praefect['auth_token']
    token: ...,
    # praefect['auth_transitioning']
    transitioning: ...,
  },
  logging: {
    # praefect['logging_format']
    format: ...,
    # praefect['logging_level']
    level: ...,
  },
  failover: {
    # praefect['failover_enabled']
    enabled: ...,
  },
  background_verification: {
    # praefect['background_verification_delete_invalid_records']
    delete_invalid_records: ...,
    # praefect['background_verification_verification_interval']
    #
    # IMPORTANT:
    # As part of reconfiguring Praefect, disable this feature.
    # Read about this as described previously.
    #
    verification_interval: 0,
  },
  reconciliation: {
    # praefect['reconciliation_scheduling_interval']
    scheduling_interval: ...,
    # praefect['reconciliation_histogram_buckets']. The old value was configured as a string
    # such as '[0, 1, 2]'. The new value must be an array like [0, 1, 2].
    histogram_buckets: ...,
  },
  tls: {
    # praefect['certificate_path']
    certificate_path: ...,
   # praefect['key_path']
    key_path: ...,
  },
  database: {
    # praefect['database_host']
    host: ...,
    # praefect['database_port']
    port: ...,
    # praefect['database_user']
    user: ...,
    # praefect['database_password']
    password: ...,
    # praefect['database_dbname']
    dbname: ...,
    # praefect['database_sslmode']
    sslmode: ...,
    # praefect['database_sslcert']
    sslcert: ...,
    # praefect['database_sslkey']
    sslkey: ...,
    # praefect['database_sslrootcert']
    sslrootcert: ...,
    session_pooled: {
      # praefect['database_direct_host']
      host: ...,
      # praefect['database_direct_port']
      port: ...,
      # praefect['database_direct_user']
      user: ...,
      # praefect['database_direct_password']
      password: ...,
      # praefect['database_direct_dbname']
      dbname: ...,
      # praefect['database_direct_sslmode']
      sslmode: ...,
      # praefect['database_direct_sslcert']
      sslcert: ...,
      # praefect['database_direct_sslkey']
      sslkey: ...,
      # praefect['database_direct_sslrootcert']
      sslrootcert: ...,
    }
  },
  sentry: {
    # praefect['sentry_dsn']
    sentry_dsn: ...,
    # praefect['sentry_environment']
    sentry_environment: ...,
  },
  prometheus: {
    # praefect['prometheus_grpc_latency_buckets']. The old value was configured as a string
    # such as '[0, 1, 2]'. The new value must be an array like [0, 1, 2].
    grpc_latency_buckets: ...,
  },
  # praefect['graceful_stop_timeout']
  graceful_stop_timeout: ...,
  # praefect['virtual_storages']. The old value was a hash map but the new value is an array.
  virtual_storage: [
    {
      # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]. The name was previously the key in
      # the 'virtual_storages' hash.
      name: ...,
      # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]. The old value was a hash map
      # but the new value is an array.
      node: [
        {
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]. Use NODE_NAME key as the
          # storage.
          storage: ...,
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]['address'].
          address: ...,
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]['token'].
          token: ...,
        },
      ],
    }
  ]
}

2番目のデータベース接続を無効にする

GitLab 16.0では、GitLabはデフォルトで、同じPostgreSQLデータベースを指す2つのデータベース接続を使用するようになっています。

max_connectionsにより大きな値を指定してPostgreSQLを設定する必要がある場合があります。Rakeタスクで、これが必要かどうかを確認できます。

PgBouncerをデプロイしている場合:

インストールタイプに基づく手順に従って、単一のデータベース接続に戻します:

  1. この設定を/etc/gitlab/gitlab.rbに追加します:

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

  2. gitlab-ctl reconfigureを実行します。

マルチノード環境では、この設定をすべてのRailsおよびSidekiqノードで更新する必要があります。

ci.enabledキーをfalseに設定します:

global:
  psql:
    ci:
      enabled: false

config/database.ymlからci:セクションを削除します。

長時間実行されるユーザータイプのデータ変更

GitLab 16.0は、usersテーブルに多数のレコードを持つ大規模なGitLabインスタンスが経由する必要があるバージョンです。

しきい値は30,000 users（30,000ユーザー）で、以下が含まれます:

  • アクティブ、ブロック、承認保留中など、あらゆる状態のデベロッパーおよびその他のユーザー。
  • プロジェクトおよびグループアクセストークンのボットアカウント。

GitLab 16.0では、バッチバックグラウンド移行が導入され、user_type値をNULLから0に移行します。大規模なGitLabでは、この移行が完了するまで数日かかる場合があります。16.1.0以降にアップグレードする前に、移行が正常に完了していることを確認してください。

GitLab 16.1では、16.0 MigrateHumanUserTypeバックグラウンド移行が完了していることを確認するFinalizeUserTypeMigration移行が導入され、完了していない場合は、アップグレード中に16.0の変更を同期的に実行します。

GitLab 16.2では、NOT NULLデータベース制約を実装しています。これは、16.0の移行が完了していない場合には失敗します。

16.0がスキップされた場合（または16.0の移行が完了していない場合）、Linuxパッケージ（Omnibus）とDockerの後続のアップグレードが1時間後に失敗する可能性があります:

FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

この問題にはフィックスフォワードの回避策があります。

回避策でデータベースの変更を完了しようとしているときに、GitLabが使用できない状態になり、500エラーが生成される可能性があります。このエラーは、SidekiqとPumaがデータベーススキーマと互換性のないアプリケーションコードを実行することが原因で発生します。

回避策のプロセスの最後に、SidekiqとPumaが再起動し、その問題が解決されます。

16.2以降へのアップグレード時の未定義列エラー

GitLab 15.11のバグにより、Self-Managedインスタンスでのデータベース変更が誤って無効になりました。詳細については、イシュー408835を参照してください。

GitLabインスタンスが最初に15.11.0、15.11.1、または15.11.2にアップグレードされた場合、データベーススキーマが正しくないため、GitLab 16.2以降へのアップグレードがエラーで失敗します。データベースの変更には、以前の変更が有効になっている必要があります:

PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

GitLab 15.11.3でこのバグの修正が提供されましたが、以前の15.11リリースをすでに実行しているインスタンスでは問題は修正されていません。

インスタンスが影響を受けているかどうか不明な場合は、データベースコンソールで列を確認してください:

select pg_typeof (id_convert_to_bigint) from public.ci_build_needs limit 1;

回避策が必要な場合、このクエリは失敗します:

ERROR:  column "id_convert_to_bigintd" does not exist
LINE 1: select pg_typeof (id_convert_to_bigintd) from public.ci_buil...

影響を受けていないインスタンスは、以下を返します:

 pg_typeof
-----------
 bigint

この問題の回避策は、GitLabインスタンスのデータベーススキーマが最近作成されたかどうかによって異なります:

インストールバージョン回避策
15.9以前15.9
15.1015.10
15.1115.11

ほとんどのインスタンスは、15.9の手順を使用する必要があります。15.10または15.11の手順が必要なのは、ごく最近のインスタンスのみです。バックアップと復元を使用してGitLabを移行した場合、データベーススキーマは元のインスタンスのものです。ソースインスタンスに基づいて回避策を選択します。

次のセクションのコマンドは、Linuxパッケージのインストール用であり、他のインストールタイプとは異なります:

  • sudoを省略します。

  • GitLabコンテナにShellで接続し、同じコマンドを実行します:

    docker exec -it <container-id> bash

回避策: 15.9以前で作成されたインスタンス

# Restore schema
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version IN ('20230130175512', '20230130104819');"
sudo gitlab-rake db:migrate:up VERSION=20230130175512
sudo gitlab-rake db:migrate:up VERSION=20230130104819

# Re-schedule background migrations
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:down VERSION=20230130110855
sudo gitlab-rake db:migrate:up VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130110855

回避策: 15.10で作成されたインスタンス

# Restore schema for sent_notifications
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version = '20230130175512';"
sudo gitlab-rake db:migrate:up VERSION=20230130175512

# Re-schedule background migration for sent_notifications
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130202201

# Restore schema for ci_build_needs
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"

回避策: 15.11で作成されたインスタンス

# Restore schema for sent_notifications
sudo gitlab-rake db:migrate:down VERSION=20230411153310
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230411153310');"

# Restore schema for ci_build_needs
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"