手動フェイルオーバーについて

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

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

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

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

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

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

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

  • limited-data-loss モード（デフォルト）。
  • force-data-loss モード。

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

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

または

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

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

limited-data-loss モードでは、プライマリとレプリカの間でデータの差が 30 MB 未満であることを確認してフェイルオーバーが開始されるため、データ損失が最小限に抑えられます。プライマリ上のオフセットは、レプリカと同期する必要があるデータのバイトごとに増加します。limited-data-loss モードでは、プライマリと各レプリカ間のオフセットのデルタが 30 MB 以上の場合、フェイルオーバーが中止されます。データ損失を許容し、フェイルオーバーを積極的に実行するには、データ保護モードを force-data-loss に設定します。

force-data-loss モードでは、一連のフェイルオーバー戦略を使用して、積極的にフェイルオーバーを実行します。フェイルオーバーを開始する前に、プライマリとレプリカの間のオフセット差分はチェックされません。 30 MB を超えるデータ変更が失われる可能性があります。

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

レプリケーション保留中のバイト数の指標は、プライマリが完全にバックアップされるまでレプリカがコピーしなければならない残りのバイト数を示します。フェイルオーバー中にプライマリが複製されると、保留中のバイト数が増加します。フェイルオーバーがハードウェア エラーによってトリガーされた場合、新しいレプリカがホストエラーから修復されるまでオフセット値が取得できなかったため、レプリケーション保留中のバイト数が空と表示されることがあります。

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

あるいは、プロジェクトの Metrics Explorer にアクセスし、redis.googlapis.com/replication/offset_diff 指標を検索します。

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

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

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

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

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

  • Redis インスタンスが正常な状態でない場合、データ損失の最小化がブロックされているため、限定的なデータ損失の手動フェイルオーバー オペレーションは失敗します。

  • 無期限で実行される Lua スクリプトを実行している場合は、force-data-loss を使用してフェイルオーバーを開始する必要があります。この場合、限られたデータ損失のフェイルオーバー オペレーションが正常に完了しません。

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

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

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

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

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

Google Cloud コンソールの確認

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

次に、[構成] タブで、[プライマリ ロケーション] の横にプライマリ ノードが存在するゾーンを表示します。このゾーンを書き留めます。手動フェイルオーバーが完了したらこのページをもう一度参照して、プライマリ ノードのゾーンが切り替わったことを確認します。

Cloud Monitoring での確認

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

  1. Google Cloud コンソールのナビゲーション パネルで [Monitoring] を選択し、次に [ Metrics Explorer] を選択します。

    Metrics Explorer に移動

  2. [指標] 要素の [指標を選択] メニューを展開してフィルタバーに「Node role」と入力し、サブメニューを使用して特定のリソースタイプと指標を選択します。
    1. [有効なリソース] メニューで、[Cloud Memorystore Redis] を選択します。
    2. [Active metric categories] メニューで、[replication] を選択します。
    3. [Active metrics] メニューで、[Node role] を選択します。
    4. [適用] をクリックします。

  3. 表示から時系列を削除するには、[フィルタ] 要素を使用します。

  4. 時系列を結合するには、[集計] 要素のメニューを使用します。たとえば、ゾーンに基づいて VM の CPU 使用率を表示するには、最初のメニューを [平均] に設定し、2 番目のメニューを [ゾーン] に設定します。

    [集計] 要素の最初のメニューが [未集計] に設定されている場合は、すべての時系列が表示されます。[集計] 要素のデフォルト設定は、選択した指標タイプによって決まります。

  5. 割り当てと、1 日に 1 つのサンプルを報告するその他の指標については、次の操作を行います。
    1. [表示] ペインで、[ウィジェット タイプ] を [積み上げ棒グラフ] に設定します。
    2. 期間は少なくとも 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 のそれぞれに関連付けられているゾーンは変わりません。