高可用性構成の概要

このページでは、MySQL 第 2 世代インスタンスの高可用性(HA)構成の概要を説明します。HA 対応の新規または既存のインスタンスを構成するには、高可用性向けにインスタンスを構成するをご覧ください。

HA 構成の概要

HA 構成は、「クラスタ」とも呼ばれ、データの冗長性を確保します。この構成は、プライマリ ゾーンのプライマリ インスタンス(マスター)とセカンダリ ゾーンのフェイルオーバー レプリカからなります。準同期レプリケーションを使用すると、プライマリ インスタンスのデータとユーザー テーブルに対するすべての変更が、フェイルオーバー レプリカにコピーされます。インスタンスまたはゾーンで障害が発生した場合、この構成によりダウンタイムが短縮され、クライアント アプリケーションで引き続きデータを使用できます。

HA フェイルオーバー レプリカは、独立したインスタンスとして課金されます。詳しくは料金のページをご覧ください。

MySQL HA 構成の概要図以下のテキストで説明されています。

フェイルオーバー レプリカ

フェイルオーバー レプリカは、プライマリ インスタンスと同じデータベース フラグ、ユーザー(ルートを含む)、パスワード、承認済みアプリケーション、ネットワーク、データベースで構成されます。

制限事項

フェイルオーバー レプリカには次の制限があります。

  • フェイルオーバー レプリカは、プライマリ インスタンスと同じリージョンの別ゾーンに配置する必要があります。
  • 1 つのプライマリ インスタンスに対して作成できるフェイルオーバー レプリカは 1 つのみです。
  • フェイルオーバー レプリカのアクティベーション ポリシーやメンテナンスの時間枠の変更はできません。フェイルオーバー レプリカのメンテナンスの時間枠は、プライマリ インスタンスと同じです。
  • フェイルオーバー レプリカでのバックアップを有効にすることはできません。バックアップは、プライマリ インスタンス上で実行される必要があります。
  • フェイルオーバー レプリカは、プライマリ インスタンスからのみ作成でき、リードレプリカからはできません。

フェイルオーバーの概要

HA 構成のインスタンスが応答しなくなると、Cloud SQL は自動的にフェイルオーバー レプリカからデータを提供するように切り替えます。この動作は「フェイルオーバー」と呼ばれます。フェイルオーバーが発生したかどうかを確認するには、オペレーション ログのフェイルオーバー履歴を調べます。

各タブをクリックして、フェイルオーバーがインスタンスに与える影響を確認してください。

正常

MySQL のフェイルオーバー前の正常なインスタンスを示す図

フェイルオーバー

MySQL のフェイルオーバー発生時のインスタンスを示す図

結果

MySQL のフェイルオーバー発生後のインスタンスと結果を示す図

処理

以下の処理が発生します。

  1. プライマリ インスタンスで障害が発生します。

    プライマリ インスタンスがハートビート シグナルとして、1 秒ごとにシステム データベースに対して書き込み操作を行います。複数のハートビートが検出されず、かつ、フェイルオーバー レプリカが正常である場合、フェイルオーバーが開始されます。フェイルオーバーが発生するのは、プライマリ インスタンスが約 60 秒間応答しない場合、またはプライマリ ゾーンでサービスが停止している場合です。

  2. Cloud SQL は、フェイルオーバー レプリカがプライマリ インスタンスの状態に追い付くのを待ちます。

    この手順にかかる時間は、レプリケーション ラグの影響を受けます。

  3. フェイルオーバー レプリカは、プライマリ インスタンス役割に昇格されます。

    フェイルオーバー レプリカは、セカンダリ ゾーンのデータを処理し、プライマリ インスタンス名と IP アドレスは以前のフェイルオーバー レプリカに移動します。プライマリ インスタンスの IP アドレスが自動的に移動したため、クライアント アプリケーションが新しいプライマリ インスタンスに再接続する際には、接続文字列の変更が不要となります。インスタンスがデータを提供しているゾーンを確認するには、GCP Console の [概要] ページに移動します。

  4. フェイルオーバー レプリカが再作成されます。

    新しいフェイルオーバー レプリカは、フェイルオーバー レプリカの受信側 IP アドレスを保持し、正常なゾーンで自動的に再作成されます。

  5. リードレプリカが再作成されます。

    新しいリードレプリカは、リードレプリカの受信側の IP アドレスを保持し、正常なゾーンで自動的に再作成されます。

要件

