Skip to main content

レプリカ クラスターへのフェールオーバーを開始する

GitHub Enterprise Server クラスターに障害が発生した場合は、レプリカにフェールオーバーできます。

レプリカ クラスターへのフェールオーバーについて

アクティブなクラスターのデータ センターで障害が発生し、高可用性を構成している場合は、レプリカ クラスターにフェールオーバーできます。

レプリカ クラスターにフェールオーバーすると、レプリカ クラスターは新しいアクティブ クラスターに昇格され、新しいアクティブ クラスターが古いアクティブ クラスターから切り離されます。 古いアクティブなクラスター内のノードは、この操作を実行するのに十分な正常な状態にある場合、メンテナンス モードになります。

フェールオーバー後、高可用性が構成されていない 2 つのスタンドアロン クラスターがある状態になります。 新しいアクティブなクラスターからレプリケーションを再構成できます。 詳しくは、「クラスタの High Availability レプリケーションを設定する」を参照してください。

前提条件

レプリカ ノードにフェールオーバーするには、クラスターの高可用性レプリケーションが構成済みである必要があります。 詳しくは、「クラスタの High Availability レプリケーションを設定する」を参照してください。

レプリカ クラスターへのフェールオーバーを開始する

Note

クラスター構成のインスタンスで、フェールオーバー後、新しく昇格されたノードに以前のプライマリ ノードでアクセスできました。 これは、パッチ リリース 3.12.2 でフィックスされました。 詳細については、 「リリース ノート」"を参照してください。

このフィックスの結果として、 ghe-cluster-failover 古いプライマリ クラスターからブロックする IP を識別し、それらに書き込みます/data/user/common/cluster-ip-blocklist。 フェールオーバーが完了した後、コマンドが実行され ghe-cluster-block-ips 、新しいアクティブなクラスター上の IP がブロックされます。

さらに、これらのパッチ リリースでは、ghe-cluster-block-ipsghe-cluster-block-ipghe-cluster-unblock-ips、およびghe-cluster-unblock-ipコマンドも導入されました。 これらのコマンドを使用すると、新しく昇格したクラスターにアクセスできる IP を手動で制御でき、 ghe-cluster-failover コマンド全体の実行に関連する長い構成の実行を回避できます。その他の情報については、「コマンド ライン ユーティリティ」を参照してください。

  1. レプリカ クラスター内のプライマリ MySQL ノードに SSH 接続します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  2. セカンダリ クラスターへのフェールオーバーを開始し、リクエストに応答するようにノードを構成するには、次のコマンドを実行します。

    ghe-cluster-failover
    
  3. 設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。

    Finished cluster configuration
    
  4. DNS レコードを更新し、レプリカ クラスターのロード バランサーの IP アドレスを指すようにします。 TTL 期間が終了すると、リクエストはレプリカ クラスターに送信されます。

GitHub Enterprise Server がプロンプトに戻り、DNS の更新が反映されたら、フェールオーバーは完了です。 ユーザーは、クラスターの通常のホスト名を使用して GitHub Enterprise Server にアクセスできます。