ディザスターリカバリー（Geo）

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

Geoは、データベース、Gitリポジトリ、その他の資産をレプリケートします。既知の問題が存在します。

マルチセカンダリ構成では、プロモートされないすべてのセカンダリの完全な再同期と再設定が必要となり、停止が発生します。

シングルセカンダリ構成でのセカンダリ Geoサイトのプロモート

Geoレプリカを自動的にプロモートしてフェイルオーバーを実行することはできませんが、マシンへのrootアクセス権があれば、手動でプロモートできます。

このプロセスでは、セカンダリ Geoサイトをプライマリサイトにプロモートします。地理的な冗長性をできるだけ早く回復するには、これらの手順に従った直後に、新しいセカンダリサイトを追加する必要があります。

ステップ1.可能であれば、レプリケーションが完了するのを待ちます

セカンダリサイトがプライマリサイトからデータをレプリケートしている場合は、不必要なデータ損失を避けるために、計画されたフェイルオーバードキュメントにできる限り厳密に従ってください。

ステップ2.プライマリサイトを完全に無効にします

プライマリサイトが停止した場合、プライマリサイトに保存されているデータがセカンダリサイトにレプリケートされていない可能性があります。続行する場合は、このデータを失われたものとして扱う必要があります。

プライマリサイトで停止が発生した場合、書き込みが2つの異なるGitLabインスタンスで発生する可能性のあるスプリットブレイン状態を回避するために、あらゆる可能な限りのことを行う必要があります。これにより、リカバリー作業が複雑になります。そのため、フェイルオーバーに備えるには、プライマリサイトを無効にする必要があります。

SSHアクセスがある場合:
1. プライマリサイトにSSHで接続し、GitLabをブロックして無効にします:
```
sudo gitlab-ctl stop
```
2. サーバーが予期せず再起動した場合に、GitLabが再度起動しないようにします:
```
sudo systemctl disable gitlab-runsvdir
```
プライマリサイトへのSSHアクセスがない場合は、マシンをオフラインにし、利用できるあらゆる手段で再起動しないようにします。次のことを行う必要があるかもしれません:
- ロードバランサーを再設定します。
- DNSレコードを変更します（たとえば、セカンダリサイトを指すプライマリDNSレコードを指定して、プライマリサイトの使用を停止します）。
- 仮想サーバーを停止します。
- ファイアウォールを通過するトラフィックをブロックします。
- プライマリサイトからオブジェクトストレージの権限を失効します。
- マシンを物理的に切断します。
プライマリドメインDNSレコードを更新することを計画している場合は、DNSの変更を迅速に伝達するために、低いTTLを維持することをお勧めします。
このプロセス中に、プライマリサイトの/etc/gitlab/gitlab.rbファイルは、セカンダリサイトに自動的にコピーされません。プライマリの/etc/gitlab/gitlab.rbファイルをバックアップして、後でセカンダリサイトに必要な値を復元できるようにしてください。

ステップ3.セカンダリサイトのプロモート

セカンダリをプロモートするときは、以下に注意してください:

セカンダリサイトが一時停止された場合、プロモートにより、最後に認識された状態へのポイントインタイムリカバリーが実行されます。セカンダリが一時停止している間にプライマリで作成されたデータは失われます。
この時点では、新しいセカンダリを追加しないでください。新しいセカンダリを追加する場合は、セカンダリをプライマリにプロモートするプロセス全体を完了した後に行ってください。
このプロセス中にActiveRecord::RecordInvalid: Validation failed: Name has already been takenエラーメッセージが表示された場合は、このトラブルシューティングのアドバイスを参照してください。
個別のURLを使用している場合は、新しくプロモートされたサイトでプライマリドメインDNSをポイントする必要があります。それ以外の場合は、新しくプロモートされたサイトにRunnerを再度登録し、すべてのGitリモート、ブックマーク、および外部インテグレーションを更新する必要があります。
ロケーション対応DNSを使用している場合、古いプライマリがDNSエントリから削除されると、Runnerは自動的に新しいプライマリに接続します。
以前のプライマリに接続されていたRunnerが戻ってこないと予想される場合は、削除する必要があります:
- UIを使用する場合は、以下のとおりです:
  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 左側のサイドバーの下部にあるCI/CD > Runnersを選択して、それらを削除します。