Cloud SQL がフェイルオーバーできるようにするには、次の要件を満たす構成が必要です。

  • レプリケーションが正常な状態にある。
  • プライマリ インスタンスが通常の動作状態(停止していない、メンテナンス中でない、長時間実行オペレーションの最中でない)にある。
  • フェイルオーバー レプリカ上で管理オペレーションが処理中でない。フェイルオーバーがエクスポートのように管理オペレーションの直後またはその間に開始された場合、フェイルオーバー リクエストは失敗します。
  • フェイルオーバー レプリカが使用可能である。フェイルオーバーが開始され、フェイルオーバー レプリカが使用できない場合、フェイルオーバー リクエストは失敗します。リクエストが正常でないプライマリ インスタンスによるものである場合、プライマリ インスタンスは停止します。
  • レプリケーション ラグが許容可能な長さである。レプリケーション ラグが 10 分を超える場合、Cloud SQL は正常でないインスタンスのフェイルオーバーを開始しません。ユーザーが開始したフェイルオーバーとゾーンの停止によるフェイルオーバーは引き続き試みられます。

構成の正常性

フェイルオーバー レプリカの可用性

フェイルオーバー レプリカの可用性は、フェイルオーバー レプリカの指標としてではなく、次のようなプライマリ インスタンスの指標として提供されます。

cloudsql.googleapis.com/database/available_for_failover

この状態は、プライマリ インスタンスの Get リクエストへのレスポンスとして failoverReplica.available フィールドにも含められます。

Stackdriver を使用して、HA 構成指標を表示できます。Stackdriver で提供されるすべての Cloud SQL 指標については、Cloud SQL 指標の一覧をご覧ください。GCP で Stackdriver を使用する方法については、Stackdriver のドキュメントをご覧ください。

レプリケーション ラグ

概要

準同期レプリケーションでは、プライマリ インスタンスへのすべての書き込みオペレーションで、フェイルオーバー レプリカに対して同じ更新が行われる必要があります。変更内容を失わないようにしつつ、プライマリ インスタンスでのパフォーマンスへの影響を最小限に抑えるため、フェイルオーバー レプリカで更新イベントを記録し、順番に更新を実行します。フェイルオーバー レプリカでの更新よりも更新イベントが早く到着した場合、フェイルオーバー レプリカの状態がプライマリ インスタンスよりも古くなります。プライマリ インスタンスでの更新時と、フェイルオーバー レプリカがそのログから更新に追いつくまでの時間の差はレプリケーション ラグと呼ばれます。

レプリケーション ラグによりフェイルオーバーの所要時間が増える可能性がありますが、プライマリ インスタンスで処理されるすべてのトランザクションはフェイルオーバー レプリカのログに記録されるため、データの損失は起きません。

レプリケーション ラグの解決

プライマリ インスタンスへの書き込みが異常に増加したためにレプリケーション ラグが発生した場合、通常は負荷が再び減少した際に、フェイルオーバー レプリカがプライマリ インスタンスに追いつきます。レプリケーション ラグが大きくても安定している場合は、フェイルオーバー レプリカを削除して再作成できます。ただし、書き込みの負荷が継続し、レプリケーション ラグが増加し続ける場合は、対処する必要があります。レプリケーション ラグが大きすぎると、インスタンスの SLA カバレッジに影響する可能性があります。 詳細をご覧ください。

レプリカは保留中の書き込みを順番に受け取るため、シングル スレッドのインスタンスとして機能します。フェイルオーバー レプリカで RAM を増やしたりディスクを増やしたりして I/O スループットを向上させることは、状況によっては役立ちます。しかし、フェイルオーバー レプリカでの更新がプライマリ インスタンスから大幅に遅れている場合は、複数のプライマリ インスタンス間で書き込み操作を共有するようにデータベースを分割する必要があります。

指標

レプリケーション ラグの状態は、次のようなフェイルオーバー レプリカの指標で確認できます。

cloudsql.googleapis.com/database/mysql/replication/seconds_behind_master

この指標の値は、レプリカがプライマリ インスタンスから何秒遅れているかを表します。

この指標の Stackdriver アラートの設定について詳しくは、レプリケーション ラグのアラートを作成するをご覧ください。

バックアップと復元

HA 向けにインスタンスを構成しても、バックアップは必要です。また、HA 構成によってバックアップの作成方法が変わることもありません。ただし、インスタンスの復元方法には影響します。バックアップからプライマリ インスタンスを復元するか、またはプライマリ インスタンスでポイントインタイム リカバリを実行する前に、すべてのフェイルオーバー レプリカとリードレプリカを削除する必要があります。復元が完了したら、フェイルオーバー レプリカとリードレプリカを再作成する必要があります。

アプリケーションとインスタンス

HA インスタンスと非 HA インスタンスの使用方法に違いはありません。したがって、アプリケーションを特別な方法で構成する必要はありません。フェイルオーバーが発生すると、インスタンスへのそれまでの接続はすべて終了します。ただし、アプリケーションは再接続する際に同じ接続文字列または IP アドレスを使用することができ、フェイルオーバー後にアプリケーションを更新する必要はありません。フェイルオーバーの間、アプリケーションはデータベースに接続できなくなります。

アプリケーションがフェイルオーバーによってどのように影響されるかを正確に判断するには、手動でフェイルオーバーを開始する必要があります。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...