-
単一セカンダリ設定でのセカンダリGeo サイトの昇格させます。
- ステップ 1.可能であればレプリケーションが終了するのを待ちます。
- ステップ2.プライマリサイトを永久に無効にします。
-
ステップ3.セカンダリサイトの昇格させる
- GitLab 14.5以降が稼働している単一ノード上で稼働しているセカンダリサイトを昇格させる方法
- GitLab 14.4以前が稼働している単一ノード上で稼働しているセカンダリサイトを昇格させます。
- GitLab 14.5 以降が稼働している複数のノードでセカンダリノードを昇格させます。
- GitLab 14.4以前が稼働している複数のノードでセカンダリノードを昇格させます。
- GitLab 14.5以降が稼働しているPatroniスタンバイクラスターでセカンダリサイトを昇格させる場合
- GitLab 14.4以前が動作しているPatroniスタンバイクラスターでセカンダリサイトを昇格させる場合
- GitLab 14.5以降が稼働している外部PostgreSQLデータベースを持つセカンダリサイトを昇格させます。
- GitLab 14.4以前が動作している外部PostgreSQLデータベースを持つセカンダリサイトを昇格させます。
- ステップ4(オプション)プライマリドメインDNSレコードの更新
- ステップ 5.(オプション) 昇格させたプライマリサイトに セカンダリGeo サイトを追加します。
- ステップ 6.旧セカンダリのトラッキングデータベースの削除
- 複数セカンダリ設定でのセカンダリGeoレプリカの昇格させる
- GitLab HelmチャートでセカンダリGeoクラスタを昇格させます。
- トラブルシューティング
ディザスタリカバリ(Geo)
Geoはデータベース、Gitリポジトリ、その他いくつかの資産をレプリケートしますが、いくつかの制限があります。
単一セカンダリ設定でのセカンダリGeo サイトの昇格させます。
現在のところ、Geo レプリカを昇格させてフェイルオーバーを行う自動化された方法は提供していませんが、マシンにroot
アクセスできる場合は手動で行うことができます。
このプロセスは、セカンダリGeo サイトをプライマリサイトに昇格させます。地理的な冗長性をできるだけ早く回復するために、この指示に従った後、すぐに新しいセカンダリサイトを追加してください。
ステップ 1.可能であればレプリケーションが終了するのを待ちます。
セカンダリサイトがまだプライマリサイトからデータをレプリケートしている場合は、不必要なデータ損失を避けるために、計画されたフェイルオーバーのドキュメントにできるだけ忠実に従います。
ステップ2.プライマリサイトを永久に無効にします。
プライマリサイトが停止した場合は、2つの異なるGitLabインスタンスで書き込みが行われるスプリットブレイン(split-brain)状態を避けるために、可能な限りのことを行うべきです。そこで、フェイルオーバーに備えるために、プライマリサイトを無効にしなければなりません。
-
SSH でアクセスできるのなら
-
プライマリサイトにSSH でアクセスし、GitLab を停止して無効にします:
sudo gitlab-ctl stop
-
サーバーが予期せず再起動した場合に、GitLabが再び起動しないようにします:
sudo systemctl disable gitlab-runsvdir
-
-
プライマリサイトにSSH でアクセスできない場合は、マシンをオフラインにして、あらゆる手段で再起動を防ぎます。そのためには
- ロードバランサーを再設定します。
- DNSレコードを変更します(たとえば、プライマリDNSレコードをセカンダリサイトに向け、プライマリサイトの使用を停止します)。
- 仮想サーバーを停止します。
- ファイアウォールを通してトラフィックをブロックします。
- プライマリサイトからオブジェクトストレージの権限を剥奪します。
- マシンを物理的に切断します。
プライマリドメインのDNSレコードを更新する予定がある場合、DNSの変更を迅速に伝搬させるためにTTLを低くメンテナーすることをお勧めします。
ステップ3.セカンダリサイトの昇格させる
セカンダリーを昇格させる際には、以下の点に注意してください:
- セカンダリ・サイトが一時停止されている場合、昇格させると、最後に確認された状態へのポイント・イン・タイム・リカバリが実行されます。セカンダリが一時停止している間にプライマリで作成されたデータは失われます。
- この時点では、新しいセカンダリを追加しないでください。新しいセカンダリを追加する場合は、セカンダリを プライマリに昇格させるプロセスをすべて完了してから行ってください。
- このプロセス中に
ActiveRecord::RecordInvalid: Validation failed: Name has already been taken
のエラーメッセージが表示された場合は、こちらのトラブルシューティングアドバイスを参照してください。
GitLab 14.5以降が稼働している単一ノード上で稼働しているセカンダリサイトを昇格させる方法
-
セカンダリサイトにSSH でログインして実行します:
-
セカンダリサイトをプライマリに昇格させるには、次のコマンドを実行します:
sudo gitlab-ctl geo promote
-
セカンダリ・サイトをプライマリに昇格させる: セカンダリ・サイトをプライマリに昇格させる場合は、次の手順を実行します:
sudo gitlab-ctl geo promote --force
-
- セカンダリ・サイトで以前に使用した URL を使用して、新しく昇格させたプライマリ・サイトに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.4以前が稼働している単一ノード上で稼働しているセカンダリサイトを昇格させます。
gitlab-ctl promote-to-primary-node
とgitlab-ctl promoted-db
コマンドはGitLab 14.5以降では非推奨となり、GitLab 15.0では削除されました。代わりにgitlab-ctl geo promote
。-
セカンダリサイトにSSHでログインし、rootとしてログインします:
sudo -i
-
GitLab 13.5以降を使っている場合は、この手順を飛ばしてください。そうでない場合は、
/etc/gitlab/gitlab.rb
を編集して以下の行を削除してください:geo_secondary_role['enable'] = true roles ['geo_secondary_role']
-
セカンダリサイトを プライマリサイトに昇格させます:
-
プリフライトチェックとともにセカンダリサイトをプライマリに昇格させます:
gitlab-ctl promote-to-primary-node
-
すでにプリフライトチェックを個別に実行している場合、または実行したくない場合は、次のコマンドでスキップできます:
gitlab-ctl promote-to-primary-node --skip-preflight-checks
GitLab 13.7以前では、同期するアイテムがゼロのデータ型でプリフライトチェックをスキップしない場合、レプリケーションが実際に最新であってもセカンダリレポートERROR - Replication is not up-to-date
を昇格させます。レプリケーションと検証出力が完了していることを示している場合、プリフライトチェックをスキップしてコマンドを完全昇格させることができます。このバグはGitLab 13.8以降で修正されました。 -
プリフライトチェックが失敗した場合でも、セカンダリサイトをそれ以上確認することなくプライマリに昇格させるには:
gitlab-ctl promote-to-primary-node --force
-
- セカンダリ・サイトで以前に使用した URL を使用して、新しく昇格させたプライマリ・サイトに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.5 以降が稼働している複数のノードでセカンダリノードを昇格させます。
-
セカンダリサイトのすべての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 を使用して、新しく昇格させたプライマリ・サイトに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.4以前が稼働している複数のノードでセカンダリノードを昇格させます。
gitlab-ctl promote-to-primary-node
とgitlab-ctl promoted-db
コマンドはGitLab 14.5以降では非推奨となり、GitLab 15.0では削除されました。代わりにgitlab-ctl geo promote
。gitlab-ctl promote-to-primary-node
コマンドはまだ複数ノードと組み合わせて使うことができません。単一のノードしかないセカンダリノードに対してしか変更を実行できないからです。代わりに、手動で行う必要があります。
-
セカンダリサイトのデータベースノードにSSHでログインし、PostgreSQLを読み書き可能に昇格させます:
sudo gitlab-ctl promote-db
-
セカンダリサイトの各ノードで
/etc/gitlab/gitlab.rb
を編集し、プライマリとしての新しいステータスを反映させます:geo_secondary_role['enable'] = true roles ['geo_secondary_role']
これらの変更を行った後、各マシンでGitLab を再設定して変更を反映させます。
-
セカンダリを プライマリに昇格させます。一つのアプリケーションサーバーにSSH接続して実行します:
sudo gitlab-rake geo:set_secondary_as_primary
- セカンダリで以前に使用した URL を使用して、新しく昇格させたプライマリに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.5以降が稼働している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 を使用して、新しく昇格させたプライマリ・サイトに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.4以前が動作しているPatroniスタンバイクラスターでセカンダリサイトを昇格させる場合
gitlab-ctl promote-to-primary-node
とgitlab-ctl promoted-db
コマンドはGitLab 14.5以降では非推奨となり、GitLab 15.0では削除されました。代わりにgitlab-ctl geo promote
。gitlab-ctl promote-to-primary-node
コマンドは、セカンダリノードが1ノードしかない場合のみ変更を実行できるため、Patroniスタンバイクラスタと組み合わせて使用することはまだできません。代わりに手動で行う必要があります。
-
セカンダリサイトのスタンバイリーダーデータベースノードにSSHでログインし、PostgreSQLを読み書き昇格させます:
sudo gitlab-ctl promote-db
-
セカンダリのすべてのアプリケーションノードとSidekiqノードの
/etc/gitlab/gitlab.rb
を編集して、プライマリとしての新しいステータスを反映させます:geo_secondary_role['enable'] = true roles ['geo_secondary_role']
-
セカンダリのすべてのPatroniノードで
/etc/gitlab/gitlab.rb
を編集し、スタンバイクラスタを無効にします:patroni['standby_cluster']['enable'] = false
-
変更を有効にするために、それぞれのマシンで GitLab を再設定します:
sudo gitlab-ctl reconfigure
-
セカンダリを プライマリに昇格させます。一つのアプリケーションサーバーにSSH接続して実行します:
sudo gitlab-rake geo:set_secondary_as_primary
- セカンダリで以前に使用した URL を使用して、新しく昇格させたプライマリに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.5以降が稼働している外部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/10/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/10/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 を使用して、新しく昇格させたプライマリ・サイトに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
GitLab 14.4以前が動作している外部PostgreSQLデータベースを持つセカンダリサイトを昇格させます。
gitlab-ctl promote-to-primary-node
とgitlab-ctl promoted-db
コマンドはGitLab 14.5以降では非推奨となり、GitLab 15.0では削除されました。代わりにgitlab-ctl geo promote
。GitLabとデータベースが同じマシンにあるセカンダリノードでしか変更を実行できないため、gitlab-ctl promote-to-primary-node
コマンドは外部の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/10/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/10/main # Promote the PostgreSQL database and allow read/write operations sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote
-
セカンダリサイトの各ノードで
/etc/gitlab/gitlab.rb
を編集し、プライマリとしての新しいステータスを反映させます:geo_secondary_role['enable'] = true roles ['geo_secondary_role']
これらの変更を行った後、各ノードでGitLab を再設定して変更を反映させます。
-
セカンダリを プライマリに昇格させます。セカンダリのアプリケーションノードに SSH して実行します:
sudo gitlab-rake geo:set_secondary_as_primary
- セカンダリで以前に使用した URL を使用して、新しく昇格させたプライマリに接続できることを確認します。
- 成功すると、セカンダリサイトが プライマリサイトに昇格されます。
ステップ4(オプション)プライマリドメインDNSレコードの更新
セカンダリサイトを指すように、プライマリドメインの DNS レコードを更新します。これにより、Git リモートや API URL の変更など、プライマリドメインへの参照をすべて更新する必要がなくなります。
-
セカンダリサイトにSSH でログインし、root でログインします:
sudo -i
-
プライマリドメインのDNSレコードを更新します。セカンダリサイトを指すようにプライマリドメインのDNSレコードを更新した後、セカンダリサイトで
/etc/gitlab/gitlab.rb
、新しいURLを反映するように編集します:# Change the existing external_url configuration external_url 'https://<new_external_url>'
セカンダリDNSレコードがそのままである限り、external_url
を変更しても、古いセカンダリ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
設定を使用します。 -
GitLab 12.0から12.7では、データベースのプライマリサイト名を更新する必要があるかもしれません。このバグはGitLab 12.8で修正されました。
この作業が必要かどうかを判断するには、
/etc/gitlab/gitlab.rb
ファイルでgitlab_rails["geo_node_name"]
の設定を検索してください。#
でコメントアウトされているか、まったく見つからない場合は、データベースのプライマリサイト名を更新する必要があります。このように検索できます:grep "geo_node_name" /etc/gitlab/gitlab.rb
データベースのプライマリ・サイト名を更新するには:
gitlab-rails runner 'Gitlab::Geo.primary_node.update!(name: GeoNode.current_node_name)'
-
新しく昇格させたプライマリのURLを使用して接続できることを確認します。プライマリドメインのDNSレコードを更新した場合、以前のDNSレコードのTTLによっては、これらの変更がまだ反映されていない可能性があります。
ステップ 5.(オプション) 昇格させたプライマリサイトに セカンダリGeo サイトを追加します。
上記のプロセスを使用してセカンダリサイトをプライマリサイトに昇格させても、新しいプライマリサイトで Geo は有効になりません。
新しいセカンダリサイトをオンラインにするには、Geo セットアップ手順に従ってください。
ステップ 6.旧セカンダリのトラッキングデータベースの削除
すべてのセカンダリには、プライマリからのすべてのアイテムの同期ステータスを保存するために使用される特別な追跡データベースがあります。セカンダリはすでに昇格させられているため、トラッキングデータベースのデータはもはや必要ありません。
以下のコマンドでデータを削除できます:
sudo rm -rf /var/opt/gitlab/geo-postgresql
gitlab.rb
ファイルでgeo_secondary[]
設定オプションを有効にしている場合は、コメントアウトするか削除してからGitLab を再設定してください。
複数セカンダリ設定でのセカンダリGeoレプリカの昇格させる
複数のセカンダリサイトがあり、そのうちの 1 つを昇格させる必要がある場合は、単一セカンダリ設定におけるセカンダリGeo サイトの昇格させるに従うことをお勧めします。
ステップ 1.1 つ以上のセカンダリサイトにサービスを提供するために新しいプライマリサイトを準備します。
-
新しいプライマリ・サイトにSSH接続し、rootとしてログインします:
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.レプリケーションプロセスの開始
ここで、各セカンダリサイトが新しいプライマリサイトの変更をリッスンするようにする必要があります。そのためには、レプリケーション・プロセスを再度開始する必要がありますが、今回は別のプライマリ・サイトを対象とします。古いレプリケーション設定はすべて上書きされます。
GitLab HelmチャートでセカンダリGeoクラスタを昇格させます。
クラウドネイティブな Geo デプロイを更新する場合、セカンダリ Kubernetes クラスターの外部にあるノードを更新するプロセスは、クラウドネイティブでないアプローチと変わりません。そのため、詳細については常に単一セカンダリ設定のセカンダリ Geo サイトを昇格させるを参照してください。
以下のセクションでは、gitlab
ネームスペースを使用していることを前提としています。クラスターのセットアップ時に別の名前空間を使用した場合は、--namespace gitlab
をその名前空間に置き換えてください。
ステップ1.プライマリクラスターを恒久的に無効にします。
プライマリサイトが停止した場合、2つの異なるGitLabインスタンスで書き込みが行われ、復旧作業が複雑になるスプリットブレイン(split-brain)状態を避けるために、できる限りのことをしなければなりません。そこで、フェイルオーバーに備えるために、プライマリサイトを無効にしておく必要があります:
-
プライマリ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.すべてのセカンダリサイトノードをクラスターの外部に昇格させます。
GitLab 14.5以降を実行している場合:
-
Linuxパッケージを使用しているセカンダリKubernetesクラスターの外側にある各ノード(PostgreSQLやGitalyなど)について、ノードにSSH接続して以下のコマンドのいずれかを実行します:
-
Kubernetesクラスターの外部にあるセカンダリサイトノードをプライマリに昇格させます:
sudo gitlab-ctl geo promote
-
Kubernetesクラスタの外部にあるセカンダリサイトノードをプライマリに昇格させるには、これ以上の確認は必要ありません:
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
GitLab 14.4以前をお使いの場合:
-
セカンダリサイトのデータベースノードにSSHでログインし、PostgreSQLを読み書き可能に昇格させます:
sudo gitlab-ctl promote-db
-
セカンダリサイトのデータベースノードの
/etc/gitlab/gitlab.rb
を編集し、プライマリとしての新しいステータスを反映させます。geo_secondary_role
を有効にする行をすべて削除します:アーキテクチャによっては、これらの手順をセカンダリKubernetesクラスターの外部にあるGitLabノードで実行する必要があります。## In pre-11.5 documentation, the role was enabled as follows. Remove this line. geo_secondary_role['enable'] = true ## In 11.5+ documentation, the role was enabled as follows. Remove this line. roles ['geo_secondary_role']
これらの変更を行った後、データベースノード上でGitLabを再設定します。
-
タスクランナーのポッドを探します:
kubectl --namespace gitlab get pods -lapp=task-runner
-
セカンダリを昇格させます:
kubectl --namespace gitlab exec -ti gitlab-geo-task-runner-XXX -- gitlab-rake geo:set_secondary_as_primary
ステップ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を使用して、新しく昇格させたプライマリに接続できることを確認します。
-
成功しました!セカンダリがプライマリに昇格されました。
トラブルシューティング
このセクションは別の場所に移動しました。