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は特別なファイルシステムを必要とせず、マウントされたStorage Applianceで動作します。ただし、リモートファイルシステムを使用する場合、パフォーマンスの制限や一貫性の問題が発生する可能性があります。

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

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

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

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

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

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

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

コンテナリポジトリ

コンテナリポジトリはコンテナレジストリに保存されます。これらはコンテナレジストリをデータストアとして構築された、GitLab固有のコンセプトです。

blob

GitLabは、イシューの添付ファイルやLFSオブジェクトなどのファイルやblobを以下のいずれかに保存します:

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

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

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

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

データベース

GitLabは、さまざまなユースケースのために複数のデータベースに保存されているデータに依存しています。PostgreSQLは、Webインターフェース内のユーザー生成コンテンツ（イシューのコンテンツ、コメント、権限、および認証情報など）の単一の真実点です。

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

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

Redisは、キャッシュデータストアとして、またバックグラウンドジョブシステム用の永続データを保持するために使用されます。両方のユースケースには同じGeoサイトに固有のデータがあるため、サイト間でレプリケートすることはありません。

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

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

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

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

一部のデータ型のレプリケーションは、機能フラグの背後でリリースされており、enabled by defaultで有効になっています。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という名前の機能フラグでデフォルトで有効になりました。