レプリカアプライアンスへのフェイルオーバーの開始

フェイルオーバーに必要な時間は、レプリカを手動で昇� �させてトラフィックをリダイレクトするのにかかる時間によって異なります。 平均時間は、20 から 30 分の範囲です。

レプリカを昇� �させても、既存のアプライアンスのためのレプリケーションは自動的にセットアップされません。 レプリカを昇� �させたあと、希望する� �合には新しいプライマリから既存のアプライアンス及び以前のプライマリへのレプリケーションをセットアップできます。

1. プライマリ アプライアンスを使用できる� �合、アプライアンスを切り替える前にレプリケーションが終了できるようにするには、プライマリ アプライアンスをメンテナンス モードにします。

   • アプライアンスをメンテナンス モードにしてく� さい。

     • 管理コンソールを使用するには、「Enabling and scheduling maintenance mode」 (メンテナンスモードの有効化とスケジューリング) を参照してく� さい

     • ghe-maintenance -s コマンドを使用することもできます。

       $ ghe-maintenance -s

   • アクティブな Git 操作、MySQL クエリ、および Resque ジョブの数がゼロになったら、30 秒間待ちます。

     注: Nomad には、メンテナンス中であっても、常に実行中のジョブが存在するため、それらのジョブを無視しても問題ありません。

   • すべてのレプリケーション チャネル レポートが OK であることを確認するには、ghe-repl-status -vv コマンドを使用します。

     $ ghe-repl-status -vv

2. レプリカ アプライアンスで、レプリカを停止して、レプリカ アプライアンスをプライマリ ステータスに昇� �するには、ghe-repl-promote コマンドを使用します。 到達可能であれば、これによりプライマリ ノードも自動的にメンテナンス モードになります。

   $ ghe-repl-promote

3. レプリカの IP アドレスを指すように DNS レコードを更新します。 TTL 期間が経過すると、トラフィックはレプリカに転送されます。 ロードバランサを使用している� �合は、トラフィックがレプリカに送信されるように設定されていることを確認します。

4. 通常の操作が再開できることをユーザーに通知します。

5. 必要に応じて、新しいプライマリから既存のアプライアンスや以前のプライマリへのレプリケーションをセットアップします。 詳細については、「About high availability configuration」 (High Availability 設定について) を参照してく� さい。

6. フェイルオーバー前に High Availability 設定の一部であり、レプリケーションをセットアップする予定のないアプライアンスは、UUID による High Availability 設定から削除する必要があります。

   • 以前のアプライアンスでは、cat /data/user/common/uuid を通じて UUID を取得します。

     $ cat /data/user/common/uuid

   • 新しいプライマリでは、ghe-repl-teardown を使用して、UUID を削除します。 UUID は、前の手� �で取得した UUID に置き換えてく� さい。

     $ ghe-repl-teardown -u UUID

参考資料

• 「Utilities for replication management」 (レプリケーション管理のユーティリティ)