手動フェイルオーバー

このページでは、Memorystore for Redis の手動フェイルオーバーの概要について説明します。フェイルオーバーの実施方法については、手動フェイルオーバーの開始をご覧ください。

手動フェイルオーバーとは

スタンダード ティアの Memorystore for Redis インスタンスでは、レプリカノードを使用してプライマリ ノードをバックアップします。プライマリ ノードが正常でなくなると通常のフェイルオーバーが発生し、レプリカが新しいマスターとして指定されます。手動フェイルオーバーはユーザーが開始するという点で、通常のフェイルオーバーとは異なります。Memorystore for Redis レプリケーションの仕組みの詳細については、高可用性をご覧ください。

手動フェイルオーバーを開始する理由

手動フェイルオーバーを開始すると、アプリケーションがフェイルオーバーに対してどのように反応するのかをテストできます。予期しないフェイルオーバーが発生した場合に、この情報を基にフェイルオーバー処理をより円滑に行えます。

オプションのデータ保護モード

次の 2 つのデータ保護モードを使用できます。

  • limited-data-loss モード（デフォルト）。
    • モードを変更しない限り、手動フェイルオーバーは常に limited-data-loss モードで実行されます。
  • force-data-loss モード。

データ保護モードを変更するには、次のいずれかのコマンドを使用します。

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss

または

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss

データ保護モードの仕組み

実際のフェイルオーバー シナリオでアプリケーションがどのように動作するかをテストする場合は、force-data-loss モードを使用します。このモードが障害復旧時のフェイルオーバーの条件を一番正確に表すためです。

プライマリからレプリカへのフェイルオーバーにはデータ損失のリスクが伴います。limited-data-loss モードでは、プライマリとレプリカの間で同期されていないデータの量が 30 MB 未満であることを確認してフェイルオーバーが開始されるため、データ損失が最小限に抑えられます。

force-data-loss モードはプライマリとレプリカ間の同期に関するこのチェックをオーバーライドします。レプリカの同期がプライマリより 30 MB 遅れている場合に force-data-loss モードを使用すると、30 MB 以上のデータが失われる可能性があります。

レプリケーション保留中のバイト数の指標

レプリケーション保留中のバイト数の指標は、プライマリが完全にバックアップされるまでレプリカがコピーしなければならない残りのバイト数を示します。フェイルオーバー中にプライマリが複製されると、保留中のバイト数が増加します。

この指標には、Google Cloud Console の [インスタンスの詳細] ページからアクセスできます。インスタンスの詳細ページを表示するには、プロジェクトのインスタンス リストのページでインスタンス ID をクリックします。

または、プロジェクトの Google Cloud のオペレーション スイートの指標エクスプローラにアクセスし、redis.googlapis.com/replication/offset_diff 指標を検索します。

手動フェイルオーバーを実行するタイミング

デフォルトの limited-data-loss 保護モードを使用した手動フェイルオーバーは、レプリケーション保留中のバイト数指標が 30 MB 未満の場合にのみ成功します。30 MB を超えるレプリケーション保留中のバイト数で手動フェイルオーバーを実行する場合は、force-data-loss 保護モードを使用します。

できるだけ多くのデータを維持するには、アプリケーションで一時的に Redis インスタンスへの書き込みを停止し、レプリケーション保留中のバイト数の指標が許容できる範囲まで下がるのを待ってから、手動フェイルオーバーを実施してください。

手動フェイルオーバーをブロックする潜在的な問題

  • 基本階層インスタンスにはレプリカがないため、このインスタンスに対して手動フェイルオーバーを実施しても効果はありません。

  • Redis インスタンスが正常な状態でない場合、手動フェイルオーバー オペレーションはブロックされます。

  • インスタンスで未完了のオペレーション（スケーリングや更新など）が保留されている場合、手動フェイルオーバー オペレーションはブロックされます。手動フェイルオーバーを実施するには、インスタンスが READY 状態になるまで待つ必要があります。

