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

自動バックグラウンド検証

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

自動バックグラウンド検証により、転送されたデータが計算されたチェックサムと一致することが保証されます。プライマリサイトのデータのチェックサムがセカンダリサイトのデータのチェックサムと一致する場合、データは正常に転送されています。計画的フェイルオーバー後、破損の程度によっては、破損したデータがlost(失われる)可能性があります。

プライマリサイトでの検証が失敗した場合、これはGeoが破損したオブジェクトをレプリケートしていることを示します。バックアップから復元するか、プライマリサイトから削除して、問題を解決できます。

プライマリサイトでの検証が成功し、セカンダリサイトでの検証が失敗した場合、これはオブジェクトがレプリケーション処理中に破損したことを示します。Geoは、バックオフ期間を設けて、リポジトリを再同期するようにマークすることにより、検証の失敗を積極的に修正しようとします。これらの失敗に対する検証をリセットする場合は、次の手順に従ってください。

検証がレプリケーションより大幅にラグしている場合は、計画的なフェイルオーバーをスケジュールする前に、サイトにもう少し時間を与えることを検討してください。

リポジトリの検証

プライマリサイトで:

  1. 左側のサイドバーの下部で、管理者を選択します。

  2. Geo > サイトを選択します。

  3. そのサイトの検証情報タブを展開して、リポジトリとWikiの自動チェックサムステータスを表示します。成功は緑色、保留中の作業は灰色、失敗は赤色で表示されます。

    正常なプライマリGeoインスタンスの概要を示す検証情報タブ。

セカンダリサイトで:

  1. 左側のサイドバーの下部で、管理者を選択します。

  2. Geo > サイトを選択します。

  3. そのサイトの検証情報タブを展開して、リポジトリとWikiの自動チェックサムステータスを表示します。成功は緑色、保留中の作業は灰色、失敗は赤色で表示されます。

    正常なセカンダリGeoインスタンスの概要を示す検証情報タブ。

チェックサムを使用してGeoサイトを比較する

Geoのセカンダリサイトのヘルス状態を確認するために、Gitの参照とその値のリスト全体でチェックサムを使用します。チェックサムには、真の整合性を確保するために、HEADheadstagsnotes、およびGitLab固有の参照が含まれます。2つのサイトのチェックサムが同じ場合、それらは間違いなく同じ参照を保持しています。すべてのサイトが同期していることを確認するために、更新ごとにすべてのサイトのチェックサムをコンピューティングします。

リポジトリの再検証

バグまたは一時的なインフラストラクチャの失敗により、Gitのリポジトリが検証用にマークされずに予期せず変更される可能性があります。Geoは、データの整合性を確保するために、リポジトリを常に再検証します。デフォルトおよび推奨される再検証間隔は7日間ですが、1日という短い間隔を設定することもできます。間隔が短いほどリスクは軽減されますが、負荷が増加し、逆もまた同様です。

プライマリサイトで:

  1. 左側のサイドバーの下部で、管理者を選択します。

  2. Geo > サイトを選択します。

  3. 最小再検証間隔をカスタマイズするには、プライマリサイトの編集を選択します:

    Geoノードの設定属性を示すウィンドウ。

検証に失敗したプロジェクトの検証をリセットする

Geoは、バックオフ期間を設けて、リポジトリを再同期するようにマークすることにより、検証の失敗を積極的に修正しようとします。UIまたはRailsコンソールを使用して、個々のコンポーネントを手動で再同期および再検証することもできます。

チェックサムの不一致による差分を調整する

プライマリサイトとセカンダリサイトにチェックサム検証の不一致がある場合、原因が明らかでない可能性があります。チェックサムの不一致の原因を見つけるには、次の手順に従います:

  1. プライマリサイトで:

    1. 左側のサイドバーの下部で、管理者を選択します。
    2. 左側のサイドバーで、概要 > プロジェクトを選択します。
    3. チェックサムの差を確認するプロジェクトを見つけて、その名前を選択します。
    4. プロジェクト管理ページで、Storage name(リポジトリストレージ名)フィールドとRelative path(相対パス)フィールドの値を取得します。
  2. プライマリサイトのGitalyノードセカンダリサイトのGitalyノードで、プロジェクトのリポジトリディレクトリに移動します。Gitaly Cluster (Praefect)を使用している場合は、これらのコマンドを実行する前に、正常な状態にあることを確認してください。

    デフォルトのパスは/var/opt/gitlab/git-data/repositoriesです。リポジトリストレージがカスタマイズされている場合は、サーバー上のディレクトリレイアウトを確認して、確認してください:

    cd /var/opt/gitlab/git-data/repositories
    1. プライマリサイトで次のコマンドを実行し、出力をファイルにリダイレクトします:

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-site-refs
    2. セカンダリサイトで次のコマンドを実行し、出力をファイルにリダイレクトします:

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-site-refs
    3. 同じシステムの前の手順からファイルをコピーし、コンテンツ間で差分をとります:

      diff primary-site-refs secondary-site-refs

現在の制限事項

レプリケーションおよび検証でサポートされているメソッドの詳細については、サポートされているGeoデータ型を参照してください。