レプリカ クラスターへのフェールオーバーについて
アクティブなクラスターのデータ センターで障害が発生し、高可用性を構成している場合は、レプリカ クラスターにフェールオーバーできます。
レプリカ クラスターにフェールオーバーすると、レプリカ クラスターは新しいアクティブ クラスターに昇格され、新しいアクティブ クラスターが古いアクティブ クラスターから切り離されます。 古いアクティブなクラスター内のノードは、この操作を実行するのに十分な正常な状態にある場合、メンテナンス モードになります。
フェールオーバー後、高可用性が構成されていない 2 つのスタンドアロン クラスターがある状態になります。 新しいアクティブなクラスターからレプリケーションを再構成できます。 詳しくは、「クラスタの High Availability レプリケーションを設定する」を参照してください。
前提条件
レプリカ ノードにフェールオーバーするには、クラスターの高可用性レプリケーションが構成済みである必要があります。 詳しくは、「クラスタの High Availability レプリケーションを設定する」を参照してください。
レプリカ クラスターへのフェールオーバーを開始する
Note
クラスター構成のインスタンスで、フェールオーバー後、新しく昇格されたノードに以前のプライマリ ノードでアクセスできました。 これは、パッチ リリース 3.11.8 でフィックスされました。 詳細については、 「リリース ノート」"を参照してください。
このフィックスの結果として、 ghe-cluster-failover 古いプライマリ クラスターからブロックする IP を識別し、それらに書き込みます/data/user/common/cluster-ip-blocklist。 フェールオーバーが完了した後、コマンドが実行され ghe-cluster-block-ips 、新しいアクティブなクラスター上の IP がブロックされます。
さらに、これらのパッチ リリースでは、ghe-cluster-block-ips、ghe-cluster-block-ip、ghe-cluster-unblock-ips、およびghe-cluster-unblock-ipコマンドも導入されました。 これらのコマンドを使用すると、新しく昇格したクラスターにアクセスできる IP を手動で制御でき、 ghe-cluster-failover コマンド全体の実行に関連する長い構成の実行を回避できます。その他の情報については、「コマンド ライン ユーティリティ」を参照してください。
-
レプリカ クラスター内のプライマリ MySQL ノードに SSH 接続します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
-
セカンダリ クラスターへのフェールオーバーを開始し、リクエストに応答するようにノードを構成するには、次のコマンドを実行します。
ghe-cluster-failover -
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
Finished cluster configuration -
DNS レコードを更新し、レプリカ クラスターのロード バランサーの IP アドレスを指すようにします。 TTL 期間が終了すると、リクエストはレプリカ クラスターに送信されます。
GitHub Enterprise Server がプロンプトに戻り、DNS の更新が反映されたら、フェールオーバーは完了です。 ユーザーは、クラスターの通常のホスト名を使用して GitHub Enterprise Server にアクセスできます。