• データタイプ
  • Gitリポジトリ
  • ブロブ
  • データベース
• レプリケーション/検証の制限
  • 機能フラグの背後にあるレプリケートされたデータタイプ
    • レプリケーションの有効化・無効化（データ型による）

サポートされる Geo データ型

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

これらの機能によって生成されたデータをGeoで複製するために、私たちはいくつかの戦略を使ってアクセス、転送、検証を行います。

データタイプ

私たちは3つの異なるデータタイプを区別しています：

• Gitリポジトリ
• ブロブ
• データベース

レプリケートする各機能やコンポーネント、対応するデータタイプ、レプリケーション、検証方法については、以下のリストをご覧ください：

• (1):Redis レプリケーションは、Redis センチネルを使用した HA の一部として使用できます。Geoサイト間では使用されません。
• (2):オブジェクトストレージのレプリケーションは、Geo またはオブジェクトストレージプロバイダー/アプライアンスのネイティブレプリケーション機能によって実行できます。

Gitリポジトリ

GitLabインスタンスは1つ以上のリポジトリシャードを持つことができます。それぞれのシャードにはGitalyインスタンスがあり、ローカルに保存されたGitリポジトリへのアクセスやオペレーションを担当します。それはマシン上で実行することができます：

• シングルディスク
• 複数のディスクを1つのマウントポイントとしてマウントした場合（RAIDアレイのように）。
• LVMの使用。

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

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

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

• あるGeoサイトから別のGeoサイトへの通常のGit clone/fetchを使用します（特別な認証が必要です）。
• リポジトリのスナップショットを使う（最初の方法が失敗したりリポジトリが壊れたりしたときのため）。
• 管理エリアからの手動トリガー（上記の両方の組み合わせ）。

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

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

これらはすべて同じシャードに存在し、Wikiとデザインリポジトリの場合は、-wiki と-design のサフィックスを持つ同じベース名を共有します。

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

ブロブ

GitLabはファイルやイシューの添付ファイルやLFSオブジェクトのようなブロブをどちらかに保存します：

• 特定の場所のファイルシステム。
• オブジェクトストレージ・ソリューション。オブジェクトストレージ・ソリューションには次のようなものがあります：
  • Amazon S3やGoogle Cloud Storageのようなクラウドベース。
  • MinIOのような）お客様によるホスティング。
  • オブジェクトストレージ互換のAPIを公開するストレージアプライアンス。

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

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

• 内部APIリクエストを使ってファイルやブロブを転送します。
• オブジェクトストレージでは、以下のことが可能です：
  • クラウドプロバイダーのレプリケーション機能を使用します。
  • GitLabにレプリケーションしてもらいましょう。

データベース

GitLabは異なるユースケースのために、複数のデータベースに保存されたデータに依存しています。PostgreSQLは、イシューコンテンツやコメント、権限や認証情報のような、Webインターフェイスでユーザーが作成したコンテンツのための単一の真実のポイントです。

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

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

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

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

レプリケーション/検証の制限

次の表は、GitLabの機能とセカンダリサイトでのレプリケーションと検証のステータスの一覧です。

これらのエピック/イシューで、不足している項目の実装の進捗を把握することができます：

• Geo：セルフサービスGeoレプリケーションフレームワークの改善
• Geo：既存の blob をフレームワークに移動

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

いくつかのデータ型のレプリケーションは、対応する機能フラグの背後にあります：

• これらは機能フラグの後ろにデプロイされ、デフォルトで有効になっています。
• GitLab.comでは有効になっています。
• プロジェクトごとに有効にしたり無効にしたりすることはできません。
• 本番環境での使用を推奨します。
• GitLabセルフマネージドインスタンスでは、GitLab管理者はこれらを無効にすることができます。

レプリケーションの有効化・無効化（データ型による）

いくつかのデータタイプのレプリケーションは、デフォルトで有効になっている機能フラグの後ろにリリースされています。GitLab RailsコンソールにアクセスできるGitLab管理者は、インスタンスに対してこれを無効にすることができます。これらのデータタイプの機能フラグ名は下の表の備考欄にあります。

パッケージファイルのレプリケーションなどを無効にする場合：

Feature.disable(:geo_package_file_replication)

パッケージファイルのレプリケーションなどを有効にします：

Feature.enable(:geo_package_file_replication)

¹ 15.5 でセルフサービスフレームワークにマイグレーションされました。詳細は GitLab issue#337436を参照してください。

² 15.11 でセルフサービスフレームワークにマイグレーションされました。機能フラグgeo_project_wiki_repository_replicationの背後で、デフォルトで有効になっています。詳細は GitLab issue#367925を参照してください。