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

注：リポジトリとWikiの自動バックグラウンド検証はGitLab EE 10.6で追加されましたが、GitLab EE 11.1でのみデフォルトで有効になっています。

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

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

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

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

自動バックグラウンド検証の無効化または有効化

プライマリノードのRailsコンソールで以下のコマンドを実行します： 

gitlab-rails console

自動バックグラウンド確認が有効になっているかどうかを確認するには 

Gitlab::Geo.repository_verification_enabled?

自動バックグラウンド検証を無効にするには 

Feature.disable('geo_repository_verification')

自動バックグラウンド検証を有効にするには 

Feature.enable('geo_repository_verification')

リポジトリの検証

プライマリノードの Admin Area > Geoダッシュボードに移動し、そのノードの検証情報タブを展開してリポジトリとWikiの自動チェックサムステータスを表示します。 成功した場合は緑色、保留中の作業は灰色、失敗した場合は赤色で表示されます。

Verification status

セカンダリノードの 管理エリア > Geoダッシュボードに移動し、そのノードの検証情報タブを展開して、リポジトリと Wiki の自動検証ステータスを表示します。 チェックサムの場合と同様に、成功した場合は緑色、保留中の場合は灰色、失敗した場合は赤色で表示されます。

Verification status

チェックサムを使った Geo ノードの比較

Geoセカンダリノードの健全性をチェックするために、Git参照のリストとその値のチェックサムを使います。チェックサムには、HEAD、heads、tags、notes、そしてGitLab固有の参照が含まれ、真の一貫性を保証します。 2つのノードのチェックサムが同じであれば、それらは間違いなく同じ参照を保持しています。 更新のたびに各ノードのチェックサムを計算し、すべてのノードが同期していることを確認します。

リポジトリの再検証

GitLab Enterprise Edition 11.6で導入され、GitLab Premiumで利用可能になりました。

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

プライマリ・ノードの Admin Area > Geoダッシュボードに移動し、プライマリ・ノードの[Edit]ボタンをクリックして最小再検証間隔をカスタマイズします：

Re-verification interval

バックグラウンドでの自動再検証はデフォルトで有効になっていますが、必要に応じて無効にすることもできます。プライマリノードのRailsコンソールで以下のコマンドを実行します： 

gitlab-rails console

自動バックグラウンド再検証を無効にするには 

Feature.disable('geo_repository_reverification')

自動バックグラウンド再検証を有効にするには 

Feature.enable('geo_repository_reverification')

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

Geo は、リポジトリの再同期がバックオフ期間付きで行われるように、検証の失敗を積極的に修正しようとします。 手動でリセットしたい場合、この Rake タスクは、検証が失敗したプロジェクトやチェックサムの不一致を、バックオフ期間なしで再同期するようにマークします：

リポジトリ用： 

sudo gitlab-rake geo:verification:repository:reset

ウィキの場合： 

sudo gitlab-rake geo:verification:wiki:reset

チェックサムの不一致による相違の調整

プライマリ・ノードと セカンダリ・ノードにチェックサム検証の不一致がある場合、その原因が明らかでないことがあります。 チェックサムの不一致の原因を見つけるには、以下の手順に従います：

  1. プライマリ・ノードの Admin Area > Overview > Projectsダッシュボードに移動し、チェックサムの差分をチェックしたいプロジェクトを見つけ、Editボタンをクリックします：Projects dashboard

  2. プロジェクト管理ページで、Gitalyストレージ名とGitaly相対パスを取得します：Project admin page

  3. プライマリノードと セカンダリノードの両方で、プロジェクトのリポジトリディレクトリに移動します（パスは通常/var/opt/gitlab/git-data/repositories）。git_data_dirsがカスタマイズされている場合は、念のためサーバーのディレクトリレイアウトを確認してください。 

    cd /var/opt/gitlab/git-data/repositories

  4. プライマリ・ノードで以下のコマンドを実行し、出力をファイルにリダイレクトします： 

    git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-node-refs

  5. セカンダリー・ノードで以下のコマンドを実行し、出力をファイルにリダイレクトします： 

    git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-node-refs

  6. 同じシステム上に前のステップで作成したファイルをコピーし、内容の差分を取ってください： 

    diff primary-node-refs secondary-node-refs

現在の制限

自動バックグラウンド検証では、添付ファイル、LFS オブジェクト、ジョブ アーティファクト、およびファイル ストレージ内のユーザー アップロードは対象外です。 Geo：レプリケートされたすべてのデータの検証」に含めるために、進行状況を追跡することができます。

今のところ、両方のノードで以下の手順に従い、出力を比較することで、それらの整合性を手動で検証することができます。

GitLab EE 12.1では、Geoは転送後にセカンダリノード上の添付ファイル、LFSオブジェクト、アーカイブされたトレースのチェックサムを計算し、保存されているチェックサムと比較し、不一致の場合は転送を拒否します。 Geoは現在、これらのデータがGitLab EE 12.1より前に同期されている場合の自動検証方法をサポートしていないことに注意してください。

オブジェクト・ストレージ内のデータは、オブジェクト・ストアがデータの完全性を保証する責任を負うため、検証されません。