サポートされているGeoデータタイプ

Geoデータタイプとは、1つ以上のGitLab機能が関連情報を保存するために必要とする特定のデータクラスのことです。

これらの機能によって生成されたデータをGeoでレプリケートするには、アクセス、転送、および検証を行うためのいくつかの戦略を使用します。

データタイプ

以下のさまざまなデータタイプを区別します:

• Gitリポジトリ
• コンテナリポジトリ
• blob
• データベース

以下に、レプリケートする各機能またはコンポーネント、対応するデータタイプ、レプリケーション、および検証方法のリストを示します:

脚注:

1. Redisレプリケーションは、Redis SentinelでHAの一部として使用できます。Geoサイト間では使用されません。
2. オブジェクトストレージのレプリケーションは、Geoまたはオブジェクトストレージプロバイダー/アプライアンスのネイティブレプリケーション機能によって実行できます。
3. オブジェクトストレージの検証は、機能フラグ geo_object_storage_verification 16.4で導入され、デフォルトで有効になっています。ファイルサイズチェックサムを使用して、ファイルを検証します。

Gitリポジトリ

GitLabインスタンスには、1つ以上のリポジトリシャードを設定できます。各シャードには、ローカルに保存されたGitリポジトリへのアクセスと操作を可能にするGitalyインスタンスがあります。これは、次のマシンで実行できます:

• 単一のディスクを使用しているマシン。
• 複数のディスクが（RAIDアレイなどの構成により）単一のマウントポイントとしてマウントされているマシン。
• LVMを使用しているマシン。

GitLabは特別なファイルシステムを必要とせず、マウントされたストレージアプライアンスで動作します。ただし、リモートファイルシステムを使用すると、パフォーマンスの制限や整合性の問題が発生する可能性があります。

GeoはGitalyのガベージコレクションをトリガーし、Geoセカンダリサイト上のフォークしたリポジトリを重複排除します。

Gitaly gRPC APIが通信を行い、次の3つの同期方法があります:

• （特別な認証を使用して）あるGeoサイトから別のGeoサイトへの通常のGitクローン/フェッチを使用します。
• （最初の方法が失敗した場合、またはリポジトリが破損している場合）リポジトリのスナップショットを使用します。
• 管理者エリアからの手動トリガー（リストされている他の可能な方法を組み合わせます）。

各プロジェクトは、最大3つの異なるリポジトリを持つことができます:

• ソースコードを保存するプロジェクトリポジトリ。
• Wikiコンテンツを保存するWikiリポジトリ。
• デザインアーティファクトをインデックス登録するデザインリポジトリ（実際のアセットはLFSに保存されます）。

これらのリポジトリはすべて同じシャード内に存在し、Wikiリポジトリとデザインリポジトリは同じベース名を共有し、それぞれ-wikiおよび-designというサフィックスが付きます。

それ以外に、スニペットリポジトリがあります。これらは、プロジェクトまたは特定のユーザーに接続できます。どちらのタイプもセカンダリサイトに同期されます。

コンテナリポジトリ

コンテナリポジトリは、コンテナレジストリに格納されます。これらは、データストアとしてのコンテナレジストリ上に構築されたGitLab固有の概念です。

blob

イシューの添付ファイルやLFSオブジェクトなどのファイルとblobをGitLabが格納する場所:

• 特定の場所にあるファイルシステム。
• オブジェクトストレージソリューション。オブジェクトストレージソリューションには、次のものがあります:
  • Amazon S3やGoogle Cloud Storageなど、クラウドベースのもの。
  • ユーザー自身がホストするもの（MinIOなど）。
  • オブジェクトストレージ互換APIを提供するストレージアプライアンス。

オブジェクトストレージの代わりにファイルシステムストアを使用する場合は、複数のノードを使用するときにネットワークマウントされたファイルシステムを使用してGitLabを実行します。

レプリケーションと検証に関して:

• 内部APIリクエストを使用して、ファイルとblobを転送します。
• オブジェクトストレージを使用すると、次のいずれかを行うことができます:
  • クラウドプロバイダーレプリケーション機能を使用します。
  • GitLabにレプリケートさせます。

データベース

GitLabは、さまざまなユースケースに対応するため、複数のデータベースに格納されたデータに依存しています。PostgreSQLは、イシューコンテンツ、コメント、権限、認証情報など、Webインターフェースでユーザーが生成したコンテンツの信頼できる唯一の情報源です。

PostgreSQLは、HTMLレンダリングされたMarkdownやキャッシュされたマージリクエストの差分など、ある程度のレベルのキャッシュされたデータを保持することもできます。これは、オブジェクトストレージにオフロードするように構成することもできます。

プライマリサイトからセカンダリサイトにデータをレプリケートするために、PostgreSQL独自のレプリケーション機能を使用します。

GitLabは、キャッシュストアとして、またバックグラウンドジョブシステム用の永続データを保持するためにRedisを使用します。どちらのユースケースも同じGeoサイトに排他的なデータを持っているため、サイト間でレプリケートすることはありません。

Elasticsearchは、高度な検索のためのオプションのデータベースです。これにより、ソースコードレベルと、イシュー、マージリクエスト、ディスカッションにおけるユーザー生成コンテンツの両方で、検索を改善できます。ElasticsearchはGeoではサポートされていません。

レプリケートされるデータタイプ

機能フラグの背後にあるレプリケートされたデータタイプ

（一部のデータタイプで）レプリケーションを有効または無効にする

一部のデータタイプのレプリケーションは、デフォルトで有効になっている機能フラグの背後でリリースされます。GitLab Railsコンソールへのアクセス権を持つGitLab管理者は、インスタンスに対してそれを無効にすることを選択できます。これらの各データタイプの機能フラグ名は、以下の表の備考欄に記載されています。

無効にするには（パッケージファイルのレプリケーションなど）:

Feature.disable(:geo_package_file_replication)

有効にするには（パッケージファイルのレプリケーションなど）:

Feature.enable(:geo_package_file_replication)

脚注:

1. 15.5でセルフサービスフレームワークに移行しました。詳細については、GitLabイシュー#337436を参照してください。
2. 15.11でセルフサービスフレームワークに移行しました。geo_project_wiki_repository_replication機能フラグの背後にあり、デフォルトで有効になっています。詳細については、GitLabイシュー#367925を参照してください。
3. オブジェクトストレージに格納されているファイルの検証は、GitLab 16.4で導入されました（geo_object_storage_verificationという名前の機能フラグを使用）。