降格されたプライマリサイトをオンラインに戻します

フェイルオーバー後、降格されたプライマリサイトに復元して、元の設定を復元できます。このプロセスは、次の2つのステップで構成されています:

1. 古いプライマリサイトをセカンダリサイトにします。
2. セカンダリサイトをプライマリサイトにプロモートします。

以前のプライマリサイトをセカンダリサイトとして設定する

以前のプライマリサイトは現在のプライマリサイトと同期していないため、まず以前のプライマリサイトを最新の状態にする必要があります。リポジトリやアップロードなど、ディスクに保存されているデータの削除は、以前のプライマリサイトを同期に戻す際には再生されないため、ディスク使用量が増加する可能性があります。または、これを回避するために、新しいセカンダリ GitLabインスタンスをセットアップすることもできます。

以前のプライマリサイトを最新の状態にするには、次の手順を実行します:

1. 遅れている以前のプライマリサイトにSSHで接続します。

2. /etc/gitlab/gitlab-cluster.jsonが存在する場合は削除します。

   セカンダリサイトとして再度追加されるサイトがgitlab-ctl geo promoteコマンドでプロモートされた場合、/etc/gitlab/gitlab-cluster.jsonファイルが含まれている可能性があります。たとえば、gitlab-ctl reconfigureの実行中に、次のような出力が表示される場合があります:

   The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb

   その場合は、/etc/gitlab/gitlab-cluster.jsonをサイト内のすべてのSidekiq、PostgreSQL、Gitaly、およびRailsノードから削除して、/etc/gitlab/gitlab.rbを再び信頼できる唯一の情報源にする必要があります。

3. すべてのサービスが起動していることを確認してください:

   sudo gitlab-ctl start

   プライマリサイトを完全にブロックした場合は、これらの手順を元に戻す必要があります。Debian/Ubuntu/CentOS7+などのsystemdを搭載したディストリビューションの場合は、sudo systemctl enable gitlab-runsvdirを実行する必要があります。CentOS 6などのsystemdを使用しないディストリビューションの場合は、GitLabインスタンスを最初からインストールし、セカンダリサイトとしてセットアップする必要があります（セットアップ手順を参照）。この場合、次の手順に従う必要はありません。

   DNSレコードを変更した場合 、このディザスターリカバリー手順中に、このサイトへのすべての書き込みをブロックする必要がある場合があります。

4. Geoをセットアップする。この場合、セカンダリサイトは以前のプライマリサイトを指します。

   1. PgBouncerがcurrent secondary（現在のセカンダリ）サイト（プライマリサイトだったとき）で有効になっている場合は、/etc/gitlab/gitlab.rbを編集し、sudo gitlab-ctl reconfigureを実行して無効にします。
   2. 次に、セカンダリサイトでデータベースのレプリケーションをセットアップできます。

元のプライマリサイトを紛失した場合は、セットアップ手順に従って、新しいセカンダリサイトをセットアップします。

セカンダリサイトをプライマリサイトにプロモートする

最初のレプリケーションが完了し、プライマリサイトとセカンダリサイトがほぼ同期している場合は、計画されたフェイルオーバーを実行できます。

セカンダリサイトを復元します

目標が再び2つのサイトを持つことである場合は、セカンダリサイトに対して、最初の手順（以前のプライマリサイトをセカンダリサイトとして設定する）を繰り返して、セカンダリサイトをオンラインに戻す必要があります。

追加のセカンダリサイトの復元

セカンダリサイトが複数ある場合は、残りのサイトをオンラインにすることができます。残りの各サイトについて、プライマリサイトとのレプリケーションプロセスを開始します。

セカンダリサイトでのデータの再転送のスキップ

セカンダリサイトが追加されたときに、プライマリから同期されるデータがサイトに含まれている場合、Geoはデータの再転送を回避します。

• Gitリポジトリはgit fetchによって転送され、不足しているrefsのみが転送されます。
• Geoのコンテナレジストリ同期コードは、タグ付けとダイジェストのタプルを比較し、不足しているもののみをプルします。
• 最初の同期でblobが存在する場合、スキップされます。

ユースケース:

• フェイルオーバーを計画し、古いプライマリサイトをセカンダリサイトとしてアタッチして、再構築せずに降格させます。
• 複数のセカンダリGeoサイトがあります。フェイルオーバーを計画し、他のセカンダリGeoサイトを再構築せずに再アタッチします。
• セカンダリサイトをプロモートおよび降格してフェイルオーバーテストを実行し、再構築せずに再アタッチします。
• バックアップを復元し、サイトをセカンダリサイトとしてアタッチします。
• データをセカンダリサイトに手動でコピーして、同期の問題を回避します。
• Geoトラッキングデータベースでレジストリテーブルの行を削除するか、切り詰めるして、問題を回避します。
• Geoトラッキングデータベースをリセットして、問題を回避します。

BLOBの再転送のスキップ

blobデータが既存のセカンダリサイトを追加すると、セカンダリGeoサイトはそのデータの再転送を回避します。これは以下に適用されます:

• CIジョブのアーティファクト
• CIパイプラインアーティファクト
• CIセキュアファイル
• LFSオブジェクト
• マージリクエストの差分
• パッケージファイル
• ページのデプロイ
• Terraform状態バージョン
• アップロード
• 依存プロキシマニフェスト
• 依存プロキシバイナリラージオブジェクト

セカンダリサイトのコピーが実際に破損している場合、バックグラウンド検証は最終的に失敗し、blobが再同期されます。

blobは、Geoトラッキングデータベースに対応するレジストリレコードがない場合にのみ、この方法でスキップされます。再同期はほぼ常に意図的であり、誤って転送をスキップするリスクを冒すことができないため、条件は厳格です。