- Runners APIを使用します。

セカンダリサイトを単一ノードで実行するプロモート

セカンダリサイトにSSHでログインして実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
以前にセカンダリサイトに使用したURLを使用して、新しくプロモートされたプライマリサイトに接続できることを確認します。
成功した場合、セカンダリサイトはプライマリサイトにプロモートされました。

複数のノードを持つセカンダリサイトをプロモート

セカンダリサイトのすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリサイトのノードをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
セカンダリサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
以前にセカンダリサイトに使用したURLを使用して、新しくプロモートされたプライマリサイトに接続できることを確認します。
成功した場合、セカンダリサイトはプライマリサイトにプロモートされました。

Patroniスタンバイクラスタリングを持つセカンダリサイトをプロモート

セカンダリサイトのすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
セカンダリサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
以前にセカンダリサイトに使用したURLを使用して、新しくプロモートされたプライマリサイトに接続できることを確認します。
成功した場合、セカンダリサイトはプライマリサイトにプロモートされました。

外部PostgreSQLデータベースを持つセカンダリサイトをプロモート

gitlab-ctl geo promoteコマンドは、外部PostgreSQLデータベースと組み合わせて使用できます。この場合、最初にセカンダリサイトに関連付けられているレプリカデータベースを手動でプロモートする必要があります:

セカンダリサイトに関連付けられているレプリカデータベースをプロモートします。これにより、データベースが読み取り/書き込みに設定されます。手順は、データベースのホスト場所によって異なります:
- Amazon RDS
- Azure PostgreSQL
- Google Cloud SQL
- 他の外部PostgreSQLデータベースの場合は、セカンダリサイト（たとえば、/tmp/geo_promote.sh）に次のスクリプトを保存し、環境変数に合わせて接続パラメータを変更します。次に、それを実行してレプリカをプロモートします:
```
#!/bin/bash

PG_SUPERUSER=postgres

# The path to your pg_ctl binary. You may need to adjust this path to match
# your PostgreSQL installation
PG_CTL_BINARY=/usr/lib/postgresql/16/bin/pg_ctl

# The path to your PostgreSQL data directory. You may need to adjust this
# path to match your PostgreSQL installation. You can also run
# `SHOW data_directory;` from PostgreSQL to find your data directory
PG_DATA_DIRECTORY=/etc/postgresql/16/main

# Promote the PostgreSQL database and allow read/write operations
sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote
```
セカンダリサイトのすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
セカンダリサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリサイトをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- セカンダリサイトをさらに確認せずにプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```
以前にセカンダリサイトに使用したURLを使用して、新しくプロモートされたプライマリサイトに接続できることを確認します。
成功した場合、セカンダリサイトはプライマリサイトにプロモートされました。

ステップ4.（オプション）プライマリドメインDNSレコードの更新

プライマリドメインのDNSレコードを更新して、セカンダリサイトを指すようにします。これにより、GitリモートやAPI URLを変更するなど、プライマリドメインへのすべての参照を更新する必要がなくなります。

セカンダリサイトにSSHで接続し、ルートとしてログインします:
```
sudo -i
```
プライマリドメインのDNSレコードを更新します。プライマリドメインのDNSレコードを更新してセカンダリサイトをポイントした後、セカンダリサイトの/etc/gitlab/gitlab.rbを編集して、新しいURLを反映させます:
```
# Change the existing external_url configuration
external_url 'https://<new_external_url>'
```
external_url変更しても、セカンダリDNSレコードがまだそのまま残っていれば、古いセカンダリURLを介したアクセスを防ぐことはできません。
セカンダリのSSL証明書を更新します:
- Let’s Encryptインテグレーションを使用している場合、証明書は自動的に更新されます。
- 手動でセットアップした場合、セカンダリの証明書は、プライマリからセカンダリに証明書をコピーします。プライマリにアクセスできない場合は、新しい証明書を発行し、サブジェクトの別名にプライマリとセカンダリの両方のURLが含まれていることを確認してください。以下で確認できます:
```
/opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
    -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