クライアント アプリケーションの接続

プライマリ ノードがレプリカにフェイルオーバーすると、Memorystore for Redis への既存の接続が切断されます。ただし再接続時には、アプリケーションが同じ接続文字列または IP アドレスを使用して自動的に新しいプライマリ ノードにリダイレクトされます。

手動フェイルオーバーの確認

手動のフェイルオーバー オペレーションが成功したかどうかは、Google Cloud コンソール、Google Cloud のオペレーション スイート、または gcloud で確認できます。

Google Cloud コンソールの確認

手動フェイルオーバーを開始する前に、Memorystore for Redis の [インスタンス リストページ] に移動し、インスタンスの名前をクリックします。

次に、[インスタンス プロパティ] セクションで、プライマリとレプリカのそれぞれが存在するゾーンを確認し、該当するゾーンを書き留めます。手動フェイルオーバーが完了したらこのページをもう一度参照して、プライマリ ノードとレプリカノードの間でゾーンが切り替わっていることを確認します。

Cloud Monitoring での確認

Metrics Explorer を使用してモニタリング対象リソースの指標を表示する手順は次のとおりです。

  1. Google Cloud Console で、Monitoring の [Metrics Explorer] ページに移動します。

    2. Metrics Explorer に移動

  2. ツールバーで [エクスプローラ] タブを選択します。
  3. [CONFIGURATION] タブを選択します。
  4. [Generic Node] メニューを展開し、フィルタバーに「Node role」と入力し、サブメニューを使用して特定のリソースタイプと指標を選択します。
    1. [有効なリソース] メニューで、[Cloud Memorystore Redis] を選択します。
    2. [Active metric categories] メニューで、[replication] を選択します。
    3. [Active metrics] メニューで、[Node role] を選択します。
    4. [適用] をクリックします。
  5. 省略可: データの表示方法を構成するには、フィルタを追加し、[Group By]、[Aggregator]、グラフタイプの各メニューを使用します。たとえば、リソースラベルや指標ラベルごとにグループ化できます。詳細については、Metrics Explorer 使用時の指標の選択をご覧ください。
  6. 省略可: グラフの設定を変更します。
    • 割り当てと、1 日に 1 つのサンプルを報告するその他の指標については、期間を 1 週間以上に設定し、プロットタイプを [積み上げ棒グラフ] に設定します。
    • 分布値の指標の場合、プロットタイプを [ヒートマップ グラフ] に設定します。

Cloud Monitoring のグラフでは、プライマリ ノードとレプリカノードを 2 本の線で表します。グラフ上の線にゼロの値が設定されているノードは、レプリカノードです。グラフ上の線に 1 の値が設定されているノードは、プライマリ ノードです。このグラフはフェイルオーバーを表すために、線の値がそれぞれ 1 からゼロ、ゼロから 1 に切り替わる様子を示しています。

gcloud 検証

手動フェイルオーバーを開始する前に、次のコマンドを使用して、プライマリ ノードが存在するゾーンを確認します。

gcloud redis instances describe [INSTANCE_ID] --region=[REGION]

プライマリ ノードは currentLocationId というラベルが付いたゾーン内に存在します。このゾーンを書き留めます。

手動フェイルオーバーが完了したら、gcloud redis instances describe コマンドを再度実行し、currentLocationId がゾーンを変更したことを確認して、プライマリ ノードが新しいゾーンに切り替わったことを確認できます。

また、locationId ラベルには、プライマリ ノードを当初プロビジョニングしたゾーンが示されます。alternativeLocationId ラベルには、システムによってレプリカノードが当初プロビジョニングされたゾーンが示されます。フェイルオーバーが発生するたびに、この 2 つのゾーンの間でプライマリとレプリカが切り替わります。ただし、locationId と alternativeLocationId のそれぞれに関連付けられているゾーンは変わりません。