```
変更を有効にするには、セカンダリサイトを再設定します:
```
gitlab-ctl reconfigure
```
新しくプロモートされたプライマリサイトURLを更新するには、以下のコマンドを実行します:
```
gitlab-rake geo:update_primary_node_url
```
このコマンドは、/etc/gitlab/gitlab.rbで定義された変更されたexternal_url設定を使用します。
URLを使用して、新しくプロモートされたプライマリに接続できることを確認します。プライマリドメインのDNSレコードを更新した場合、これらの変更は、以前のDNSレコードのTTLによってはまだ伝播されていない可能性があります。

ステップ5.（オプション）プロモートされたプライマリサイトへのセカンダリ Geoサイトの追加

以前のプロセスを使用してセカンダリサイトをプライマリサイトにプロモートしても、新しいプライマリサイトでGeoは有効になりません。

新しいセカンダリサイトをオンラインにするには、Geoセットアップ手順に従います。

ステップ6.以前のセカンダリのトラッキングデータベースの削除

すべてのセカンダリには、プライマリからのすべてのアイテムの同期ステータスを保存するために使用される特別なトラッキングデータベースがあります。セカンダリはすでにプロモートされているため、トラッキングデータベース内のそのデータは不要になりました。

次のコマンドを使用してデータを削除できます:

sudo rm -rf /var/opt/gitlab/geo-postgresql

gitlab.rbファイルでgeo_secondary[]設定オプションが有効になっている場合は、それらをコメントアウトするか削除して、GitLabを再設定しますして、変更を有効にします。

この時点で、プロモートされたサイトは、Geoが設定されていない通常のGitLabサイトです。オプションで、古いサイトをセカンダリとして戻すことができます。

マルチセカンダリ構成でのセカンダリGeoレプリカのプロモート

複数のセカンダリサイトがあり、そのうちの1つをプロモートする必要がある場合は、セカンダリ Geoサイトをシングルセカンダリ構成でプロモートすることをお勧めします。その後、さらに2つの手順が必要になります。

ステップ1.1つ以上のセカンダリサイトを提供する新しいプライマリサイトを準備します

新しいプライマリサイトにSSHで接続し、ルートとしてログインします:
```
sudo -i
```

/etc/gitlab/gitlab.rbを編集します:

## Enable a Geo Primary role (if you haven't yet)
roles ['geo_primary_role']

##
# Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
# public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

# Every secondary site needs to have its own slot so specify the number of secondary sites you're going to have
# postgresql['max_replication_slots'] = 1 # Set this to be the number of Geo secondary nodes if you have more than one

##
## Disable automatic database migrations temporarily
## (until PostgreSQL is restarted and listening on the private address).
##
gitlab_rails['auto_migrate'] = false

（これらの設定の詳細については、プライマリサーバーの設定を参照してください）

ファイルを保存し、データベースのリスンの変更と適用されるレプリケーションスロットの変更のために、GitLabを再設定します:
```
gitlab-ctl reconfigure
```
変更を有効にするには、PostgreSQLを再起動します:
```
gitlab-ctl restart postgresql
```
PostgreSQLが再起動され、プライベートアドレスをリッスンするようになったので、移行を再度有効にします。
/etc/gitlab/gitlab.rbを編集し、設定を変更してtrueにします:
```
gitlab_rails['auto_migrate'] = true
```
ファイルを保存して、GitLabを再設定します:
```
gitlab-ctl reconfigure
```

ステップ2.レプリケーションプロセスの開始

ここで、各セカンダリサイトに、新しいプライマリサイトでの変更をリッスンさせる必要があります。そのためには、レプリケーションプロセスを開始する必要がありますが、今回は別のプライマリサイトに対して行います。古いレプリケーション設定はすべて上書きされます。

既存のセカンダリサイトにはすべて入力されたデータベースがあるため、次のようなメッセージが表示される場合があります:

Found data inside the gitlabhq_production database! If you are sure you are in the secondary server, override with --force

適切なセカンダリサイトにいることを確認したら、--forceを使用してレプリケーションを開始します。

--forceを使用すると、そのセカンダリサーバー上のデータベース内の既存のデータがすべて削除されます。

GitLab HelmチャートでのセカンダリGeoクラスタリングのプロモート

クラウドネイティブGeoデプロイを更新する場合、セカンダリKubernetesクラスタの外部にあるノードを更新するプロセスは、クラウドネイティブではないアプローチとは異なります。そのため、詳細については、シングルセカンダリ構成でのセカンダリGeoサイトのプロモートを参照してください。

以下のセクションでは、gitlabネームスペースを使用していることを前提としています。クラスターのセットアップ時に別のネームスペースを使用した場合は、--namespace gitlabを自分のネームスペースに置き換える必要もあります。

ステップ1.プライマリクラスターを完全に無効にする

プライマリサイトがオフラインになると、プライマリサイトに保存されているデータのうち、セカンダリサイトにレプリケートされていないデータがある可能性があります。続行する場合は、このデータを失われたものとして扱う必要があります。

プライマリ Kubernetesクラスターへのアクセス権がある場合は、それに接続して、GitLab webserviceおよびSidekiqポッドを無効にします:
```
kubectl --namespace gitlab scale deploy gitlab-geo-webservice-default --replicas=0
kubectl --namespace gitlab scale deploy gitlab-geo-sidekiq-all-in-1-v1 --replicas=0
```
プライマリ Kubernetesクラスターへのアクセス権がない場合は、クラスターをオフラインにし、あらゆる手段を講じてオンラインに戻らないようにします。次のことを行う必要があるかもしれません:
- ロードバランサーを再設定します。
- DNSレコードを変更します（たとえば、セカンダリサイトを指すプライマリDNSレコードを指定して、プライマリサイトの使用を停止します）。
- 仮想サーバーを停止します。
- ファイアウォールを通過するトラフィックをブロックします。
- プライマリサイトからオブジェクトストレージの権限を失効します。
- マシンを物理的に切断します。

ステップ2.クラスターセカンダリサイトのすべてのノードをプロモートします

セカンダリサイトが一時停止された場合、これは、最後に認識された状態への特定時点へのリカバリーを実行します。セカンダリが一時停止している間にプライマリで作成されたデータは失われます。

セカンダリ Kubernetesクラスターの外部にあるPostgreSQLやGitalyなどの各ノードについて、Linuxパッケージを使用して、ノードにSSHでログインし、次のいずれかのコマンドを実行します:
- Kubernetesクラスターの外部にあるセカンダリサイトノードをプライマリにプロモートするには:
```
sudo gitlab-ctl geo promote
```
- Kubernetesクラスターの外部にあるセカンダリサイトノードを、without any further confirmation（それ以上の確認なしに）プライマリにプロモートするには:
```
sudo gitlab-ctl geo promote --force
```

toolboxポッドを見つけます:

kubectl --namespace gitlab get pods -lapp=toolbox

セカンダリをプロモートします:
```
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_secondary_as_primary
```
タスクの動作を変更するために、環境変数を指定できます。使用可能な変数は次のとおりです:
名前デフォルト値説明
ENABLE_SILENT_MODE false trueの場合、プロモートの前にサイレントモードを有効にします（GitLab 16.4以降）

名前	デフォルト値	説明
`ENABLE_SILENT_MODE`	`false`	`true`の場合、プロモートの前にサイレントモードを有効にします（GitLab 16.4以降）

ステップ3.セカンダリクラスターをプロモートします

既存のクラスター設定を更新します。
Helmを使用して既存の設定を取得できます:
```
helm --namespace gitlab get values gitlab-geo > gitlab.yaml
```
既存の設定には、次のようなGeoのセクションが含まれています:
```
geo:
   enabled: true
   role: secondary
   nodeName: secondary.example.com
   psql:
      host: geo-2.db.example.com
      port: 5431
      password:
         secret: geo
         key: geo-postgresql-password
```
セカンダリクラスターをプライマリクラスターにプロモートするには、role: secondaryをrole: primaryに更新します。
クラスターがプライマリサイトとして残っている場合は、psqlセクション全体を削除できます。プライマリサイトとして機能している間は、トラッキングデータベースを参照し、無視されます。
新しい設定でクラスターを更新します:
```
helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
セカンダリに使用されていたURLを使用して、新しくプロモートされたプライマリに接続できることを確認します。
成功!これで、セカンダリがプライマリにプロモートされました。

トラブルシューティング

このセクションは別の場所に移されました。